Topic : Problem with programming protected device

Forum : ARM

Original Post
Post Information Post
December 19, 2011 - 12:59pm
Guest

Hello. I have problem with upgrading program from my own bootloader procedures.

When procesor is not read-out protected, everything is going ok (verify says ok).
Problem occurs when I set in RFlasher7 (using Ride7 and RLink programmer). Internal program is erased ok (mass erase) but it stops after first full word programming command (flash controller returns FLASH_FLAG_BANK1_WRPRTERR). In Option Bytes non of the WRP0-WRP3 is set (all have 0xFF).

I have found in documentation potential problem: when RDP jest activated, first pages of the flash are automatically write protected, and probably thats why upgrade stops.

So, my question: I want to fully upgrade program in protected flash - how to do it ?

And one more guestion: Are option bytes erased during mass erase command ? Should I set up readOutProtection again after mass erase command ?

Replies
Post Information Post
+1
0
-1
December 19, 2011 - 1:15pm
Raisonance Support Team

Hi,

I'm not sure I completely understand your question, but here are a few hints...

Clearing RDP will erase everything, including option bytes.

Obviously, there will be a problem if the code doing this executes from the Flash, so you have execute all the required code (maybe the whole bootloader except the startup) in the RAM.

For most STM32 devices, the Mass Erase procedure of RFlasher (and Ride) is performed by setting and clearing RDP.

On some (maybe all) devices, the flash is write-protected while RDP is ON.

I hope it helps.

Best Regards,

Vincent

+1
0
-1
December 19, 2011 - 2:28pm
Guest

Well, I am not sure but I observed that RDP is not cleared when executing mass erase command.

And thats why is my problem : I am upgrading internal flash by my own bootloader. Bootloader procedures are of course executed from RAM: first mass erase command, and next flash is programmed. Everything work well when device is not ReadOut Protected.

But when I once RDP is activated this procedures doesnt work. Mass erase procedure clears flash, but upgrade program stops while first programming command (flash controller says that WRPRTERR occured).
I looked at the documentation, and I found that when RDP jest activated first pages of the flash are automatically write protected, and probably thats why upgrade stops. So, RDP is not cleared when mass erase procedure is executed.
But how can I upgrade software now when I cannot write first pages of flash ?

with best regards,

+1
0
-1
December 19, 2011 - 2:58pm
Raisonance Support Team

This would depend on which STM32 you are using, and which version of the lib...?

Maybe you must change your MassErase procedure for it to use the RDP. By default that's not the case with some STM32 libs/devices...

+1
0
-1
December 19, 2011 - 3:17pm
Guest

Well, I use STM32F105 with lib 3.4.0

+1
0
-1
December 19, 2011 - 3:32pm
Raisonance Support Team

Well, look at the lib's code and you'll see that FLASH_EraseAllPages does not touch the Option Bytes, and therefore it does not remove RDP.

If RDP was set before, you should call FLASH_ReadOutProtection to remove RDP (which also performs Mass Erase) before reprogramming. (both Flash and OBs)

+1
0
-1
December 19, 2011 - 4:02pm
Guest

Thats right. But the problem is that after removing RDP, the new value of the RDP will be reloaded only after PowerOn reset. But after PowerOn reset (or even simple reset) flash will be already empty (mass erase procedure will be executed automatically when clearing RDP). So my bootloader will dissapear from flash and RAM...

+1
0
-1
December 19, 2011 - 4:16pm
Raisonance Support Team

Hi,

You do NOT need to POR for the new RDP to be taken into account.

A Reset might be required, but you can do that and still keep the data in the RAM and instruct the device to boot in the RAM for the next reset. That would do the trick.

But how to do that is beyond our competence. I suggest you ask ST support, because this is really a STM32/lib question. (This forum is about Raisonance tools...)

Best Regards,

Vincent

+1
0
-1
December 19, 2011 - 5:05pm
Raisonance Support Team

Hi,

Lucky you, we have an internal project that does just this. (updating protected firmware by bootloader)

The simple way of doing it is to put the bootloader and _only_ the bootloader in the first flash sectors that are write-protected when RDP is ON. Then you make sure it does not erase itself. Meaning you just don't erase the pages containing it. (and of course you don't reprogram it)

So you do NOT need to remove RDP.

Best Regards,

Vincent

+1
0
-1
December 19, 2011 - 9:37pm
Guest

Great thanks for advices!!

But in my project, procesor cannot be booted from RAM directly (bootloader is executed after power up initialization and configuring some peripherials etc. ). Besides, how to upgrade bootloader then in such situation??

And I do mass erase command to make quick upgrade - with 256kbytes flash erasing page by page can last above 10 seconds.

thanks for help!

+1
0
-1
December 20, 2011 - 10:17am
Raisonance Support Team

Hi,

Let me clarify that there are two possible approaches...

1. Put the bootloader and all the init and libs it requires at the start of flash, use partial erase, keep RDP active all the time. In this scheme you cannot upgrade the bootloader itself. It is quite slow indeed but firmware upgrade is not performed often so 10~20 seconds delay is usually acceptable.

2. Remove RDP and reset with boot in RAM. Then of course you must put in RAM all the init and libs required by the bootloader. This option is faster to execute (probably) and allows to upgrade the bootloader, but it is more complex to implement and less secure: if there is a problem (connection, power, etc.) during the upgrade, you might loose the bootloader and be unable to use the device again until you reprogram it using a RLink or similar tool.

3. Another posibility would be to go for option 1 for firmware upgrade and for option 2 for bootloader upgrade.

As far as I know these are the only options when using the STM32. Ask ST: other solutions might exist.

Best Regards,

Vincent

+1
0
-1
December 20, 2011 - 10:24am
Raisonance Support Team

Hi,

In fact there is another solution, which is viable only for large quantities: (several hundreds or more) You can include the RLink in your design.

We can sell you some preprogrammed RLink CPUs and provide you with the schematic.

Then on-the-field upgrade is the same as production. And on-the-field debugging is much easier.

If you are interested in this approach, please contact

Several customers already did this and they are quite happy with it.

Best Regards,

Vincent

+1
0
-1
December 21, 2011 - 10:45pm
Guest

Great thansk for help!

My device needs to be upgraded remotly (via GPRS network), so preprogrammed RLink CPU mounted on the board will not help here.
But I will thing about this in next projects... thanks