Once in the system bootloader, is there a way to update a readout protected firmware with only an UART access (and no BOOT0 access)?

[PA:99]

Hello,

Objective:

I have to update the firmware of an STM32F412 using the bootloader in system memory (through UART protocol).

Situation:

A command in my user code allows jumping to the bootloader after a system reset (so the device is in nominal state). This works well and allows to update the firmware if the readout protection is not activated (RDP=0xaa).

Problem:

If the readout protection is activated (RDP=0xbb), the bootloader command that deactivates it does a mass erase (as expected) but also a system reset (as documented in AN3155 p.34). As there is no access to the BOOT0 pin in my case, this system reset makes the MCU exit the bootloader code and renders the flashing impossible.

Questions:

Is there a solution to remove the readout protection and stay in the bootloader so the new firmware could be written to flash? Or another way to achieve the stated objective?

Thanks for reading!

PA

[Gudgel.boB]

I don't know about the built-in system bootloader but you can make your own bootloader that waits a few seconds (after reset) for a particular string on the UART line and then reads successive input to that UART so that the flash can be programmed with that data you send it. All with the flash read protection enabled. This bootloader can also decrypt your encrypted update if needed so that others (customers ?) can update their processors. But I don't think the built-in booloader does this since the key needed to decrypt that code update would then be known to everyone from reading the manual for the processor.

Can't the built in SFU USB uploader upate method the processor even though it is read protected ? Or is that necessary to be able to verify the new code given to the processor over the USB that keeps that from happening ?

[Andreas Bolsch]

You could try to do the RDP level decrease in code located in RAM and jump to the bootloader after the mass erase completed *WITHOUT* causing an option byte reload (that's the reason for the bootloader to issue a reset). The problem is whether the booloader itself checks the RDP level on entry and behaves accordingly, and if this is the case whether the boodloader does this check on the contents of the option byte in flash (where RDP level would be at 0 already) or the contents of the flash option register (which would still indicate level 1). I'm afraid you can find out this only by experiment.

But even if this would work, there is no guarantee this will remain possible in a future revision of the bootloader code.

If the bootloader doesn't allow flashing your application with flash option register still at RDP level 1, the last resort would be to write (by code in RAM) a short program to flash which jumps directly to bootloader and issue the reset then after level decrease and mass erase. The RM doesn't seem to explain whether a simple system reset causes an option byte reload (for some other devices it does *NOT*, only a power-on reset does), but if it does not, a simple

resolution would be to to cause a wake up from standby mode (the RM mentions explictly option byte reload for this situation).

Fortunately the F412 doesn't erase the RAM when changing RDP level 1 to 0, as some other devices do, but some of these offer BOOT level selection by options bytes ...

[PA:99]

Hello,

Thank you for your answer!

I think making my own bootloader (or at least part of it) as you propose will be the cleanest way to achieve what I need. And as you said, this will also allow the encryption of the distributed firmware, without witch the read-out protection is of reduced interest.

Regarding the build-in USB bootloader, I quickly checked AN3156, and I didn't find a way to update the flash while the RDP is active. The standard "Write memory" command seems to not allow it:

"If the Flash memory read protection is enabled, the Write memory operation is not performed" (AN3156 rev11 p. 14).

I didn't check this in detail tough (as USB is not an option for me).

Kind regards,

PA

[PA:99]

Hello,

Thank you for your explanation and for drawing my attention on the potential non-reloading of the flash option register on system reset (and the corresponding solution)!

Thank you also for your two suggestions of code in in RAM to circumvent the the problem. It was interesting to read and I will certainly have that in mind when I write a more definitive solution to this problem. I think I see a little deeper now in the internals associated to the boot process : )

For the short term, I unfortunately will have to leave the units unprotected because of the limited time I can allocate for that right now.

Kind regards,

PA