Bootloader to read from external EEPROM and write to MCU's flash memory

[rodrigoruiz1230]

 Hi community, I´m using an STM32F411RE with which I plan to create a custom bootloader with specific functions located on sector 7 of flash memory. These functions will read the data stored in an external EEPROM that contains a .hex file, which should then be read and written to address sector 0 of the flash memory. Once this is completed, the new program will be executed. (Perhaps it may be better to switch up the sectors?)

In other words, the idea is to update the STM32 firmware whenever there is a new update by querying a webpage, which will then respond to the STM32 and send the .hex file to be stored in the external EEPROM. The STM32 will enter bootloader mode once all data has been sent, load the new firmware into the flash memory, and execute the new program. I’ve attached an image to reinforce the idea.

[Tesla DeLorean]

Ok, and what's stopping you in doing this?

Perhaps break this down and implement the pieces, the read/write of the internal flash, the read/write of the EEPROM. Look at how you want to transfer the data, over serial, common protocols like X/Y-Modem, something with it's own flow control and error checking etc.

I'd probably use sector zero as the boot, as that's where the MCU expects to find the first code.

[rodrigoruiz1230]

Ok thanks for your response @Tesla DeLorean, my main question was if the idea was feasible to begin with. I'm a beginner using the bootloader and the eeprom, so i was looking videos about how to use a custom bootloader because the videos that i watch always use the default bootloader (the one accessed by the boot0 pin), i agree with you that a bootloader on sector zero is the best idea so based on your experience and knowledge do you know where I could find information about how to create a custom bootloader. Please and thank you.

Kind regards.

[Tesla DeLorean]

As a beginner, start with smaller incremental goals.

Is it possible, yes in the broad sense, you can stage updates in EEPROM or QSPI NOR FLASH, and then subsequently apply them to Internal Flash

Can you probe the web? Not directly, but an app on the PC could, or something running on the STM32 with access to WiFi, Cellular, etc, could send an HTTP type request, or access an FTP server.

One could send a .HEX over a serial link to an STM32, you'd need to process and decode that, and pace the ingestion as the Internal Flash Erase and Write are slow and blocking, so you'd need some flow control to prevent data loss. Perhaps use a protocol that accomodates that directly.

Perhaps look to ST's IAP examples (In Application Programming)

The ISP (In System Programming) via the System Loader has a method to move binary data into memory. The USART protocol is described here, you could code a PC side app to implement this.

https://www.st.com/resource/en/application_note/an3155-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

[NEdom.1]

Are you looking for a firmware plan?

You  might need two STM32 programs or firmware staff to implement IAP and OTA for STM32, the bootloader and the main application.

You could issue an update action either in bootloader or in you main application.

Issue update in you bootloader:

Powerup -> Bootloader -> Main app -> any update ? No -> Stay in Main app and do your things.

Yes -> Set update flag -> reboot to bootloader -> get firmware package and save in NV memory -> Success? No,  try again.

Yes -> Clear update flag and set new main app jump address. then reboot and jump to main app.

Perform Update in your main app:

Powerup -> Bootloader -> Main app -> any update ? No -> Stay in Main app and do your things.

Yes -> get firmware package and save in NV memory -> Success? No,  try again.

Yes -> set new jump address and reboot

You might consider the data security and integrity of the firmware transferred. Additional, some memory area in RAM may need to be set non-initilaized to maintain information while reboot.

Also it is recommended to keep a brick rescue area with read-only option whenever the main app firmware updated is corrupted.