Why STM32H743ZI DFU bootloader does not come up?

[martin.k]

Hell ST community!

I have made a board with an STM32H743ZI MCU on it. It has connections to pins where serveral USART peripherals sit (without pull-ups) and uses USB FS on PA9 to PA12.

My problem is that the DFU bootloader does not show up via USB. If not tested USART yet, but as there are no external pull-ups it think it wouldn't work either.

Not showing up means:

• It does not come up after the designated software reset procedure
• It does not come up on it's own with the BOOT0 pin pulled high
• If I have the BOOT0 pin pulled high, power the system on, connect with a SWD debugger and reset the system with ST-Link (function System-Rest in Target->MCU Core), the DFU mode via USB comes up

Normal boot to my firmware works and the firmware runs fine as well. I just have the problem now, that I cannot make field updates without the DFU working.

What can be the problem here?

Might the bootloop Do I need external Pull-Ups on every RX pin used in the bootloader mode?

Or could it be that it receives "something" over SPI1? I have connected some analog cicuitry to the related pins. But still, why does it come up then if I reset the system with STlink again?

Any help is really appreciated.

Thank you in advance,

Martin.

[Tesla DeLorean]

How quickly does your external clock/crystal start/stabilize?​

[martin.k]

Ugh... This is really hard to say. It's an 25 MHz crystal from Abracon: ABM3-25.000MHZ-D2Y-T with 18pF load capacitors.

Do you think TIM17 measures the wrong frequency, due to a longer startup delay? But, shouldn't this wait for stable conditons? And if it is the crystal, why it does not work when I jump to SystemMemory from my application?

[martin.k]

It's a really weird problem... At least I made a little progress:

Frist of all, I've measured that start up delay. It's between 2 and 3ms, if the HSE starts. I say "if it starts", beacause the bootloader obviously does not enable it.

If I power on without the BOOT0 jumper, my firmware runs fine and HSE is of course on.

If I power on with BOOT0 high HSE is off. Within that state doing a "System Reset" with STlink does indeed lead to a running HSE. Does the debugger force the HSE on somehow?

If I run my firmware and go through software reset and jump to system memory, HSE is off as well.

According to AN2606 HSE is only used if DFU is selected. So either there is a bug in the booltoader, which I think is not very likely. Or one of the other peripherals is selected. But, I do not know why yet. I do suspect the SPI1 peripheral, but I'm not sure about this.

Looks like I have to implement my own bootloader based on the DFU application example :\

[Tesla DeLorean]

The HSE is off by default. I don't think the debugger would enable it, it has little need for it, and doesn't know the frequency of the device placed. It will slow down the processor, and allow some code to execute as it wrestles control at start up.

The boot loader programs values into the RCC and can start the PLL/HSE, it being on before you call it would make no difference, it assumes it is off and likely writes default values which would cause it to stop, before going about it's business.

The boot loader has hard coded expectations about how quickly the HSE and PLL will start. In may of the STM32 there is a subset of supported frequencies. Or it will benchmark against the HSI and make a guess.

The boot loader is going to be sensitive to pin noise on those interfaces it is looking to receive connectivity on. See AN2602 for an enumeration. The USART particularly because it configures those as TIM inputs to measure the signature of the 0x7F data pattern to select the correct baud rate.

[martin.k]

I do know HSE is off by default and the RCC will be de-initialized before it is used. This is how the code is generated by CubeMX and I wouldn't expect it to be different in the bootloader.

However, it does not explain why it's not working...

According to AN2606 the bootloader sits in a loop until it detects sane data via USART, or a I2C addressing, or some SPI sync mechanism, or an USB cable plugged in. During this phase HSE is of and HSI is used, so it is clear why HSE is not coming up.

However, I'm wondering how that cable detect mechanism would work when the VBUS detect pin is not used and the USB peripheral is off (because the app not clearly states it turned on only after cable detection and HSE start-up.

I think it is very unlikely that any ohter peripheral receives any sane data out of nowhere, so I think we can exclude this. There must be something wrong with the cable detection.

[martin.k]

And the question remains: Why does it work when I do a "System Reset" with the STlink software. Where is the difference to a "NVIC_SystemReset" call and a "Power-on reset"?

Ohh, and executing that software reset from my firmware with a connected debuger doesn load the booloader either.

(Btw. I use your variant to jump into system memory: Clean DCache, Set special key, Reset, and then jump from the startup file. It's a very clean way, thank you for sharing that code)

[Tesla DeLorean]

I don't know that I can explain it without burying a whole lot of time/effort into the situation.

[martin.k]

It's okay. You already helped me a lot.

For now im okay with writing a custom bootloader. By using that DFU application example it wouldn't be so much effort, I think.