STM32H743 rev V USART2 Bootloader will not respond. rev Y Does work

FColl.1 · ‎2022-01-31

We have two revisions of our board.

RevA has STM32H743 RevY chip running bootloader V13.2 (confirmed using STLINK).

RevB has STM32H743 RevV chip running bootloader V9.0 (confirmed using STLINK).

On our RevA board we can connect successfully from another MCU to ROM Bootloader on USART2 and upload and flash firmware. This contradicts the AN2606 page264 which says USART2 does not work.

We are trying to get our RevB board working with STM32H743 RevV chip running bootloader V9.0 and it does not work. There are only very minor changes between the boards.

I have checked the following:

Reset and Boot0 pins toggled correctly (measured at chip)
BOOT_ADD1(optionbyte) = 0x1FF0 (checked with STLINK)
USART1 and USART3 RX pins not floating.
USB PB14/15 floating.
I2C pins pulled up
SPI pins floating but unlikely to be reliably clocking in 0x5A to sync
Tried 9600 and 115200 baud. Config UART to 8E1.
Waiting >100ms before sending to USART2
Tried sending 1000 times 0x7F with small gap between.

Does anyone have any suggestions on other things to try to get this working? Like I said it works on Rev Y chip so why not on Rev V?

Has anyone got the ROM bootloader on Rev V STM32H743 working with any of the ports?

Cheers,

Felix

FColl.1 · ‎2022-02-10

Finally...FWIW some extra information from ST Support regarding the V9.0 bootloader. These are responses to my questions and suggestions on a support case I opened with them.

>> Fig 60 shows the USART being configured after it has received the 0x7F.

>> How is this possible?

>> Does this flow chart need updating?

In fact there is a configuration, or more precisely a reconfiguration, that is done for USART1 only as it uses two set of PINs for detection.

>> Should PB15 be left floating or pulled up?

It depends on customer HW.

If PB15 is left floating it can induce interferences and may lead to bad detection.

So if customer HW is liable to interferences he can consider to connect it to VDD.

Pavel A. · ‎2022-02-10

A very interesting research, @FColl.1

IMHO it shows that the built-in bootloader is almost useless.

In all projects that we did on STM32s and STM8s, we never had a need to use this bootloader. Only SWD.

Recently an important customer asked us for a custom bootloader that is truly OTP (no "user" bootloader suits what they want, even with "secure area" or PCROP).

Would be great if ST could let users to program their own code into the "system" OTP area.

FColl.1 · ‎2022-02-13

I tend to agree. Not sure why ST is still using this bootloader at all. Unfortunately for our project it is still going to be cheaper to use the ROM bootloader than to roll a custom one.

FColl.1 · ‎2022-02-17

Just in case anyone else stumbles across this, we narrowed the problem down. We need to pull PB15 up to 3V3 with a 10K resistor to get UART2 to connect properly.