DFU over USB not working - HSE not detected?

Martin Pesek · ‎2020-04-15

Hello all, I am currently unable to solve this issue:

I use STM32F401RET6 with USB functionality (COM port). USB works just fine when in normal runtime, but I am unable to reach the DFU.

I think that for some reason the HSE is not detected or some other fault happens in the bootloader. When I pull the BOOT0 to 3V3 on start, the normal program does not start, which is good. But when I plug in a USB cable, device gets reset and starts in normal mode and not DFU.

I have tried accessing the DFU using USART1 and it seems to connect OK. According to the AN2606, it would seem that the HSE is not detected:

However, the HSE probably works just fine when running in normal mode as USB CDC works and I am able to communicate using a terminal with USB COM port.

I use 8 MHz HSE:

The device may be powered both from the USB or external power jack.

Does anyone have ideas how to advance, what to test or how to resolve this? Thank you.

Martin Pesek · ‎2020-05-11

Thank you all for many tips and your help. I will now share how I resolved this issue.

tl;dr I changed from the STM32F401 to the STM32F446, which works.

No layout or design changes were performed, I literally only interchanged these two MCUs and now, it works like wonder. The STM32F401RE would sometime at least try to enumerate as a STM32 Bootloader when connected under a some sort of frequency value of external crystals (very strangely 5 MHz iirc). This probably points to a HSE-related issue, but that's all I know (might be related to PCB layout, startup time, stability - only my guesses).

I had some issues when the STM32F446 DFU Device would keep connecting and disconnecting but after some analysis this was caused only by bad contacts caused by bad soldering.

As Jan correctly suggested, definitely make sure to have a solid cable, solid connectors (both PC and your PCB) and good soldering joints!

View solution in original post

waclawek.jan · ‎2020-04-15

Don't you by any chance have a "known good" board on which DFU works ('F401 DISCO, but that's probably very rare as ST withrew them early in favour of the 'F411 DISCO, see comment in https://www.mikrozone.sk/comment.php?comment.news.1227 and links there).

How fast does the 8MHz oscillator start in your application? Could R21 have impact on this startup time?

Could you use, just as an experiment, an external oscillator?

The bootloader determines the crystal frequency against HSI - measure how precise HSI is.

Can't the bootloader falsely start using other interface, due to activity on some of the pins observed by the bootloader?

How exactly is the USB connector connected, what could it impact? What happens if you connect a USB charger instead of PC?

JW

Martin Pesek · ‎2020-04-16

Thank you Jan, I will try your suggestions and return with more info.

I only have NUCLEO-F401RE, I might be able to try it there with some hacks.

I tried shorting R21 but it seemed to have no effect. The connection of USB is following:

I already tried shorting the 22 Ohm resistors and removing the 1k5 pullup, but no visible effect.

When I connect the device first to power jack, then the usb charger, it seems to stay in bootloader (normal code does not start). Interestingly, when I reconnect the USB cable to PC, it is not recognized in Windows (almost immediately a error pops up).

Martin Pesek · ‎2020-04-18

Tried many different crystal oscillator frequencies. Sometimes when using 5 MHz or 16 MHz the device shows up in Windows' Device Manager as "STM32 Bootloader" but with a warning sign and doesn't really work with DfuSe. I don't think there is interference with other peripherals such as SPI, USART or I2C because when I connect a power jack, the device is in BOOT mode and normal program does not start.

Many things now seem to point to bootloader badly calculating frequency or not detecting HSE.

I tried soldering crystal to NUCLEO-F401RE with capacitors, shorting paths to MCU but no luck there either, device immeadiately shows as unrecognized.

Any suggestions except writing own bootloader?

TDK · ‎2020-04-18

The 1K5 resistor is not necessary as the MCU has the necessary built-in resistors. It is possible this is causing the issues.

I have an STM32F411 with an 8MHz crystal using the DFU bootloader without issues.

If you are jumping to the bootloader rather than resetting into it with BOOT0=1, be aware that you need to deinitialize the USB first, otherwise it will not work correctly.

Also be aware STM32CubeProgrammer may give better results than the DFUSE.

If you feel a post has answered your question, please click "Accept as Solution".

Martin Pesek · ‎2020-04-23

Thank you for the suggestions.

Removing 1k5 resistor did not help this issue.

I am trying only resetting with BOOT0 = 1 so far.

waclawek.jan · ‎2020-04-23

How many PCs and cables did you try?

JW

Martin Pesek · ‎2020-04-24

Thanks, tried 2 different cables and 3 different PCs with 3 different OS (Win 10, 8, Ubuntu). The issue is always the same.

gary239955 · ‎2020-04-30

Hi Martin, I think I'm having the same problems as you. I'm using a 25MHz crystal with 390R resistor. I go into DFU mode by charging a capacitor on BOOT0, then let the watchdog reset. This works fine. Like you, I do not boot from flash. But DFUse does not see it. I'm using an ST32F205. I used to use an ST32F105, and I had it working on that system with a similar crystal. I'll let you know if I get anywhere.

Martin Pesek · ‎2020-05-07

Thanks Gary, wishing you luck!

I encountered a very strange behaviour today when I resoldered the MCU to STM32-F446RC due to project extension.

When I connected the newly soldered MCU to USB withh BOOT0=1, DFU loaded up with no problem, I was able to access it in STM32CubeProgrammer and connect to it.

But then tried connecting over SWD using other NUCLEO as a programmer. That was also okay. In Windows a message simultaneously popped up about Installing drivers. However, then I disconnected the device and tried the DFU again and it doesn't work!

No restarts of any devices helped anymore. Could this point to some sort of drivers issue maybe?