Issue with Bootloader on STM32H743 using Boot0 and inline application to invoke ST Bootloader code

[smati2]

I am porting code from STM32L4R5 (STM32L4R5VIT6) to STM32H743 (STM32H743VIT6). All the porting has gone well except for the last part being Bootloader. We use Boot0 pin Grounded and request to go to bootloader within the application. I should also mention that we are using SPI (SPI4 in case of STM32H743, and SPI2 in case of STM32L4R5) for bootloader communication with the primary micro.

Details: In our system, the primary micro is iMX7 and the secondary micro is the STM32. They communicate via SPI. On the "main" loop of STM32, among its many tasks, it continuously monitors for request to go into bootloader. Once, it detects the bootloader request, it calls the Bootloader routine (attached below for both STM32L4R5 and STM32H743). In the meantime, the iMX7 is listening for the STM32 to go into bootloader. Once it detects STM32 is in bootloader, it sends the new firmware to it.

In our previous design that uses STM32L, Bootloader works just fine. However, in our latest design using the STM32H, it is not working! It basically acts as if it is going to bootload (jumps to supposedly ST bootloader routine that I don't have code to trace) and hangs in there. Meanwhile, the iMX7 not detecting the STM32H7 is in bootload, it times out and the process stops.

Note that we are using Boot0 Grounded and I know the Bootload address for STM32H7 has changed to 0x1FF09800 (see attached code). Nevertheless, the process is not

successful. Also please note that the ST-Link in my debug under JTAG reports Bootloader version as 0x9.0.

BTW, I have looked on the ST Community and other resources. Apparently, ST has written a whole new bootloader for the STM32H7. Many seem to be complaining about the

Bootloader of STM32H7. The attached bootloader code used for the STM32H7 is referenced from ST Community Knowledge Base under the title "Jump to Bootloader from application on STM32H7 devices".

Any help with this is greatly appreciated as it is stopping us from moving forward with the design. Thank you in advance.

NOTE: Added my Flash registers from Debugger upon the breakpoint at main startup point.

[MM..1]

You check AN2606 Table 108 ?

[smati2]

Yes. FYI, the STM32L upon receiving the message to initiate Bootloader, it starts by sending 0xA5 on MISO. However, on STM32H, the MISO responds as 0x00 which may indicate that it hasn't gotten to the right location of Bootloader to respond as 0xA5.

[MM..1]

Need check and read better

order for detection if other interface is marked as detected SPI ...

Check too schematics and table 107 pinout usw.

[smati2]

Not sure what you are intending to indicate. I believe the diagram you sent is for the bootloader itself to decide which interface to use for bootload. In our case, we want the bootloader to use SPI (SPI4 in the case of out STM32H743). However, we are not seeing any activity on the MISO of our SPI4. Hence, basically indicating Bootloader did not detect the sync byte 0x5A coming from the primary micro (from MOSI) to reply with 0xA5 on MISO. Therefore, it is more than likely trying to bootload on another interface.

Please note that we have followed the recommendations on Table 108 of AN2606 and in particular PA11 and PB15 are pulled HIGH.along with stack pointer being lower than RAM end @ - 16 bytes.

BTW, except for SPI4, which we need for the Bootloader communication and is configured as recommended on Table 107 of AN2606, I have even tried to manually stop all the other used interfaces (I2C1, I2C2, I2C4, SPI2, USART2) on our STM32H design and changed all the pins for those interfaces to GPIO and at quiet state prior to the bootloader jump. Note that I know that the ST Bootloader is probably reconfiguring the pins for its needs, nevertheless, I have even done that prior to the bootloader jump and still ST's bootloader is not communicating on the SPI4.

[MM..1]

Read AN2606 better, only this pins is SPI4 for bootloader

and i send you diagram for you see SPI is on end check , then if detected is any other first ...

but your issue is bad pinout used maybe. (no info from your message)

[smati2]

Thanks for following up. Yes, we are using PE11 for SPI4_SNN, PE12 for SPI4_SCK, PE13 for SPI4_MISO, and PE14 for SPI4_MOSI. Also as mentioned before, we have followed the ST recommendations on Table 108 of AN2606 to "supposedly" avoid bootloader to choose another interface other than SPI4.

Looks like the bootloader Ver 0x90 with STM32H7 family is very sensitive and somehow detects another interface and doesn't communicate under SPI4. Many on the web are complaining about that bootloader for various reasons.

You know, an easy solution for ST, if ST is listening, would have been to have some setup with say a reserved location in the Flash for example that contains the interface used for Bootloader. So, depending on the value at that location, Bootloader would communicate with that interface. ST could even keep the current arbitration loop process as a backup in case it couldn't determine the interface by looking at the content of that flash address.

As much as I didn't want to, I am starting to consider writing our own bootloader....

[MM..1]

Thenmaybe you need jump to start ... Solder on your board one MCU only to pins power and stlink and PE SPI4. Setup option bytes to start system bootloader directly and test it.

Boot(pin) = 0 and BOOT_ADD0(optionbyte) = 0x1FF0