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

[FColl.1]

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:

1. Reset and Boot0 pins toggled correctly (measured at chip)
2. BOOT_ADD1(optionbyte) = 0x1FF0 (checked with STLINK)
3. USART1 and USART3 RX pins not floating.
4. USB PB14/15 floating.
5. I2C pins pulled up
6. SPI pins floating but unlikely to be reliably clocking in 0x5A to sync
7. Tried 9600 and 115200 baud. Config UART to 8E1.
8. Waiting >100ms before sending to USART2
9. 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]

I just ran it under the STLINK. I put the unit into bootloader then halt in STCUBE programmer. Reading the PC it is a value around 0x1FF0AAF4. Can an ST employee please confirm that this address is in the initial loop? Or... has it accidentally synced to a port other than USART2?

[FColl.1]

I found the video at https://www.youtube.com/watch?v=kTMjjED8ErA which has some very useful reverse engineering tips for the bootloader. This information should be in a trouble shooting section of AN2606.

Following the instructions in the video I dumped the USART1,2,3 registers (in that order) from my device.

This is the register state in the normal operation of my application firmware (we use USART2 during normal operation):

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -r32 0x40011000 0x2c -r32 0x40004400 0x2c -r32 0x40004800 0x2c
 -------------------------------------------------------------------
 STM32CubeProgrammer v2.8.0
 -------------------------------------------------------------------
 
ST-LINK SN : 005000373438510634313939
ST-LINK FW : V3J9M3
Board : STLINK-V3MINI
Voltage : 3.34V
SWD freq : 24000 KHz
Connect mode: Hot Plug
Reset mode : Software reset
Device ID : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size : 2 MBytes
Device type : MCU
Device CPU : Cortex-M7
BL Version : 0x90
 
 
Reading 32-bit memory content
 Size : 44 Bytes
 Address: : 0x40011000
 
0x40011000 : 00000000 00000000 00000000 00000000
0x40011010 : 00000000 00000000 00000000 000000C0
0x40011020 : 00000000 00000000 00000000
 
 
 
Reading 32-bit memory content
 Size : 44 Bytes
 Address: : 0x40004400
 
0x40004400 : 0000012D 00000000 00000001 00000029
0x40004410 : 00000000 00000000 00000000 006000D0
0x40004420 : 00000000 00000000 00000000
 
 
 
Reading 32-bit memory content
 Size : 44 Bytes
 Address: : 0x40004800
 
0x40004800 : 00000000 00000000 00000000 00000000
0x40004810 : 00000000 00000000 00000000 000000C0
0x40004820 : 00000000 00000000 00000000

Now, here is the register dump after putting the STM32 into bootloader mode but not sending anything to any of the ports. (omitting the command line and header for brevity):

0x40011000 : 0000140D 00500000 00000000 00000000
0x40011010 : 00000000 00000000 00000000 006000D0
0x40011020 : 00000000 00000000 00000000
 
0x40004400 : 0000140D 00500000 00000000 00000000
0x40004410 : 00000000 00000000 00000000 006000D0
0x40004420 : 00000000 00000000 00000000
 
0x40004800 : 0000140D 00500000 00000000 00000000
0x40004810 : 00000000 00000000 00000000 006000D0
0x40004820 : 00000000 00000000 00000000

Finally here are the registers after sending 12 lots of 0x7F to USART2 RX (PA3):

0x40011000 : 0000140D 00500000 00000000 00000000
0x40011010 : 00000000 00000000 00000000 006000D0
0x40011020 : 00000000 00000000 00000000
 
0x40004400 : 0000140D 00500000 00000000 0000022D
0x40004410 : 00000000 00000000 00000000 006080F8
0x40004420 : 00000000 0000017F 00000000
 
0x40004800 : 0000140D 00500000 00000000 00000000
0x40004810 : 00000000 00000000 00000000 006000D0
0x40004820 : 00000000 00000000 00000000

It can be observed that USART2 seems to have been configured and indeed there seems to be a 0x7F in the USART2 RDR register low byte. However if I send other data like 0xA5 I still see the RDR set to the same value (0x0000017f). So... what is going on? I get no response from the USART2 regardless of what data I send. @Imen DAHMEN​ Can you please get an ST dev to take a look at this? I'm blocked on this and it is looking like a bootloader bug.

[FColl.1]

I just checked again and I can see the 0xA5 appearing in the RDR. So it looks as though USART2 is definitely receiving the data I'm sending. I do not see any toggling on the PA2 pin. I'm monitoring it with an oscilloscope set to trigger on falling edge. The line stays high the whole time. Perhaps the TX is on another pin?

[FColl.1]

I went through the registers for the USART2 and all the configuration and status makes sense that it has been configured correctly, autobaud detected and received my data. Additionally I went through the GPIO config registers and confirmed that the AF MUX is set to USART2 for PA2,3

0x58020000 : AA82AAAF 00000100 CFC3FFF0 24000000
0x58020010 : 0000600C 00000000 00000000 00000000
0x58020020 : 55557700 600AA004

[FColl.1]

I dug out an old Nucleo-H753ZI board and ripped of the relevant SB zero ohm resistors for PA2 and PA3. I jumpered boot0 to 3v3 and reset it. I used a usb virtual com port (115200 8e1) to send 0x7f to the Nucleo's STM32H753 and it responds as expected; 0x79 for the first 0x7f sent and then a 0x1f for every two 0x7f sent after that. The STM32 on the nucleo is rev V bootloader 0x90.

The USART 1,2,3 registers are:

0x40011000 : 0000140D 00500000 00000000 00000000
0x40011010 : 00000000 00000000 00000000 006000D0
0x40011020 : 00000000 00000000 00000000
 
0x40004400 : 0000140D 00500000 00000000 0000022B
0x40004410 : 00000000 00000000 00000000 006090D0
0x40004420 : 00000000 0000017F 0000001F
 
0x40004800 : 0000140D 00500000 00000000 00000000
0x40004810 : 00000000 00000000 00000000 006000D0
0x40004820 : 00000000 00000000 00000000

This is a different variant in a different package but it indicates that we must be doing something wrong which is causing the bootloader on our board to choose the wrong port. Can someone from ST confirm that the bootloaders for the 743 and 753 are binary identical?

[waclawek.jan]

In debugger, write to the USART Tx data register and observe the pin in question.

JW

[FColl.1]

Thank you for the helpful suggestion.

I ran..

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -w32 0x40004428 0x000000a5

And I can see 0xa5 received in the terminal program I'm using. So the port is active as expected.

[FColl.1]

I've worked through all the pins listed in AN2606 to check their states when we are in the bootloader.

I don't think it is accidentally picking up and locking to another port.

USB DFU

PA11 - Low

PA12 - High

USART1

PA9 - Low

PA10 - Low

PB14 - High PB14,15 are used in out app for USB+- I fitted a plug that has pull up resistors and no connection to a host to prevent and toggling on these lines.

PB15 - High

USART2

PA3 - Rx sending 0x7F 115200 8e1

PA2 - Tx no reply. Can get data to send by using STLink to set USART2_TDR

USART3

PB10 - NC - Not a problem as this is an output

PB11 - NC - This is potentially a problem if noise causes a toggle on this line. I have tried putting a pull down on this and it did not help. The evidence from looking at registers is that USART1 and USART3 do not receive data and baud detect.

I2C1

PB6 - High - Connected as i2c clock for devices on board

PB9 - 0.5V - connected to base of a BJT

I2C2

PF0 - Unconnected - Grounding did not help

PF1 - Unconnected - Grounding did not help

I2C3

PA8 - High

PC9 - Low - Pull down

SPI1

PA4 - Low

PA5 - Low

PA6 - Low

PA7 - Low

SPI2

PI0 - Unconnected - Grounding did not help

PI1 - Unconnected - Grounding did not help

PI2 - Unconnected - okay as it is output for bootloader

PI3 - Unconnected - Grounding did not help

SPI3

PC10 - Unconnected - Pulling down did not help.

PC11 - Low

PC12 - Low

PA15 - Low

SPI4

PE11 - Unconnected - Grounding did not help

PE12 - Unconnected - Grounding did not help

PE13 - Unconnected - okay as it is output for bootloader

PE14 - Unconnected - Grounding did not help

FDCAN

PH13 - Unconnected - Pulling down did not help.

PH14 - Unconnected - Pulling down did not help.

[FColl.1]

I finally got the Rev V (Bootloader 9) STM32H743 talking on the USART2 port. We had to mod our board to put all the pins mentioned in AN2606 into a safe state. It seems that the move to bootloader 9 from bootloader 13 has made it more sensitive to noise on the pins it watches.

If you are listening ST, this bootloader design is terrible. Normally a bootloader samples a handful of pins to decide which port is enabled so the designer only has to consider and manage the state of those pins. In your design the designer has to take account of the state of over 30 pins! There is no way to diagnose which of these 30 pins is causing an issue other than trial and error.

It is possible to get information about the state of the bootloader by reading the PC, but without disassembling the bootloader this is not helpful. I recommend that ST publish the linker map and source for the bootloader so that programmers can diagnose issues more readily.

[FColl.1]

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.]

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]

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.