(STM32F411CE) Always in system bootloader when powering on

[Jeremy1]

I have a custom board which always enters the DFU USB system bootloader when powering on, even though BOOT0 & BOOT1 pins are driven to ground. After I load a simple test program on it (via dfu-util), it runs the program just fine. However, when I remove power, it ends up back in the bootloader when I power it back on.

I've attached the schematic. It's based on another board design which works just fine.

I feel at a lost for why this could be happening. I've read the datasheet and the bootloader application note (AN2606). I've tested that the BOOT0 & BOOT1 pins are connected to ground. Is there another way that the chip could automatically go to the booloader and not execute the user program on power-up?

Thank you!

[waclawek.jan]

> it ends up back in the bootloader when I power it back on

How do you know?

What does your program do? Is it a simple loopdelay blinky?

Does momentary grounding of NRST start your program?

JW

[Tesla DeLorean]

I think the inference here is that it comes up as a DFU device.

The BOOT0 floating issue seems discounted.

Not sure the F411 is new enough to have the boot to ROM, check the FLASH has a valid image check. ie looks if erased, looks at Initial SP/PC in vectors.

Third option is that FLASH code is actively switching to ROM, say via a magic number in RAM, or a button detect.

Would start with a really simple blinky app, and then instrument to see if the FLASH enters.

Just power via USB (not on computer), and use debug pod to probe/understand what's going on internally.

[berendi]

If it accepts a firmware image through dfu-util, then we can reasonably assume that the ROM bootloader is running. Well, unless someone has programmed the MCU with an equivalent bootloader, and convinced OP to link the application at a higher address.

AFAIK the STM32F4 series doesn't have empty flash detection, but it'd be still worth trying to read back the first couple of bytes at 0x08000000. The byte at 0x08000003 should be 0x20, and the one at 0x08000007 should be 0x08 or maybe 0x00.

Is R2 really 20 Ω ?

[Jeremy1]

R2 is actually 20k (that was just a typo in the schematic).

The F411 chip is brand new and I placed it myself. So there shouldn't be any funniness with the bootloader or flash address.

Thanks for your recommendation about reading out the flash. I'll give that a try and see.

[waclawek.jan]

> BOOT0 & BOOT1 pins are driven to ground

Have you measured it, directly on the pins?

Have you verified that all GND and VDD (including analog ones) are connected as intended, again directly on pins?

Is the battery connected? What constitutes "power removal"? Have you tried the NRST reset?

Can the DFU utility program a program into RAM and run out of it?

JW

[Jeremy1]

I have measured directly on the pins and the ground goes to ground and VDD goes to 3.3v.

Currently it's powered through USB. I have also connected a USB battery to factor out anything my laptop is doing.

"Power removal" is either physically turning it off with the switch or unplugging it from USB.

When I perform a NRST reset it goes back into the bootloader.

I'm not sure if the DFU utility program can do that. I'm using the same flash command I use for my other board designs (dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/program.bin). After flashing the program, dfu-util asks the bootloader to jump to the user program.

[waclawek.jan]

At this point, I am out of ideas, sorry...

JW

[Piranha]

How is NRST connected? Is it really floating?

[Jeremy1]

Yes, it's floating.

[Piranha]

So, I asked, you answered and that's it. You didn't have a single thought that it might be the problem? No thinking, no reading documentation... Especially AN4488 section 3.1 and reference schematic. Let's better search for some b.l.a.c.k. magic nonsense "solution" putting random parts somewhere...

[Jeremy1]

After playing with it some more, it turns out that replacing the pulldown resistor with a 100nF capacitor fixed it. (I figured this out after trying an RC circuit with it). I'm not sure if this makes sense to anyone, but that's where we are.

[ColdWeather]

Hello,

I've got the same issue with a STM32F091 in TQFP48 on my board. Under a magnification glass I spotted some remains/splits of solder (small balls/filaments) between some pins (I cannot say any more, what pins that were). I cleaned the board, and the problem has gone. Please check for any filaments between and even under the pins and the quality of soldering: sometimes a pin can just slightly touch the pad hovering over it and not being soldered properly.