Enter UART bootloader at STM32H743XIH6 (Rev. X) fails

[SF??r]

Hello,

has anyone succeed with this task?

I run the UART also as CLI interface on PA9 and PA10. Documentations says, there is the UART bootloader on this pins. If I rise the boot0 pin at power up my application doesn't start. So I try use STM32CubeProgrammer and also terminal program to send 0x7F. (I checked all data on the line with a scope).

I got no answer. What could happen here? Is there special handling required because of the secure bootloader options?

I had never problems with STM32 bootloaders until now...

Thanks

Sebastian Förster

[SF??r]

I still stuck here.

Has anyone succeed with this task?

Sebastian Förster

[Tesla DeLorean]

Number of people using H743 Rev X probably pretty finite.

Would suggest discussing with local FAE assigned to your account, or filing an Online Support Request

[SF??r]

I will pull all RX Bootloader Pins of the (BGA) package to a defined level in the next hardware revision (like suggested). There is a large number and it would be great if the internal bootloader has some option bit settings to disable the loader at some interfaces.

Here is the list of pins that shouldn't be left floating if the bootloader is used:

PA10, PB15, PA3, PB11, PA7, PI3, PC12, PE14, PA11, PA12, PH14

[SF??r]

That's scary with this blackbox bootloader!!!

AN2606 says:

"It is recommended to keep the RX pins of unused bootloader interfaces (USART_RX, SPI_MOSI, CAN_RX and USB D+/D- lines if present) at a known (low or high) level at the startup of the bootloader (detection phase). Leaving these pins floating during the detection phase might lead to activating unused interface."

That implies that no internal pulls will be used, because pullup and pulldown could produce a mid level and undefined logic?!

But my measurement say other things... A lot of these pins are pulled internal. I could also see this behavior on the NUCLEO-H743. In bootloader mode (bridge boot0 to vcc and press reset) the user LED LD3 lights up!!

With this number of possible bootloader interfaces the bootloader is for most applications unusable...

Or did I get anything wrong?

best regards

Sebastian

[SF??r]

Okay!

Debuggung this H7 black box bootloader issn't funny.

Here are my results (on my special PCB design):

PA11 (USB - DM) should not be pulled to low level

PB15 (USART1, second pin option) should not be pulled to low level

STM has no information about this...

Reference manual misses the CAN bootloader pins at chapter: 2.6 Boot configuration

Result and outcome of my tests: Never ever use the STM32H7 bootloader in your final application, because you never know the required condition to came up with the loader.

If the bootloader cames up luckily STM32CubeProgrammer output is:

09:31:06 : STM32CubeProgrammer API v2.2.1
 
09:31:10 : Serial Port COM75 is successfully opened.
 
09:31:10 : Port configuration: parity = even, baudrate = 38400, data-bit = 8, stop-bit = 1.0, flow-control = off
 
09:31:10 : Activating device: OK
 
09:31:10 : Chip ID: 0x450
 
09:31:10 : BootLoader protocol version: 3.1
 
09:31:13 : UPLOADING OPTION BYTES DATA ...
 
09:31:13 : Bank : 0x00
 
09:31:13 : Address : 0x5200201c
 
09:31:13 : Size : 308 Bytes
 
09:31:14 : UPLOADING ...
 
09:31:14 : Size : 1024 Bytes
 
09:31:14 : Address : 0x8000000
 
09:31:14 : Read progress:
 
09:31:15 : Data read successfully
 
09:31:15 : Time elapsed during the read operation is: 00:00:01.564

Best regards,

Sebastian