1
\$\begingroup\$

I recently had to look into firmware readout and write protection for the STM32. And I noticed the process of disabling write protection after it's been enabled, is not device-specific; there's nothing unique (like the 96-bit device ID) involved in the lock/unlock process, that prevents someone other than the owner from unlocking the device, except that the unlocking process triggers a Mass Erase of the flash memory. The unlock keys are there in flash programming manual for anyone to see.

So did I miss something in the docs? Or is this just how it is with some MCUs, where disabling write and read protection basically results in a Mass Erase, ensuring the owner's code is safe (typically the ultimate goal, I assume)? Are there MCUs that actually use passwords from SRAM, unique device IDs or pin logic levels, to protect the flash and is this usually a built-in feature or must be implemented by the programmer?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ OTP (one time programmable) protection bits do exist in some devices, and some have the ability to disable the interface overall, but you have to ask, what is the point? Until you get into BGA's someone who wants to re-purpose the hardware can easily swap the chip for a new one, so making a simple erase possible gives up little benefit while making the chip design simpler and a firmware development team's life far easier as they can't accidentally make mistakes that need a technician or at least walking to the soldering bench to fix. \$\endgroup\$
    – Chris Stratton
    Mar 12, 2017 at 22:06
  • \$\begingroup\$ @ChrisStratton Yes, write protection never did make sense to me. Readout protection obviously yes, but how does one protect anything with write protection, except perversely denying the hacker the hardware? But a client asked for it a while back, so I'm just curious about it now. \$\endgroup\$
    – SoreDakeNoKoto
    Mar 12, 2017 at 22:19

2 Answers 2

Reset to default
3
\$\begingroup\$

Generally speaking, read protection is to protect the IP, write protection is to prevent a glitch from bricking the product.

So you want the read protection to be unbreakable without erasing the program (though the method does not have to be secret if it reliably erases the program) whereas write protection merely has to be set up so that it is extremely unlikely to occur accidentally, even if there are glitches etc.

\$\endgroup\$
2
  • \$\begingroup\$ But you haven't come across any MCU that used 'exotic' stuff like passwords or device IDs to disable read/write protection? Either as a built-in feature or devised by the programmer? \$\endgroup\$
    – SoreDakeNoKoto
    Mar 17, 2017 at 22:16
  • \$\begingroup\$ @TisteAndii It's common to protect parameters etc. with a password or special sequence of button pushes or whatever- I've certainly implemented it in firmware. You might find bootloader implementations of interest. \$\endgroup\$
    – Spehro Pefhany
    Mar 18, 2017 at 0:43
0
\$\begingroup\$

When you flip the read/write protection bits, what you actually are doing is just setting a floating gate bit. I've never seen a commercial implementation where you could erase a single bit, as we generally erase banks. If you happen to have a reprogrammable device with the protection bits set, when you bring it into reset mode it will start up the charge pumps and set all of bits to be high (that's the usual bring up state). Each MCU is different, but this is on all of the MCUs I've seen or made.

Regarding the processor IDs, we used e-fuses that were one-time write.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.