0
\$\begingroup\$

I have an STM32F407VG on my board. I am able to bring it to the dfu mode. Then I am able to flash it using DfuSe, which also correctly recognizes the dfu device (http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF257916) or using the dfu-util for Linux. Both report to have successfully completed the download.

My whole command is:

dfu-util -d 0x0483:0xdf11 -c 1 -i 0 -a0 -s 0x08000000 -D my.bin

with those:

-d --device vendor:product  Specify Vendor/Product ID of DFU device

-p --path bus-port. ... .port   Specify path to DFU device

-c --cfg config_nr      Specify the Configuration of DFU device

-i --intf intf_nr       Specify the DFU Interface number

-a --alt alt            Specify the Altsetting of the DFU Interface

-s --dfuse-address address  ST DfuSe mode, specify target address for raw
                            file download or upload. Not applicable for
                            DfuSe file (.dfu) downloads

Now when I powercycle my STM32, it doesn't seem to boot at all. RTC-Oscillator does not run, LEDs that should instantly blink do not blink. And most important (since all those could fail because of bad software): DfuSe does not recognize the STM32 in Application mode. Does anyone have an idea what could be wrong and holding the STM32 back from normally booting?

Thanks and best regards, Noah

\$\endgroup\$
6
  • \$\begingroup\$ You might try a simpler program. Or spend the $10 for any of the discovery boards to use as an SWD adapter, make yourself an SWD cable and load a simple blink program. If necessary you can then use a debugger such as gdb to figure out what is going on. These parts requiring a number of operations to get GPIO going, and unless your program is a known good one some may be missing. I could be wrong, but I don't think that you can get back to DFU mode without either rebooting with suitable boot settings, or the cooperation of whatever you flashed (which requires that program to function) \$\endgroup\$ May 17, 2015 at 16:27
  • \$\begingroup\$ Well, the program is tested very well and works without a doubt. The hardware as well. So I am now looking for what I did wrong while soldering. Because both have been tested intensively. So I must have misssoldered something ... \$\endgroup\$
    – Yatekii
    May 17, 2015 at 16:59
  • \$\begingroup\$ That's nonsensical. If you are still looking at what you did wrong with soldering, then obviously the hardware isn't tested. And your claim that the software is tested is quite suspect as well - on what did you test it? That said, getting something running on the STM32F4 discovery wouldn't be a bad first step. \$\endgroup\$ May 17, 2015 at 17:25
  • \$\begingroup\$ wat. when there is multiple users flying their quadrotors with that hardware & software, they're ok. And it's just my soldering or my way of flashing that's bad. Thus the hardware and software are obviously tested and working and just my soldering (or whatever I did wrong) is bad. But if you don't even get that better don't try to help me lol. \$\endgroup\$
    – Yatekii
    May 17, 2015 at 21:28
  • \$\begingroup\$ You could mention in the question itself that this is not an original design. But if you are unwilling to debug it as if it were one, then your question doesn't really belong here. \$\endgroup\$ May 17, 2015 at 22:27

2 Answers 2

1
\$\begingroup\$

Assuming you're at the point where:

  • you are using a pre-compiled firmware image which has worked for others with this exact PCB design and exact MCU part number in the past, so all toolchain/linker/etc issues are ruled out
  • USB bootloader enumerates on your host machine (development computer)
  • you've confirmed the checksum of your firmware image against a known good copy
  • the entire PCB is populated (aka, all parts are soldered)
  • basic power circuitry is running to some degree (aka, all voltage rails and regulators are within acceptable ranges)
  • MCU powers on, internal logic voltage regulator is running
  • all switches, buttons, knobs, fuses, power plugs, sockets, trays, etc are in the full and upright position for takeoff
  • you have visually inspected all your hand soldering with a microscope for shorts and bad joints

... then common "board bring-up" problems with STM32s at this stage could be:

Reset and boot pins (BOOT0/BOOT1) are not being pulled correctly at the right time. Try probing these lines to make sure they are set correctly, and not just floating. Note that Reset should be pulled down with an open drain, not a push-pull on some (all?) STM32F4 chips (this is a hardware design point). If there is any logic of any kind driving these pins, capture an oscilloscope trace and verify against the datasheet to make sure the pins are at the correct levels at the correct times.

assert() failure very early in init code. Eg, during your firmware's clock and NVIC initialization routines or runtime setup, preventing main() from ever getting called. Try a simpler configuration, eg using the low speed internal clocks.

Bad power supply, eg a brown out when some external chip is enabled. Scope the power rails with a properly grounded oscilloscope during the first couple dozen microseconds to make sure all voltages are reasonably stable when the chip is trying to power on. If this is a USB powered device, try using a battery or bench power supply instead.

Bad or out-of-spec NVIC (interrupt) or RCC (clock) configuration in firmware. Double check all the nitty gritty fine print in the datasheet about intermediate PLL frequency limits et al. Out-of-spec settings might work with some chips of the same model but not others due to manufacturing tolerances.

Your blinky surface mount LED is populated backwards. Also happens sometimes with oscillators. In this particular case it looks like you have other signs of failure, but try toggling as many GPIOs as possible in your code and probe around just to check.

Internal "user configuration" flash bits have somehow been set improperly, check the special application note on this.

You've somehow populated the wrong microcontroller, check the package markings just in case there was a problem in the logistics chain somewhere.

There's errata for this silicon or batch, check ST's website.

That all being said, if you're doing board bring-up on hand-soldered hardware without a debugger, you're basically stabbing in the dark with a one-bit flashlight in an infinite library with thousands of bytes of configuration registers and hundreds of pages of reference documentation. Hope you're having fun!

\$\endgroup\$
1
  • \$\begingroup\$ Thanks for this elaborate reply! Of course what did it for me was compiling the code for the right MCU. I somehow left that unchecked :( \$\endgroup\$
    – Yatekii
    Dec 25, 2015 at 12:45
0
\$\begingroup\$

What fixed this for me was compiling the source for the right MCU. I somehow managed to try and flash a binary being compiled for the wrong MCU. Sorry for that one.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.