Secured MCU Breaker Experts!

Posts Tagged ‘open microcontroller bin’

Forty seconds after a part is connected, it has already told you which of four situations you are in: the array was never programmed, the array is protected, the read is addressing the wrong place, or the die is damaged. The information is in the pattern of the returned words, and it is available before any money is spent and before any package is opened.

On an OTP part this triage is more valuable than on a flash part, because nothing can be undone. There is no erase that resets the experiment, no second attempt at a different protection state, and no way to try again after a wrong guess about the device profile. Get the signature right and the job is one of three known engagements; get it wrong and the part may be destroyed proving it.

Four signatures, one table

The third row is the one that causes the most wasted work, because a repeating cycle looks like data to a tool that only counts bytes. It is the read path returning a fixed value in response to every address, and it happens on units that are protected and on units whose read timing is wrong.

The part in numbers

1024 words of twelve-bit program memory in two pages, 25 bytes of RAM, twelve I/O pins, thirty-three instructions, no interrupts, and a configuration word carrying the watchdog enable and the protection fuses. The A suffix denotes a revised die of the same architecture, specified for a higher clock and a wider supply window.

Two of those facts shape the triage. The single entry point means a good read always begins with a decodable instruction at address zero, which is the cheapest possible test. The two-page split means a read can be good for the first 512 words and wrong afterwards, which produces a signature that looks like damage and is usually a page-bit problem in the fixture.

All ones: the ambiguous signature

A blank OTP array reads as all ones, and so does a part whose data pin is not connected. The distinction is made by the configuration word: a blank part returns an unprogrammed configuration word, and a part with an open connection returns nothing coherent at all or fails identification.

There is a third case that catches people. A part that was programmed and then exposed to a bulk erase command on a programmer that believes it is a flash device will return all ones while the die is perfectly good. On a true OTP device the erase does not exist, so this happens only when the operator selected the wrong device profile, which is also the most common cause of the other signatures.

The correct response to all ones is not to conclude the part is blank. It is to read the configuration word, then read a second time with a different address order, and only then to report.

All zeros and repeating words

A clamped or shorted data bus reads as all zeros. So does a device whose read is being answered by the protection logic rather than by the array, on the parts where the protection pulls the output low rather than high.

The discriminator is the address. A bus fault produces the same value at every address including the configuration word and the calibration word at the top of the map. A protection artefact usually stops at the top of the array, because the configuration word is read through a different path and still returns its real contents.

So: read the config word. If it is plausible while the array is uniformly zero, the array is protected. If both are zero, suspect the fixture.

Plausible but wrong

The fourth signature is the cruel one, because it looks like success. The image decodes for a while, produces recognisable MOVLW and GOTO sequences, and then degenerates. Three causes dominate.

The first is an offset. A read that begins one word late produces an image in which address zero holds what should be at address one, and the first instruction no longer decodes to a jump. This is trivially detectable and therefore rarely missed.

The second is a page-bit problem. On a 1024-word part the upper page needs a status bit set before it can be read, and a fixture that never sets it returns page zero again at every address above 511. The image then looks like a program that repeats itself exactly once, which is not a thing real firmware does.

The third is the wrong device profile. A profile written for a 512-word part returns the first 512 words correctly and fills the rest with a constant. A profile written for a 2048-word part returns 1024 real words followed by 1024 words of fiction.

A triage order that takes ten minutes

Read the configuration word. It is small, it is outside the array, and it usually answers even when the array does not.

Read address zero and check that it decodes. If it does not, the read is misaddressed and everything downstream is worthless.

Read the last word of each page and compare against the first word. Identical values at four widely separated addresses are a fixture artefact, not code.

Count how many distinct values appear in the first sixty-four words. Real firmware produces more than a dozen; a protection artefact produces two or three.

Then, and only then, decide between the three engagements: a read, a die-level job, or a diagnostic report that says the part is fine and the fixture is not.

For the moment after triage, when the image has to become a file, PIC16C57 heximal file extraction covers the container arithmetic. For the protection model behind the second signature, PIC16C56 code copying explains what the fuses do and do not block. And for the same triage on a part with twice the array, PIC16C57C firmware is the direct comparison.

FAQ

Can an OTP part return to the blank state? No. Once a word is programmed the bits are fused. A programmer that reports an erase on this device has the wrong profile selected.

Is a repeating pattern always protection? Nearly always, but check the address range first. A pattern that stops at the configuration word is protection; one that continues through it is a fixture problem.

What does a dead die look like? Mixed data with stuck bits: the same word returning with one bit always high regardless of address. That is not recoverable by re-reading, and it is the one signature that justifies opening the package as the next step.

The short version

Four patterns, four conclusions, ten minutes. Read the configuration word first, verify address zero, compare widely separated addresses, and count distinct values. The signature decides whether the job is a read, a die-level recovery or a report that says the part was never the problem.