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?