cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with Automatic Write Protection & Bootloading

gordon23
Associate
Posted on December 18, 2012 at 09:50

Hi All

I have an '105 running a bootloader & application.  The bootloader is stable and I regularly release updates for products in the field.  I recently had a requirement to upgrade the bootloader in the field and wrote an application to do this. (The app contains a binary array of the bootloader, and attempts to over-write the original)

It all works great until I attempt to upgrade a device which has read protection enabled, which it fails miserably.  After quite a bit of hair pulling I found the following on page 17 on the 

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/PROGRAMMING_MANUAL/CD00283419.pdf

:

2.4.1 Read protection

The read protection ... ...Once the protection byte has been programmed:

? Main Flash memory read access is not allowed except for the user code (when booting

from main Flash memory itself with the debug mode not active).

? Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for high-density and

connectivity line devices) are automatically write-protected. The rest of the memory can

be programmed by the code executed from the main Flash memory (for IAP, constant

storage, etc.), but it is protected against write/erase (but not against mass erase) in

debug mode or when booting from the embedded SRAM.

Which essentially means I cannot erase and then write the first page of the bootloader.

Reading on I find (on page 18)

2.4.2 Write protection

In high-density ...

Unprotection

To disable the write protection, two application cases are provided:

? Case 1: Read protection disabled after the write unprotection:

� Erase the entire option byte area by using the OPTER bit in the Flash memory

control register (FLASH_CR)

� Program the correct RDP code 0x00A5 to unprotect the memory. This operation

first forces a Mass Erase of the main Flash memory.

� Reset the device (system reset) to reload the option bytes (and the new WRP[3:0]

bytes), and to disable the write protection

?

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.

Using Case 2 (underlined) I have attempted to unprotect the flash, but without luck.

Does anyone know if there is a workaround to get the first page(s) unlocked?

And moving forward (or alternatively) how to prevent the automatic write protection in the first place?  

We only implement read protection on our production devices, so this was rather unexpected.

Thanks

Gordon

#read-write-protection
3 REPLIES 3
Jacob L
Associate II
Posted on June 27, 2013 at 11:58

Hi Gordon,

I know this was a long time ago, but I am facing the exact same problem as you.

Did you manage to find a way around it?

Best regards,

Jacob Lillie

Jacob L
Associate II
Posted on June 27, 2013 at 11:59

Hi Gordon,

I know this was a long time ago, but I am facing the exact same problem as you.

Did you manage to find a way around it?

Best regards,

Jacob Lillie

damh
Associate II
Posted on June 28, 2013 at 09:48

There is a possibility/work around.

Use ''2'' bootloaders 😉

First one only load new MSP, SCB->VTOR and Resetvector of the second one. To clarify: the first 4kB of the device are ''lost'' or only a dummy bootloader.

The second bootloader is the real one and can be exchanged in a read protected device.

Better version: you take 3 bootloaders. First bootloader decides if second or third is the ''active'' bootloader. So you can exchange the bootloader without the problem, that there are a few (milli)seconds in which the device would not be recoverable if a powerfail occures.

But that needs flashsize 😉