Posted on December 19, 2014 at 11:27We would like to enable level 1 read-out protection from code running on an STM32F437. We have code that will enable the protection using the following steps:
1. Unlock OPTCR by writing twice to FLAS->OPTKEYR, using special values from reference manual.
2. Wait for BSY bit to clear in SR register.
3. Set new value in OPTCR, with all RDP bits cleared
4. Set STRT bit in OPTCR
5. Wait for BSY bit to clear in SR register.
6. Relock OPTCR by setting lock bit
However, when this runs, the processor seems to hang shortly after step 4, setting the start bit. It may stop immediately - certainly we don't see any serial output that happens just after step 4. We've tried leaving the MCU powered for a few minutes with nothing more happening.
If the MCU is power cycled, level 1 protection has been set as expected.
We would like to set the readout protection and then continue normally, so that our bootloader can ensure protection is enabled whenever it runs. It would also be fine if a reset is required after enabling protection, since the board has just booted anyway. At worst, we can certainly tolerate the hang, and require the user to power cycle, but we wanted to check this behaviour, since a) it seems unlikely to be the desired result and b) it's not described in the reference manual, as far as we can find.
The protection code described above runs early in boot - we are running an RTOS, so we run the protection code before starting up any other threads.
Early in development of the code, it seemed to run without hanging the processor, just causing a brief interruption to normal execution, presumably while the flash is unreadable during writing of the option bytes, but we can't replicate this - some change to the code/generated binary means that it always hangs.
Finally, we also have code to return to level 1 protection. This runs very similarly - causing a hang when start bit is written. However since our code is running from flash this would seem to be the expected result - the code is erased, so obviously can't keep running! However it would be good to confirm that this approach is valid. The mass erase and level change do seem to work as expected, as long as the MCU is left powered for long enough to complete the mass erase and then change the level. Again, we can't find much detail at all on this in the reference manual, it would be very handy to have an outline of the recommended process, and what happens on the MCU in detail (e.g. we assume that the mass erase happens before the level change, etc.)
Thanks in advance for your help.
#rdp #stm32f4 #stm32
