The phrase “security bits” comes from a generation of small microcontrollers where protection was literally one bit, sometimes one fuse, with two or three meaningful states. Engineers who worked with those parts still use the phrase, and it still gets typed into search boxes, but the thing it refers to no longer exists in that form.

On a modern ARM part the protection is a block of option bytes — a small non-volatile configuration area with several independent fields, one of which happens to encode a protection level. Calling them “bits” is harmless. Treating them as one bit is how devices get destroyed.

One word, four different mechanisms

When a customer says the chip is “locked”, they may mean any of four things, and the four have different answers.

Read protection is the one that matters for recovery, and it is the only one of the four that is a level rather than a flag.

Read protection has three states

Level zero is unprotected. The debug port can read the array directly, the ROM bootloader will hand over memory, and there is nothing to defeat.

Level one is protected. The debug port still connects, the core still runs, and every attempt to read flash through the debug interface returns either an error or meaningless data. What level one does not do is stop the code that is already in flash from reading it — the application can read its own constants freely, because it is not going through the debug port.

Level two is permanent. Debug access is disabled at the silicon level, the option bytes can no longer be changed, and there is no documented path back. A device at level two is not a recovery target by any software route.

The distinction between level one and level two is the single most important fact in this work, because the operation that “opens” a level one device also erases it, and the operation that attempts to open a level two device does nothing at all.

Write protection is not protection against reading

A frequent confusion: a device with write protection enabled is reported as “protected”, and it is — against modification. The array reads normally. If the goal is extraction, write protection is irrelevant, and mistaking it for read protection sends the job down a route that was never blocked.

The two are configured in the same option byte block, which is why they get conflated. They are evaluated by different logic and they answer different questions.

The small package does not simplify anything

The twenty-pin variant has the same protection hardware as its larger siblings. What it has less of is pins, and that changes the practical route rather than the protection.

With fewer pins, the debug interface shares signals with functions the application wants, and a product built around this package usually has very little board space for a probe. The result is that the electrical access is the harder half of the job, while the protection is the same puzzle as on a forty-eight pin part.

It also means a smaller array: at this flash size the entire image is a few dozen pages, and a full read is a matter of seconds once access exists.

Reading the option bytes first

Before any decision, read the option byte block and the status register that reports the current protection state. This costs one command and it prevents two expensive mistakes: attempting a read that was always going to fail, and issuing an unlock on a device that is already open.

The fields to record, in the order that matters:

1. The read protection byte and therefore the level.
2. The write protection bits, mapped to the pages they cover.
3. The boot configuration, which decides where execution starts and whether a bootloader is in the path.
4. The securable area size, if the option is present on this revision.

Record the raw values and the interpretation together. The interpretation is what you will check against behaviour later, and the raw value is what has to be programmed back.

What level one actually allows

Level one blocks the debug port from reading flash. It does not block:

• Execution of the existing code, which is how the device still works normally.
• Communication over the application’s own interfaces.
• Reads of memory that is not flash, within the limits the debug port imposes.
• Identification, which means the part number and the revision remain readable.

That last point is why a locked device can still be identified, and why the first question — which part is this — has an answer even before protection is considered.

The mistake to avoid

The unlock sequence for level one is documented and it works. It also erases the main flash as a security measure, which is the entire point: the protection is removed by removing what it protected.

So “opening” a protected device is not a recovery technique. It is a way to obtain a blank part. Any procedure that begins with an unlock has already decided to destroy the contents, and that decision belongs to the device owner, in writing, before it is executed.

Related reading

• STM32G030C8 and what opening the protection actually costs — the same mechanism, from the side of the operation rather than the map.
• STM32G030K8 and where the code physically lives — the read path once access exists.
• STM32F030C8 read-out protection — the predecessor family, where the same levels behave slightly differently.

FAQ

How many security bits does this part have? Not one. The protection is a set of option byte fields, of which the read protection byte is the only one that carries a level.

Can a level one device be read without unlocking? Not through the debug port. Other routes depend on what the application itself exposes.

Is level two ever recoverable? No documented method exists. A level two device is treated as unrecoverable through software.

Does the twenty-pin package protect differently? The mechanism is identical. Only the physical access differs.

Conclusion

The word survived the architecture that produced it. What exists now is a block of option bytes with one field that encodes a level, and the level determines everything: what can be read, what must be destroyed to change it, and whether the device is a recovery target at all. Read the block before doing anything, and treat the word “unlock” as a synonym for “erase” until proven otherwise.

Comments are closed.