Skip to main content
Visitor II
April 15, 2020
Solved

DFU over USB not working - HSE not detected?

  • April 15, 2020
  • 8 replies
  • 6203 views

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:

0693W000000VsDVQA0.png

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:

0693W000000VsE9QAK.png

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.

    This topic has been closed for replies.
    Best answer by Martin Pesek

    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!

    8 replies

    Super User
    April 16, 2020

    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

    Visitor II
    April 16, 2020

    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:

    0693W000000VuplQAC.png

    0693W000000VupvQAC.png

    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).

    Visitor II
    April 18, 2020

    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?

    Super User
    April 19, 2020

    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.

    Visitor II
    April 23, 2020

    Thank you for the suggestions.

    Removing 1k5 resistor did not help this issue.

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

    Super User
    April 23, 2020

    How many PCs and cables did you try?

    JW

    Visitor II
    April 24, 2020

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

    Visitor II
    April 30, 2020

    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.

    Visitor II
    May 7, 2020

    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?

    Super User
    May 7, 2020

    Yes, but you've told us you tried several different PCs...

    On Linux, at least, the DFU device should show up in lsusb...

    JW

    Martin PesekAuthorAnswer
    Visitor II
    May 11, 2020

    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!

    Graduate
    July 12, 2021

    it was the difference between 427 working and 407 not working in DFU for us https://community.st.com/s/question/0D53W00000wyoGESAY/f4-sporadic-reset-into-dfu-and-dfu-jump-any-links-between-power-and-dfu

    we believe it's about the oscillator taking too long to start and DFU procedure resetting