Flash EEPROM Emulation and Readout Protection

[Mr_M_from_G]

Hello,

we want to add a flash EEPROM emulation to our software, currently for STM32H7 but I think the question also applies to other STM32 families.

As the EEPROM contents must be preserved also over firmware updates I think there is a conflict with setting readout protection active. When I want to update firmware I have to unprotect readout which leads to a flash erase and this also erases EEPROM contents.

Is there a way around this with STM32?

Thanks a lot

Martin

[Danish1]

Having your own bootloader that runs on your stm32h7 is one way to do this.

It will never need to enable readout protection so can omit the mass erase.

The bootloader could execute at reset, and if it finds that the new firmware differs from what is currently in main FLASH, then it rewrites the FLASH, leaving the EEPROM pages intact. Of course the bootloader must verify that the new firmware is good before trying to do this.

But you need to work out how to give the bootloader the new firmware to load. Some people allocate (nearly) half the stm32 FLASH to store the new firmware. I suppose it could also use USB or another interface (although you don't want to wait too long to see if there's firmware on the attached PC as it slows boot-up time), but it is important to keep the bootloader simple so you're confident there are no bugs in it so it won't need updating.

Hope this helps,

Danish

[Mr_M_from_G]

Hello Danish,

thanks for your answer.

Maybe I was not quite clear. I want to enable readout protection to protect firmware against a readout for some reverse engineering purposes or something like that.

STs bootloader eg via UART currently also allows to avoid mass erase if no protection is enabled. But once you enabled readout protection, the only way to update your program is via a mass erase including any data stored in any sector included in an EEPROM emulation or similiar. At least thats how it seems to me at the moment. Still this is hard to believe because for quite some years now manufacturers don't include EEPROMs in their devices anymore, pointing developers to EEPROM emulation. But if the price is to have no readout protection, who would do it?

Any help or information is welcome

Thanks

Martin

[waclawek.jan]

IMO Danish made a typo above and he meant to say:

> [your own bootloader] will never need to disable readout protection so can omit the mass erase.

JW

[Bob S]

As @Danish​ said, write your own bootloader (or find one that someone else has written that fits your needs). The ST-provided built-in bootloader provides basic, generic capabilities. Needing EEPROM emulation isn't "basic", though it is often needed. Could you add an external SPI or I2C EEPROM to your design? That would (could??) remove the need for a custom bootloader. I think ST even provides code (somewhere, I don't have the app note number handy) for a USB DFU device, if your unit uses USB (I know, you mentioned UART above). IAR has a tech note about writing a bootloader for ARM Cortex-M CPUs (disclaimer, I haven't read this other than the search engine summary):

https://www.iar.com/support/tech-notes/general/creating-a-bootloader-for-cortex-m/

Writing bootloaders isn't too difficult, but does require some thought about error recovery modes.

[Mr_M_from_G]

Ah, now I got it, thanks Jan.

I even once wrote a bootloader for an SM32L4 and yes it could update firmware with readout protection active. I forgot about that because here we want to use STs bootloader... we'll have to discuss

Thanks again

Martin