STM32 Flash Read Protect/Write Unprotect

[rs11]

Posted on January 20, 2010 at 21:43

STM32 Flash Read Protect/Write Unprotect

[rs11]

Posted on May 17, 2011 at 13:22

I understand from

http://www.st.com/stonline/products/literature/pm/13259.pdf

that when readout protection is enabled in the STM32 flash, first two (in high density) pages of flash memory is automatically write protected. I have been trying to achieve a state where readout is protected, but the write is unprotected. I need this to be able to perform in field bootloader (which resides in the first two pages) upgrade. The documentation says this procedure 1) Enable Readout protection - Done with success 2) As per 2.4.2 of 13259.pdf, Uportect write by erasing the whole option bytes area and reseting the system - This operation if done without ''disabling'' readout protection does not unprotect the flash pages. Has anyone experienced this situation? Please share your experience.. Is unprotecting first two pages a possibility when the read is protected? I am able to write protect and unprotect successfully, when the read protection is not enabled. Also, if Read protect is enabled, I am able write unprotect if I disable read protection, but that will mass erase my flash which I cannot during just the bootloader upgrade.

[16-32micros]

Posted on May 17, 2011 at 13:22

Quote:

Has anyone experienced this situation? Please share your experience.. Is unprotecting first two pages a possibility when the read is protected? If the read Protection is enabled, The First 4Kbytes of flash are automatically write protected by Hardware and you can not disable it by software. This is done to protect user-bootloader to re-program it self by an untrusted code. Cheers, STOne-32.

[rs11]

Posted on May 17, 2011 at 13:22Thanks STOne-32. But the documentation 13259.pdf says the following...Is this a document error? ''Case 2: Read protection maintained active after the write unprotection, useful for inapplication programming with a user boot loader: – Erase the entire option byte area by using the OPTER bit in the Flash memory control register (FLASH_CR) – Reset the device (system reset) to reload the option bytes (and the new WRP[3:0] bytes), and to disable the write protection''

[16-32micros]

Posted on May 17, 2011 at 13:22

Hi rs1,

The documentation is correct too. It applies to the remaining pages ( the upper pages than the First 4Kbytes). Cheers, STOne-32.

[dbarto]

Posted on May 17, 2011 at 13:22

I can't seem to get the readout protection enabled. Given that I'm supposed to poke 0xffff at 1FFFF800, and when I try it doesn't stick.

Upon reboot the value has bounced back to 5AA5. What am I missing?

[dbarto2]

Posted on May 17, 2011 at 13:22

[Tesla DeLorean]

Posted on May 17, 2011 at 13:22

Main Flash memory access through code executed from SRAM or FSMC, and Flash access through data read using DMA1, DMA2, JTAG, SWV (serial wire viewer), SWD (serial wire debug), ETM and boundary scan are not allowed.

PM0042 Reading/programming the STM32F10xxx embedded Flash memory Doc ID 13259 Rev 7 19/35

I'm having a hard time separating your thought for the rest of the post. But when a ROP'd device booting into FLASH copies code from FLASH in to RAM, and executes that code in RAM it can see and access the protected FLASH. Access rights are inherited From PM0042

''All features linked to loading code into and executing code from the embedded SRAM are still active (JTAG/SWD and boot from embedded SRAM) and this can be used to disable the read protection. When the read protection option byte is altered to a memory-unprotect value, a mass erase is performed.''

If ROP'd device is booted into RAM, the FLASH/ROM are protected, while you can call a FLASH\ROM based subroutine, it will fail when it tries to load constants from that memory. This forum's editor continues to be godawful, and crashes/errors a lot.

[Shang.Dawei]

Posted on May 17, 2011 at 13:22