Posted on November 01, 2016 at 15:50Dear all,
I have an issue using the option bytes to set the program flash write protection during a firmware update through IAP (in application programming).
My devices are STM32F427ZI and STM32F429NI (Eval-Board: STM324x9I-Eval). I don't use the dual bank feature.
The update of the application works fine. The procedure in short is:
1. start in bootloader program (an own implemention, boot pins 0 0)
2. remove the write protection of the application sectors
3. perform the flash update
4. enable the write protection
5. reset
Sometimes the update fails. After a couple of hours doing research, I found the critical part and isolated it.
What do I see?
The critical thing is step no 4 and a power cycle instead of soft-reset by a user (a very impatient one).
In that case the programm flash is read protected (level 1) and neither the bootloader nor the applications starts.
From the users point of view the device is bricked now.
Reading back the register FLASH_OPTCR it contains CFFFFFFD and FLASH_OPTCR1 is 0FFF0000. In the FLASH_OPTCR register only the nWRP[11:0] was updated to enable the write protection by my bootloader application, RDP and the all the other bits haven't been touched.
I guess the power loss that occurs after or during erasing the option byte flash bricks the device leaving all bits set. Does anybody can confirm this?
Although the impatience of the user is not part of the procedure mentioned above. Regarding to robustness this behaviour is very critical.
Is it a mistake by me or a real issue - already known? Did I forget anything that can help to prevent this behaviour?
Thanks a lot, I look forward to your help/hints and questions.
Best regards, sphere
#stm32 #option-bytes #flash
