How do I jump from application code to bootloader without toggling the BOOT0 pin on STM32H745?

[Michael98006]

I followed this article by @Khouloud GARSI​ and was unable to get the function to jump to the bootloader working. The application seems to freeze after I execute the function given in the article and the bootloader doesn't ACK my messages until I reset the MCU with BOOT0 line pulled high (so I know I can talk to the bootloader in principle - I just can't jump to it programmatically).

Also, I don't understand the claim in that article that the bootloader starts at address 0x1FF09800 when the documentation says it starts at 0x1FFF0000 (see AN2606). In any case, I tried jumping to 0x1FFF0000 and got a hardfault, so 0x1FFF0000 seems like the wrong address.

We're trying to automate the process of firmware updates where we have an external control board talking to the STM32H745 MCU and allowing us to do OTA firmware updates, but the BOOT0 line is not connected to the control board. We built a custom board that we don't want to change, so if we have to toggle the BOOT0 line programmatically, it's going to require some really annoying rework we'd rather not do.

Any help with this issue would be greatly appreciated!

[berendi]

Put back all peripherals to their reset state as the bootloader expects them to be. Do not trust any library function or code written by people who do not know what they are doing.

Simplest way might be to set all defined bits in the RCC reset registers to 1 then to 0, then deal with the odd ones that do not have reset bits like RCC itself.

[TDK · Accepted solution]

You could also test your "jump to bootloader" code by immediately jumping to the bootloader on startup without first enabling peripherals or changing the clock. Once you're sure that is working, you can work on figuring out which peripheral is causing the issue.

[berendi]

Doing a NVIC_SystemReset() and jumping to the bootloader immediately in the reset handler is also a valid way to put back all peripherals in a state the bootloader expects them to be.

[Tesla DeLorean]

>>Also, I don't understand the claim in that article that the bootloader starts at address 0x1FF09800 when the documentation says it starts at 0x1FFF0000 (see AN2606). In any case, I tried jumping to 0x1FFF0000 and got a hardfault, so 0x1FFF0000 seems like the wrong address.

This ain't rocket science, you can actually look into memory and inspect it, and see where the active vector table is. The system memory is quite large, the boot loader is a subset of that. The Reference Manual is the controlling document here, which defines system memory in the 0x1FF00000..0x1FF1FFFF (128KB) range.

@Amel NASRI​ can someone flag AN2606 H7 section for review?

[Piranha]

A link to a detailed description of the same:

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

[Amel NASRI]

Hi @Community member​ ,

I'll take care to report this for review. Thanks for highlighting this.

I'll keep you informed.

-Amel

[Khouloud GARSI]

Hi @Community member​ ,

As said by Clive, the system memory is quite large and the boot loader is a subset of that.

In STM32H7, the base address of system memory is 0x1FFF0000 while the entry point of the bootloader is 0x1FF09800. They are not the same on this family.

We will add this information to our documentation.

However, the jump to the bootloader using the address 0x1FF09800 should work. I have already tested it before sharing the sample code on the "Jump to Bootloader from application on STM32H7 devices "article.

Khouloud.

[KSun.3]

Before calling SysMemBootJump(), is it necessary to to execute __DSB()?

[TSosi.1]

Hi Khouloud,

Where is the address 0x1FF09800 specified in the documentation?

Thanks!

Tom