STM32H743 DFU Entry doesn't work unless BOOT0 held high at power-on

[MKenn.1]

I'm having trouble entering the DFU bootloader on my H743 (rev V).

power on (with BOOT0 high) -> USB DFU functions as expected

power on (with BOOT0 low) -> application functions as expected

reset (with BOOT0 low) -> application functions as expected

reset (with BOOT0 high) -> DFU bootloader doesn't work

jump from application to DFU -> DFU bootloader doesn't work

I've tested this behavior both on a custom board (H743ZI rev V), and on a Nucleo-H743ZI2 with the same results. If I break in to the debugger in either of the not-working scenarios, I can see the program counter is in the bootloader's code somewhere, so it *is* jumping in, but USB doesn't work.

Jumping from application to bootloader works fine with the same application running on various F4 and F7 devices, but doesn't work on the H7.

 What's going on? Why can't I enter the bootloader except at power-on?

[TDK]

> reset (with BOOT0 high) -> DFU bootloader doesn't work

This works fine on my H743ZI2 nucleo board. I suspect something else is going on.

[MKenn.1]

> This works fine on my H743ZI2 nucleo board. I suspect something else is going on.

Really? Pushing the reset button with a wire from BOOT0 -> 3.3v resets in to the bootloader? How could that work *sometimes*?

[TDK]

Yes, really. Could be a poor connection from the wire, such that it doesn't pull the pin up. Could be a bad USB cable. Could be the PC ignores the device due to what it previously did on the port.

[MKenn.1]

I can pretty much rule all those out. I know it's actually entering the bootloader (wire/button works fine), since I can break in in the debugger and see it running.

Likewise, I'm sure the cable is fine because USB works fine while running the application (ie, not bootloader). PC isn't ignoring it due to something previous, because I can power on the device, reset to DFU, then connect USB, and the behavior is the same. dmesg shows no new USB device.

[TDK]

I don't know what the problem is, but it does work on my H743ZI2 board without issue on Win10. It doesn't appear to be a hardware issue. My guess is something funny going on on the PC side. If you have another machine, I would test on there. OS is probably relevant here.

[MKenn.1]

I've tried on 3 different PCs, two Windows and one Linux.

I did a bit of reverse engineering with Ghidra + GDB, and there's a function with a big loop that checks, in sequence:

• FD-CAN
• I2C1-3
• SPI1-4
• Check if something is happening on the RX bit in GPIOB - USART1 alternate mapping (if so, switch the alternate function mapping for USART1 to PB14/15)
• USART1-3
• Check if a struct in RAM contains a particular value (USB :))

(curiously, this doesn't match the order of checks in AN2606 :o)

In the USB OTG interrupt, that same struct in RAM is set to contain the "cable present" value. But that condition is never happening, so USB isn't getting initialized for whatever reason.

[MKenn.1]

Some fun facts:

• The H7 bootloader is implemented using ST HAL (functions and structs match exactly), but the older F4/F7 bootloaders are not.
• This H7 bootloader was probably compiled with optimization either disabled, or maybe at -Og, which seems like an oversight. Even trivial single-instruction functions didn't get inlined.

[TDK]

Makes sense as F4/F7 predate HAL.
It’s interesting that ST itself is using HAL. I guess that’s a good thing overall?
Thanks for sharing.

[MKenn.1]

The plot thickens! I disabled USB in our application, so now it can't talk to the PC, but it's still fully alive. Created a thread that just waits a few seconds, then reboots to DFU (one of the things that didn't work before). Reset-to-DFU now works just fine. What the heck ST? A system reset is supposed to reset the system as if you'd powered it on, right? How is state spilling around a reset?