ST ROM Bootloader boot0 pin

[KoS]

How is the boot0 pin is intended to be used by ST chip designers in real world applications? Once the boot0 pin is set high, the chip executes the bootloader section in memory and it will not go back to the execution of application section of memory unless the boot0 pin is set low. How can the user switch that pin back to low to recover the application firmware execution, after flashing a new application firmware, while the STM32 is in bootloader mode?

[Peter BENSCH]

Well, BOOT0 is not queried permanently, but only in a short period of time immediately after a pulse at the NRST of the respective STM32. You have not mentioned which STM32 it is exactly, because the different derivatives behave somewhat differently, which is discussed in detail in the respective reference manual and in addition in the AN2606.

But to answer your problem in general: yes, the BOOT0 may be set to 1, then the NRST is activated and deactivated again, which triggers a reset, after which the STM32 starts the built-in bootloader and waits for communication with the programmer via one of the serial ports. After that, of course, the BOOT0 must be set to 0 again and a new reset triggered, after which the STM32 then starts the user program.

Does it answer your question?

Regards

/Peter

[KoS]

Hi Peter,

Thank you for your time to answer.

Unfortunately this answer does not answer my question. Sorry for the incomplete information, I will rephrase and expand my question.

It is an STM32H723ZG. I have tested successfully the above mechanism for USB and observed the behaviour you mentioned.

Our intention is to have a firmware upgrade over the air via CANBus. We were not sure how are we going to achieve that using the ST embedded ROM bootloader.

While a "healthy" application is running in the STM32, we can potentially configure a circuit to set the boot0 pin and trigger a reset on NRST pin, using a GPIO pin to control that circuit (please suggest any circuit ideas). Then the bootloader will take over and flash the firmware.

Now how do we get back to the application memory section? Since our circuit will be latched with the boot0 pin high and there is no firmware running to reset it remotely back to low.

Please see my complete test process on another thread about the CANBus issue:

https://community.st.com/s/question/0D53W00002AXNeLSAX/st-rom-bootloader-fdcan-canbus

[Tesla DeLorean]

The normal method is to have an external resistor pull BOOT0 LOW so the part has unambiguous direction.

On the H7 a reset and a power-on reset are treated differently.

The MCU can also check the vector table for valid information, and will revert to the system loader if the user flash is blank. Expect to have to power cycle once programmed.

Expect to have to code your own CAN loader implementation, expect to have to own the PC side CAN stack, and the update application and process.

The ROM loader is primarily targeted at recovering otherwise bricked devices, and typically not a user facing method unless you own/create a suitable front-end that is supportable to those kinds of users.

Have your own boot loader, and don't erase it, keep it independent of your application image, and sign or validate that before handing over control so you have a robust and less brickable device.

[MM..1]

When you read more system bootloader have more commands , not only write erase.

One is go or start loaded application. And here your code place boot0 pin backto zero...