Firmware update via bootloader - without reset - how to?

[SKled.1]

Scenario:

• one STM32F0, as part of a bigger system, has the purpose of monitoring and controlling the power rails.
• To be able to update the firmware in the field, a U(s)ART connects it to the Linux ARM SoC also in the system
• the latter is supposed to provide the firmware by implementing the corresponding USART firmware update protocol, talking to the STM32 bootloader.

As you may have guessed by now, it would be rather disadvantageous if the STM32 gets reset for the update, which reconfigures the pins as floating, and disables the power of the Linux SoC.

I searched around a bit and found several threads mentioning jumping to the bootloader code from user code - for which you apparently should do a reset, as things need to be set to defaults for it to work.

But if I understood the reference manual right, a "software reset" also resets everything, i.e. also the pins to floating. So the "write magic value to backup register, software reset, jump to bootloader from modified startup code if magic value is present" scheme would not work.

I can dream up a bunch of solutions using additional external hardware components.

But - can this be done without extra hardware?

Such that the system will still not saw at the branch it's sitting on and cut its own power?

[Tesla DeLorean]

Commit a few flash sectors to coding your own update loader, so you can control all aspects of it's behaviour and performance.

[MM..1]

As you write you have two ways:

1. change hw to leave thinks powered short time over reset stm32 - in own bootloader code turn power back on as first code
2. write own bootloader code but jump to it and from it without reset

use internal bootloader this way is i mean impossible.

[SKled.1]

Ah, ok. Thought maybe I could avoid rolling my own, but alignment of the planets seems against me 😉

Any tips, maybe warning of typical mistakes one could make / things that could go wrong, when implementing one's own bootloader?

How would I work with that? Assume I am using the STM32CubeIDE for development.

For virgin boards, I would first flash my custom bootloader, kept as a separate entity / project, to the address the default bootloader jumps to. By hand, e.g. using the STLink util for programming.

I make sure nothing never writes to the custom-bootloader area again (let's say after it has been confirmed working correctly)

For the application project, I would change the linker script in the STM32CubeIDE project such that the FLASH address points to the next sector after the bootloader, such that when debugging with the IDE, the IDE will load the code, via GDB / STlink, to the offset address.

That sector address has to be known by the boot loader also, to jump to in the normal, not-updating case, and for updating of course.

For getting the firmware onto the MCU without a debugger, I obviously use my new shiny bootloader.

All correct so far?

Anything else?

Thanks for the advice.

[MM..1]

All you writes is true, standart way we use is bootloader jump to app and IWDG or WWDG jump to bootloader , state bits is check and start upgrade.

In idea without reset i see RAM static variable addressed from booth codes, and checked in bootloader for magic word. When not writed start app.

App relocates interrupt table and run. Then in point to upgrade write magic to ram and jump to bootloader. It check magic and relocates vector back to boot.

Do upograde and jump to app area... no reset.

[prain]

Also you have option to use "scripts" instead of a completely new firmware. when using scripts you can load new script to MCU flash without reset. In some industrial PLCs based on stm32 this concept is used.

If you are familiar with python I recommend you ​to use MicroPython

[Piranha]

Regarding a robust and simple bootloader design, read my post here:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

[SKled.1]

Cool, thanks for the link!