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,

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...

Well, I use STM32F105 with lib 3.4.0

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)

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...

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

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

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!

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

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