STM32F413VGT6 does not enter DFU on USB

[FBaev.1]

Hello!

Prehistory:

USB DFU works flawlessly on another my design which is based on the STM32H743ZGT6.

When it is powered on with BOOT0=1, I measure 3.3V on the USB_DP processor pin with a USB cable disconnected from the board.

Problem:

There is a USB DFU issue on the design based on the STM32F413VGT6.

Facts for a power-on with BOOT0=1 (jumper X10 is not installed):

1) USB_FS_DP voltage is about 0.2V

2) the processor is not discovered as DFU when USB cable is connected to a PC

3) R200 was replaced with 51 Ohm - no change in behaviour

4) test firmware implements blinking LED, so when BOOT0=1, it is definitely is not executed, because the LED is off.

When BOOT0=0 and test firmware configured USB as DFU, after power-on I measure 3.3V on the USB_FS_DP signal.

[Uwe Bonnes]

Check the decision tree (34.2) in the F413 section of AN2606 if something on another pin keeps the bootloader from reaching DFU.

[FBaev.1]

Dear Uwe Bonnes,

Thank you for the response.

I've already looked into the section 35.2 of the AN2606.

There is no active host on any interface mentioned in the "Table 74. STM32F413xx/423xx configuration in system memory boot mode".

Is it possible to debug the issue?

[Uwe Bonnes]

Do you have debug access via JTAG or SWD? Hot plug the debugger to the hanging process and read out registers and try to decipher what is going wrong.
Did you have a look with the scope? Is HSE running? Is it  a simple frequency? Is it in the low range as suggested by the note under table 71? What happens on the PC when you connect to DFU mode? Is the USB_DP pullup activated? Did you doble check the design? No solder or placement errors?

[FBaev.1]

Dear Uwe Bonnes,

You wrote:

> Do you have debug access via JTAG or SWD?

In case STM32F413VGT6 has BOOT0=0 - yes.

In case STM32F413VGT6 has BOOT0=1 - no.

> Hot plug the debugger to the hanging process and

> read out registers and try to decipher what is going wrong.

Please see above.

> Did you have a look with the scope? Is HSE running? Is it  a simple frequency?

Yes, everything is OK.

> Is it in the low range as suggested by the note under table 71?

Please see previously attached picture.

Please note that STM32H743ZGT6 design has 25 MHz crystal - nevertheless USB DFU works flawlessly.

Even if the issue could be connected with the crystal frequency, this cannot explain the observation that USB_FS_DP pull-up is not activated.

> What happens on the PC when you connect to DFU mode?

In case of STM32F413VGT6 having BOOT0=1 - nothing.

> Is the USB_DP pullup activated?

In case of STM32F413VGT6 having BOOT0=1 - no.

> Did you doble check the design? No solder or placement errors?

The design works flawlessly with a dedicated firmware. The issue is only with DFU behaviour when BOOT0=1.

[Uwe Bonnes]

There is nothing that disallows debug access with BOOT0=1 . You have no source code, but you can still stop and query registers, RAM and flash.

Matching the crystal frequency is needed for the bootloader to try DFU. No match, no DP pull. Perhaps look with a scope on OSC_OUT for HSE startup, check for larger variation against 25.0000xx Mhz or try another crystal e.g. with 8 MHz.

[FBaev.1]

Dear Uwe Bonnes,

You wrote:

> you can still stop and query registers, RAM and flash.

What exactly should I look for or check?

> Matching the crystal frequency is needed for the bootloader to try DFU. No match, no DP pull.

The last statement definitely is incorrect.

I've intentionally configured internal clocking so incorrect frequency (not 48 MHz) was applied to the USB module and in all cases USB_FS_DP pull-up was activated (of course the USB device was not discovered in this case).

[Uwe Bonnes]

You can check GPIO state, RCC state  and USB state. Not easy and requires a lot of reading in the reference manual.

Did you check PB2/BOOT1. Maybe 33k is too high value to keep at '0' on startup.

[FBaev.1]

Dear Uwe Bonnes,

Any chance to escalate the issue to the factory?

You wrote:

> You can check GPIO state, RCC state  and USB state.

What exactly should I look for and how it could give a clue to the issue cause?

> Did you check PB2/BOOT1. Maybe 33k is too high value to keep at '0' on startup.

From the original problem description:

"3) R200 was replaced with 51 Ohm - no change in behaviour".

Also, in the MB1137 design (https://www.st.com/en/evaluation-tools/nucleo-f413zh.html#cad-resources) 100 kOhm resistor is used.

[FBaev.1]

Dear Uwe Bonnes,

Any chance to escalate the issue to the factory?