Problems with getting an STM32F405RGT6 to enter DFU mode

[markr2]

Posted on January 27, 2015 at 03:18

I'm working with the STM32F405RGT6 on a custom board, trying to get the DFU mode of the ROM bootloader to work.  From my (very careful & repeated) reading of AN2606 and the STM32F4 Discovery schematic my design should enter DFU mode when I take it out of reset with BOOT0 high, BOOT1 low, and USB (but no other comms) connected, but it doesn't.

In order to explore the problem in a space in which I'm reasonably certain that no other hardware will interfere, I've assembled a small test board that mounts an STM32405RGT6, a JTAG port, a USB port, a /RESET button and a BOOT0 button. BOOT1 is pulled low and there are pullup/down (selectable as to which) 10K resistors on each of the GPIO's nominated in AN2606: PA10, PB5, PB11, PC11 (exception: PA10 has only a pulldown).  Operating voltage is 3.3V, I'm using an 8MHz crystal, and my dev environment is Keil Pro 5.12.  Using JTAG I can program the STM32 with a simple firmware build (a commandline console via a USB CDC Device implementation), so I'm satisfied that the MCU and the USB implementation are working perfectly well. If I hold down the BOOT0 button (driving it high) then cycle /RESET, the STM32 launches into the ROM bootloader.  I know that it's going into the bootloader because by debugging the MCU I can see that it starts not at the Reset handler but at 0x1fff3da0 (presumably the Reset handler for the bootloader) and as soon as I release BOOT0 the CDC device enumerates. I don't see how it can be related to firmware, because starting from an almost identical firmware build (a simple command line accessed via CDC VCP) running on an STM32F407 Discovery, I have no difficulties causing the Disco to enter DFU mode.  My suspicion is that there is something missing from AN2606 regarding hardware requirements for DFU in an STM32F405. To my actual question, then: What might I have missed, or what is missing from the documentation?

[Tesla DeLorean]

Posted on January 27, 2015 at 06:12

How fast does the 8 MHz start and stabilize? Does the behaviour change if you provide an 8 MHz source (oscillator, not crystal)?

The ROM benchmarks the clock to determine one of a number of acceptable rates, perhaps there is an issue there. It's also looking for pin transitions on the peripherals it supports, to identify which is being used. Can you talk to the System Loader via USART1 or USART3? If it's just USB that's the problem you'll need to focus on those pins.

[chekibapple]

Posted on February 25, 2015 at 19:15

Yes, some quartz may have a too long startup time and I had this issue in the past.

you just need to use a different quartz, maybe the one in the discoveryKit.But I think I don't agree with Clive about using an oscillator, because in that case, STM32 bootloader should have been configured with bypass option, and they don't say it in the AN2606, they only mention quartz.from my side, DFU bootloader has been working on F4 discovery kit just by setting Boot0 to Vdd and PB2 to Gnd.

[Tesla DeLorean]

Posted on February 25, 2015 at 19:40

But I think I don't agree with Clive about using an oscillator,

You don't have to agree, the purpose of the suggestion was to eliminate a specific class of failures, and not require a random set of parts being pulled from a draw that probably won't meet the device's requirement. It's a lot easier to build an external crystal circuit that DOESN'T oscillate properly than one that does. If you've failed at the task once, what are the odds you'll do it better the second time around? Bypass mode turns off the inverter/output path, not sure the system loader cares about the nature of the source, just that it clocks, and at some specific frequencies. When debugging a situation it is helpful to eliminate as many nodes from the failure search space as possible, so you can focus on what the problem really is. Edison once said he discovered a 1000 ways not to build a light bulb, but Edison was also an idiot when compared to the likes of Tesla.

[markr2]

Posted on March 03, 2015 at 00:55

Clive,

I've finally gotten back to this, and I can confirm that you were correct. I've done some surgery on my prototype board and swapped my crystal for the crystal from a Discovery - fun, because the Discovery uses a through-hole HC49 case and I used an SMT NX3225G.  Even with the Discovery crystal connected by short (~1cm) flying leads and with the wrong load capacitors, my board came straight up in DFU mode. Appreciate the advice. Cheers, Mark