DFU Mode Help

I have a project that is dependent on the GHI Cerbuino Bee board. Since this board is no longer available I decided to put the STM32F405 on my own PCB. I copied most of the schematic for the Cerbuino in terms of the pins I thought were required to place the device into the ST Micro DFU mode.

On power up of my new board with BOOT0 high and BOOT1 low. and connected via USB, my computer does not see any USB devices attached. Not even an unrecognized device.

So I suspected it must be the crystal but I used one with the same specifications as the on on the cerbuino board. I also used the same decoupling caps. I do notice the crystal pins have a voltage spike when releasing reset while holdiing down the LDR, but the crystal never starts oscillating.

So then I questioned whether a virgin STM32F405 actually has a bootloader in it.So I looked through the STM specs and found the bootloader is also supposed to respond on the serial port. I connected a serial port and continuously sent 0x7F while reseting with boot0 high and it actually responded.

I then found a STM serial firmware updater and used this to upload tiny_booter into this device through the serial port. It worked and was very surprised that my PC immediately detected the cerb-familty device on the USB port.

Now when I looked at the crystal it is oscillating correctly at 12mhz.

So, a long winded preamble to my question, why would the ST DFU device not show up in device manager when I enable the built in bootlader. Is there something special you need configured in terms of I/O pins?

When I hold down LDR and release reset on my Cerbuino bee boards, my PC immediately detects a device in DFU mode so I know my device drivers are installed correctly.

Could it still be an issue with crystal startup times? Would the GHI firmware be more tolerant to PLL stabilization times than the ST bootloader?

After powering the board you need to release BOOT0 from being high which will then place it in DFU mode.

I am releasing boot0. I have two push buttons, reset and boot0.

I hold them both down resetting the processor and applying 3.3v to boot0. I then release reset and shortly after release boot0 to ground

Without the Ghi boot loader installed nothing would happen. No usb device detection of any kind.

With the ghi boot loader installed nothing happens until I release boot0. Then the carb-family device shows up. Not the dfu device I am expecting.

A virgin STM will show up as in DFU mode out of the factory with the correct pullup/downs on Boot0 and Boot1

Have you got a pickie of your schematic?

1 Like

What level have you got PA10 (pin 43) connected to? I recall having to ensure this was HIGH to get USB bootloader to work.

I have it pulled high.

_

What happens if you hold boot0 down for ~30-60sec after reset, does it go into DFU mode?

I had a 405 design once that would only go into DFU mode after holding down boot0 for what seemed like an eternity.

If I hold it down for 30 seconds evetuauly a Windows message pops up saying a USB device has malfucntioned and can not be recognized.

As soon as I release boot0, it immediatley shows up in device manager as Cerb-Fmily

Interesting, something is defo wrong as releasing boot0 should say dfu mode…

I shall mull some more.

Reinstall STM32 Loader driver or install it if not installed yet.

Can you test it on another USB-port? A have a USB-hub that doesn‘t work with a STM in DFU-Mode (mostly, sometimes it works :man_shrugging:t2:)…

I have tried multiple USB ports and multiple computers. Doing the same process with a Cerbuino Bee brings up the DFU device immediately so I doubt its the device drivers.

Like I mentioned in my original post, the 12Mhz Oscillator never starts and from what I have ready you can not get any USB activity without this external oscillator running. So I still feel is something to do with the crystal. Its just odd that is runs fine with the GHI code loaded.

try with Serial Port if you can. Serial Port should work even no external crystal. Try both cases with/without USB connection.

If serial work fine meaning likely something wrong with crystal.

The Uart does work, that is how I installed the GHI firmware on the device. Its just very cubersome for me to do it this way. I would really like to get the DFU mode working.

I just built 4 more boards. DFU mode does not work on any of them.
I used STs RS232 Flash loader to installed Tiny Booter 4.3.8.1. This worked on all the boards
Used FEZConfig to load the GHI firmware on all boards.
Loaded my application and can debug through VS on all boards

All boards run fine in application mode, Crystal runs as expected.

But sadly no DFU functionality.

Did you try holding done BOOT0 for a looooooooooong time?

We too have this same issue it shows a message as STdevice in DFU Mode for G80’s purchased from Mouser August 2019

See my answer to your previous post

I have the same issue of santhosh, I bought some G80’s from Mouser the last 30th of august, All the units seem to be blank
I have the same issue of santhosh, I bought some G80’s from Mouser the last 30th of august, All the units seem to be blank, there is no bootloader pre loaded. Can you tell me what can I do? Can you redirect me to the response you are talking about? Thanks

I have responded to your other thread. We will help you ASAP