MCU doesn't boot in normal mode after readout protection done via ROM bootloader.

Anttu Koski · ‎2020-09-09

I have an issue with STM32L462 when using the ROM bootloader via UART to enable readout protection. It just hangs after enabling RDP level 1 and requires power cycling to recover. With several other STM32 MCUs (F0, F3, H7, ...) this seems to work.

The ROM bootloader seems to be responding still after RDP enabled, but the code from flash cannot be executed. I've tried resetting with GPIO, but that doesn't help.

Anttu Koski · ‎2020-09-09

Also noticed that the same issue is when moving RDP level 1 -> RDP level 0 (doing read unprotect).

EBier.1 · ‎2020-09-22

Does anyone have a hint on that? Any ideas to bring the mcu out of unknown reset/bus error state? Or maybe an interrupt like watchdog and a consecutive mcu reset?

waclawek.jan · ‎2020-09-22

Are you sure this is related to RDP level change? The 'L46x have an AN2606-Pattern-6 bootloader entry, i.e. they enter bootloader if the FLASH is "empty" - and the FLASH_SR.PEMPTY bit is reloaded only at power-on reset and OBL_LAUNCH command.

But protection level change itself may require the same reload at power-on reset, or OBL_LAUNCH.

So, maybe you can try to load a stub into RAM which performs OBL_LAUNCH, after programming.

JW

gregstm · ‎2020-09-22

Not sure if this is exactly related - I download my programs using the UART bootloader. When I moved to the STM32L4 chips, I had to start cycling power to get the downloaded program to run (with previous chips I could just press the reset button). My suspicion was that it is related to the fact that only a "power" reset clears all registers, and that a "system" reset (eg. NRST pin reset) doesn't - but maybe it is related to the fact that I use a change from RDP=1 to RDP=0 to do a mass erase before programming. (Note - after writing the previous paragraph, I re-read and investigated JW's reply - and I think it finally explains why I have to do a power-on reset to get my user program running!)

Anttu Koski · ‎2020-12-14

This seems to work at least in some cases:

See stm_pempty_launch_code[]

https://github.com/stm32duino/stm32flash/blob/master/stm32.c