Secured MCU Breaker Experts!

Posts Tagged ‘open mcu eeprom’

A programmer’s “read all” button is a convenience that assumes the device is one contiguous memory. On this part it is not. There are four distinct ranges, they behave differently under protection, and only one of them is the customer’s program.

Knowing which range you are reading is the difference between delivering an image and delivering sixty-four kilobytes of somebody else’s bootloader.

The four ranges

The main flash begins at a fixed base address and runs for the size of the part — sixty-four kilobytes here, which is thirty-two pages of two kilobytes each. Everything above that base is either a different memory or nothing.

The system memory is the one that causes trouble. It contains the vendor’s bootloader, it is identical on every device of this family, and a read that runs past the end of main flash into it produces a file that disassembles into plausible code. It is not the application, and delivering it as part of the image inflates the file and confuses every downstream tool.

Two kilobytes per page, and what that implies

Thirty-two pages is small enough that the whole array fits in one transfer, which removes most of the complexity of large-part extraction. There is no bank switching, no read-while-write, no second bank to keep coherent.

What remains is the ordinary discipline: read the whole array, read it again, and compare the two. A page that differs between passes was being written, or is marginal. Either way it is a page to look at rather than a page to trust.

Erased flash reads as all ones. That is useful, because it makes the end of the program visible: a region of all ones at the top of the array is either unused space or the boundary of what the part was ever programmed with.

Reading the first eight bytes

The vector table at the base of the array is the cheapest sanity check available. The first word is the initial stack pointer, which must point into SRAM. The second is the reset handler, which must point into the array.

If the first word looks like a code address rather than a RAM address, the base is wrong or the image is shifted. If the second word points outside the array, the file has an offset error. Both are caught in one look, before any disassembly.

An all-ones vector table means the array is blank — which on a device that was supposed to be programmed is a finding, not a failure.

The read path, and what blocks it

At the lowest protection level the debug port reads the array directly. That is the fast path: nothing to unlock, nothing to sacrifice.

At the next level the debug port connects but reads do not return the array. The returned values are not random — they are typically zero or an error, which is a distinguishable signature. A read that returns zeros where the vector table should be is not a blank device; it is a protected one. This distinction is worth stating plainly because “the chip is empty” is a conclusion people reach too quickly, and it leads to the wrong next step.

The ROM bootloader is a separate path with its own command set, and it does not bypass read protection. It is subject to the same option byte, which means it is useful for identification and useless for extraction on a protected part.

What to do with the file afterwards

Three deliverables, in the order a customer uses them.

The image, exactly as read, with the base address and the length stated. Not trimmed, not padded — the raw read, so it can be compared against a future read byte for byte.

A loadable format for programming a replacement, which is the same bytes with the addresses made explicit. This is a mechanical transformation and it should be done by a tool, not by hand.

An orientation document: where the vector table is, roughly where the code ends, whether the last pages look like data rather than code, and whether there is any sign of a bootloader in the boot configuration.

That third item is what makes the delivery usable by someone who was not present during the extraction.

The last pages are often not code

A pattern worth checking on every device of this family: the final pages frequently contain something that is not instructions. Configuration blocks, emulated non-volatile storage, calibration copies, log records.

The tell is content. Code has structure — a dense mix of opcodes with regular patterns and few long runs of identical bytes. Data has repetition, or readable ASCII, or long runs of the same value. A page that disassembles into nonsense is not corrupt; it is a different kind of thing.

Saying so in the delivery matters, because the alternative is a customer who tries to disassemble the configuration block and concludes the recovery was faulty.

When the read is incomplete

If the array is protected and the non-destructive routes are exhausted, the remaining options are the physical ones, and they are a different order of job. Before that decision, confirm that the simple things are not the cause: a read that fails partway through is more often a clock or supply problem than a protection problem, and a read that returns a truncated file is usually a tool setting.

Related reading

• STM32G030F6 and what the protection levels mean — the option byte map behind the blocking.
• STM32G030K6 and why an identical copy still differs — the per-unit regions a dump does not capture.
• STM32F030CC flash memory — the predecessor’s layout, useful for comparison.

FAQ

Should the system memory be included in the dump? No. It is the vendor’s bootloader, identical on every unit, and it is not part of the customer’s program.

How can a protected device be told from a blank one? A blank array reads as all ones. A protected read typically returns zeros or an error. The two signatures are different.

What is the page size on this part? Two kilobytes. Sixty-four kilobytes is thirty-two pages.

Can the bootloader read the array on a protected device? It is subject to the same protection, so no.

Conclusion

Four ranges, one of which is the job. Read the array twice, check the vector table, keep the system memory out of the file, and tell the customer which pages are not code — that is the difference between a dump and an extraction.