STM32H7 ROM bootloader issue with factory units

[AAtan]

We found some STM32H743VIT6 devices shipped from the supplier are not able to be programmed over ROM bootloader. After programming with ST-LINK/SWD, ROM bootloader works fine and MCU is able to be programmed . Our bootloader interface is UART1.

Is there some ROM bootloader interfaces priority resolving policy ( I can't find such info in the docs) ?

Maybe some glitch on other peripheral interface, changes ROM bootloader focus out of UART1 and after flashing with ST-LINK that the glitch is not effective anymore ?!

Bootloader version is V9.0, protocol version is V3.1.

UART Baud rate is 57600.

The exact part number is STM32H743VIT6 , revision V, produced 2019/48th week.

[SF??r]

We have the same problem. The bootloader is different to other stm32 bootloaders we know so far. For example, the bootloader enables pull ups at some rx pins. Sounds like a valid idear, but not with a custom board design and without information what pins are pulled....

We managed the bootloader access problem by keeping USB bootloader pins free, no external pulls....

There is an open stm support ticket... but nothing happens for months here....

best regards

sebastian

[AAtan]

Hi Sebastian,

Thanks for sharing the same experience with us.

so, I guess, the ROM bootloader gets confused about state on the DP/DM lines on USB and expect bootloading from USB rather than from some other interface (UART in our case) ?

I still can't find how ROM bootloader resolves boot interfaces priorities so this is only an assumption.

The strange thing is that this issue doesn't appear for all devices we produce, but for some of them (MCU order codes and production batch dates are the same among them).

So the solution is to keep PA11/PA12 not pulled up ?

Regards,

Aleksandar

[SF??r]

The bootloader has strange behavior... best solution is to not use the bootloader.... you could write your own bootloader and download it to the other bootloader section and set the option bits for the entry addr.

I checked our data again. Also keep PB15 floating... but don't ask why... our solution was PB15 and PA11/12 keep floating...

[NMati.1]

I will strengthen the requirement on PA11: It must be logic high when you enter the bootloader. On two different PCBs with STM32H743VIT6 rev V silicon, I can control whether the USART3 bootloader responds by keeping port A in reset and shorting PA11 to 3.3V (success) or 0.0V (no response from bootloader). PA12 is unconnected on one of the boards so I haven't spent as much time examining that pin.

That said, PA11, and PB15 aren't the only pins which will prevent the USART3 bootloader from working, but I don't know what the others are. I've had to deal with a nondeterministic problem with the bootloader while bisecting for deterministic failures from pin state, so debugging is rather slow. It literally ended up being faster to write my own ST-compatible bootloader.

I'll also note that the problem(s) with the USART3 bootloader appear to be more fundamental. I modified the startup vector table of my BIOS to jump directly to the address pointed at by 0x1FF09804:

const void *const kStartupInterruptVectors[] __attribute__((section(".startup_vectors"))) = {
 [kInterruptInitialSpValue] = (void *)0x24003AF8, // Value taken from 0x1FF09800.
 [kInterruptReset] = (void *)0x1FF09ABD, // Value taken from 0x1FF09804.

With this change, no user code is executed; the bootloader runs immediately (with the caveat that the interrupt vector table offset is wrong). As before, holding PA11 high enables bootloading and PA11 low prevents the bootloader from responding. ...on the custom PCBs that I'm developing on. If I use either a NUCLEO-H743ZI (rev Y silicon) or a NUCLEO-H743ZI2 (rev V silicon), with a POF transceiver hooked up to PB10 and PB11 for USART3, bootloading simply doesn't work after powering up until I reflash the part with the ST-LINK (at which point the USART3 bootloader always works). From this, I'm inclined to conclude that the USART3 bootloader is just broken.