STM32: DFU bootloader not wokring

[TheHolyHorse]

Hi all.

So I've been working on a project with a STM32F373 which I was gonna program through USB. Problem is it's not detected in windows(10), well it's detected as a usb device but it gives me a "device descriptor request failed" error. I've tried manually installing the "STM Device in DFU Mode" driver but nothing seems to work.

BOOT0 pin is pulled high, I know it enters some other mode when it's pulled high because I have some LEDs hooked up and some start lighting up when booting with BOOT0 high. D+ is pulled high through a 1.5k resistor according to the datasheet. I've been reading through datasheets, manuals and google searches but I can't find anything that will help me.

I'm completely lost 

[lucazader]

Try having a look for the zadig USB driver that people recommend for using with DFU on windows.

From memory the DFU implementation used in ST's windows software uses libusb, and if you don't use zadig (or similar) to force the driver to use libusb then it quite often doesn't work,

[oPossum]

Device descriptor request failed typically means that the USB device was detected due to the 1.5k pullup resistor, but there is no communication with the device. The device descriptor is the first request that is made and it is failing. This could be a wiring error or the bootloader is not USB or there is hardware missing that it needs such as a crystal.

[TheHolyHorse]

I've measured and confirmed that everything is connected. The STM32F373 runs of it's internal oscillator if no external clock is present. According to the datasheets and manuals the device has a DFU bootloader which is enabled.

[Psi]

Most USB devices need an input to use for usb Vbus detect.
So the mcu knows when usb is plugged in and when to start talking.

Have you looked at the stm32 datasheet/USB DFU app notes for how you're supposed to do USB vbus detection on the STM32?
From what you have said it sounds like the STM32 doesn't know USB is connected.

EDIT: Looks like VBUS detect input isn't needed for USB DFU


Also, just FYI i have noticed with some STM32 and UART BOOT modes that, not only do you need to set BOOT pins correct, but you also need to trigger a RESET yourself.
ie they don't always seem to startup in boot mode from a cold power on with boot pins correct.

Also, you mention boot0, have you got boot1 set correctly too?

[TheHolyHorse]

Most USB devices need an input to use for usb Vbus detect.
So the mcu knows when usb is plugged in and when to start talking.

Have you looked at the stm32 datasheet/USB DFU app notes for how you're supposed to do USB vbus detection on the STM32?
From what you have said it sounds like the STM32 doesn't know USB is connected.

EDIT: Looks like VBUS detect input isn't needed for USB DFU


Also, just FYI i have noticed with some STM32 and UART BOOT modes that, not only do you need to set BOOT pins correct, but you also need to trigger a RESET yourself.
ie they don't always seem to startup in boot mode from a cold power on with boot pins correct.

Also, you mention boot0, have you got boot1 set correctly too?

I've tried triggering resets or just unplugging the power nothing makes a difference. About boot1 I've no way of checking, it is supposed to be set would be pretty useless to ship chips with bootloaders that the user can't access.

[Psi]

i mean there are two boot pins, BOOT1 and BOOT0

If you are trying to use BOOT0 pin to enter DFU bootloader but have left BOOT1 floating that might be the problem.

[r0d3z1]

I am not sure that Vbus is not needed, could you try to connect it ?

[TheHolyHorse]

i mean there are two boot pins, BOOT1 and BOOT0

If you are trying to use BOOT0 pin to enter DFU bootloader but have left BOOT1 floating that might be the problem.

There's no BOOT1 pin one the F373, it is however a nBOOT1 bit in the option bytes(or somewhere don't remember).

I am not sure that Vbus is not needed, could you try to connect it ?

There's no dedicated VBUS pin on the F3 series and it doesn't really explain how to do vbus detection on chips that don't have it. I've tried having the 1.5k pullup on the vbus line to pull it high when I connect the cable, but nothing has worked so far.

[Psi]

Yeah, sorry, i thought your one had boot1 but it doesn't.

I did notice it has a VBAT pin for battery backup.
Maybe it wont enter bootloader without that? (unlikely but worth checking)

Also confirm you are feeding power to all VCC pins and ground to all GND pins.
If you happened to miss one then parts of the chip may not have powered on

[Psi]

Also check you have good grounding between MCU and PC USB.

It's easy to get confused and accidentally wire the USB cable shield pin to MCU ground instead of the actual USB GND pin.


Also when messing around debugging USB non-detention issues you can occasionally get the USB stack into a weird state that requires a full computer power off/on to clear.
So it's possible to actually fix a problem but not know you fixed it until after a full PC power off/on.

[TheHolyHorse]

Yeah, sorry, i thought your one had boot1 but it doesn't.

I did notice it has a VBAT pin for battery backup.
Maybe it wont enter bootloader without that? (unlikely but worth checking)

Also confirm you are feeding power to all VCC pins and ground to all GND pins.
If you happened to miss one then parts of the chip may not have powered on

VBAT is connected to 3.3v and I have power to all the other power pins as well

[Psi]

Failing all that i do recall an issue when DFU flashing STM32 based drone flight controllers in windows.

The issue was a rouge windows driver claiming control over the device and it didn't support DFU so DFU was never detected.
Solution was to run a tool called Zadig to remove the bad driver.

I don't know if this is relevant to your issue and I don't recall all the details but this thread seems to show how you to use Zadig to get DFU working for drones

https://www.dronetrest.com/t/zadig-drivers-for-cleanflight-betaflight-stm32-flight-controllers-dfu-mode/2719

[TheHolyHorse]

Failing all that i do recall an issue when DFU flashing STM32 based drone flight controllers in windows.

The issue was a rouge windows driver claiming control over the device and it didn't support DFU so never worked.
Solution was to run a tool called Zadig to remove the driver.

I don't recall all the details but this thread seems to show how you to use Zadig to get DFU working for drones

https://www.dronetrest.com/t/zadig-drivers-for-cleanflight-betaflight-stm32-flight-controllers-dfu-mode/2719

I don't think it's a driver issue, it simply can't talk to the mcu at all. But i'll try the zadig thingy I could very well be wrong.

[Psi]

yeah, i agree it seems more like STM32 not responding to PC's USB requests,  i'm just out of other ideas.

Have you tried powering on the STM32 in BOOT/DFU mode without the USB cable. Then waiting 10 seconds to make sure STM32 is all started up and then connecting the USB cable?
Maybe windows is giving up to soon and the STM32 isnt ready?

[TheHolyHorse]

Zadig fails as well says resource already exist, but since the first thing that pops up in device manager when connecting it is "Unknown USB Device (Device Descriptor Request Failed)" I'm not too surprised.

Maybe the mcu is just dead or something, but I really don't feel like removing it and soldering another one

[Psi]

Did you buy the chip from a known good source or from aliexpress/ebay.

Maybe it's already programmed/locked or has DFU disabled.

[Jeroen3]

The STM32F373 runs of it's internal oscillator if no external clock is present.

Universal serial bus (USB)
The STM32F373xx embeds an USB device peripheral compatible with the USB full-speed
12 Mbs. The USB interface implements a full-speed (12 Mbit/s) function interface. It has
software-configurable endpoint setting and suspend/resume support. The dedicated 48
MHz clock is generated from the internal main PLL (the clock source must use a HSE
crystal oscillator).

Internal oscillators are note accurate enough for USB.
There are a few STM32 chips that have Crystal-less USB (STM32F0x2) but the F3 is not one of those.

[Psi]

Well i suspect that has answered the question.

[Jeroen3]

If you calibrate the internal oscillator you might get it to work on your desk.

[TheHolyHorse]

The STM32F373 runs of it's internal oscillator if no external clock is present.

Universal serial bus (USB)
The STM32F373xx embeds an USB device peripheral compatible with the USB full-speed
12 Mbs. The USB interface implements a full-speed (12 Mbit/s) function interface. It has
software-configurable endpoint setting and suspend/resume support. The dedicated 48
MHz clock is generated from the internal main PLL (the clock source must use a HSE
crystal oscillator).

Internal oscillators are note accurate enough for USB.
There are a few STM32 chips that have Crystal-less USB (STM32F0x2) but the F3 is not one of those.

   well that makes sense, how could I miss that. I had a feeling I missed something major, everything was going to easy.

Anyway thanks for all the help