Wouldn't disabling the flash readout protection erase the custom boot loader that might be stored in the main flash memory?

[Shivam]

I'm planning to write a custom boot loader for some reasons. For this the main flash memory will be partitioned into two sectors; the first one holding the custom boot loader and the 2nd one storing the user application. My biggest concern is the read out protection. Suppose I've a device with a custom boot loader along with read out protection enabled and now I want to update the firmware on the 2nd partition. Now as soon as I disable the read out protection, wouldn't it erase the whole flash memory erasing the custom boot loader along with it as stated in AN3155 (Under 3.12 Readout Unprotect Command section)? Is there any way I can set this mass erase only for the 2nd partition? So that the custom boot loader still resides in the 1st partition after this process?

[Danish1]

Yes disabling flash READOUT protection would erase everything, including your custom bootloader.

But what is the point of your custom bootloader, if not to load the main firmware?

Your bootloader could have a command to erase and load the user application.

Of course your PC or whatever would have to run a program to supply the new application in a form that your bootloader understands. And you might need a way for your main application to request that your bootloader does the erase-and-load cycle.

I tend to debug without a bootloader, and without readout protection.

But my release build only gets loaded by my custom bootloader.

I manage _write_ protection for the appropriate bits of FLASH, and on some stm32 updating this causes a reset cycle.

I never enable _read_ protection for my release build.

Hope this helps,

Danish

[Tesla DeLorean]

Mass Erase removes everything so you can't recover custom bootloaders, encryption algos and keys.​

D​o the firmware update without changing readout protection, watch which sectors that get write protected.

[Shivam]

I actually needed the read out protection so as to prevent the end user from reading the main flash memory and thus getting hold of the firmware. So from what I've understood; there's no way I can keep the read out protection enabled while also having my custom boot loader on the main flash memory. Is that right?

[Pavel A.]

Your custom bootloader can erase and write internal flash even when read out protection is active. This is how you will update your main application.

But do not do mass erase under write protection, and do not erase the bootloader itself. Then everything will be lost.

[Tesla DeLorean]

>> Is that right?

NO

[Shivam]

Thanks for your help sir. It's clear to me now.

I just had this one doubt though; I had already asked this in the previous replies. Is this "RDP inactive" check only limited to the internal boot loader? If what you've said is true then I can design my own boot loader which skips this check without any issue right?

"Doesn't the read out protection prevent you from issuing the write memory command on the main flash memory locations? In their write memory command flow (on device side), it seems to check whether the RDP is active before accepting the start address for the write operation. I would like to know how you were able to flash new firmware on the main flash memory while still having the read out protection enabled. Is my understanding of the flow correct or am I still missing something? It would be great if it's possible to directly update the firmware without having to disable the RDP."

[Pavel A.]

Yes you can skip this check

[Shivam]

Thanks a lot @Pavel A.​ @Community member​ for clearing my doubts. That was really helpful. Have a good day.