Minimum circuit check STM32F401RC

[Pack34]

I made a small widget to act as a DAQ for various projects. The intention is to have a couple themocouples, current sensors, etc to validate whatever I'm working on. This is the first STM32 design I've put together from scratch and I've run into a road block. The rails are fine and the chip takes the code but nothing happens. I know the chip takes something because if I switch between internal and external oscillators I can see the change on the PH0 and PH1 pins.

Is there something basic I'm just missing in regards to the minimum circuit requirements for this thing? It almost seems like I'm missing something on the reset, boot, or vcap pins but I'm not seeing it. I made two up individually and they both exhibit the same behavior, so I would assume this is not an assembly error.

[Pack34]

The datasheet for the micro:
http://www2.st.com/content/ccc/resource/technical/document/datasheet/9e/50/b1/5a/5f/ae/4d/c1/DM00086815.pdf/files/DM00086815.pdf/jcr:content/translations/en.DM00086815.pdf

I did notice that I had the PH0 and PH1 pins reversed on the part but that shouldn't matter. The output waveform on these pins has an oddly small amplitude ~1V, but it oscillates at the appropriate frequency. I would be blaming this, but the issues with the chip persist when moving to an internal oscillator. It may be a hint at the issue. Also, I flicked off the R6 and R7 to isolate the crystal and wired in a function generator set to the 8MHz and there was no change in the behavior.

Double checked all my nets, everything that looks like it should be connected in the schematic is connected.

Double checked pinout assignments and the ordering of pins on the footprint.

Orientation of the chip is clearly correct since it programs.


As far as I can tell, the absolute minimum requirements are:
- All Vss to ground
- All Vdd to 3v3
- Decoupling cap at each Vdd
- Bead on Analog Vdd for noise (not needed if ADC is not being used)
- V_Cap pin needs a 2.2uF cap to ground.
- Boot0 and Boot1 need to be grounded (I hacked in a bodge wire to be sure Boot1 is low)
- Reset pin needs to be held high with a decouping cap
- Appropriate passives on external oscillator.

Voltage rails are correct.

[marus25]

If you can connect with the debugger after programming you may be able to see the program counter; I'm kind of wondering if you're getting into the bootloader for some reason (typically I've seen 10k pull downs on the boot0 pin instead of the 100k you're using, may be too weak of a pull down). If the PC is in the range 0x1FFF0000 to 0x1FFFFFFF you are in the bootloader.

I had an issue with an STM32 part doing this (stupidly forgot the pull down - luckily I could stick one on after I noticed).

Also your cap on nRST is larger than I've typically seen (usually 100nF) - although I don't think that would cause problems.

Also your decoupling doesn't seem to be quite what I've seen recommended for most STM32 parts.

They recommend having a single 10uF in parallel with one of the 100nF decoupling caps.

And on VCAP1 you should have a 4.7uF low ESR cap (2x2.2uF is recommended on parts with two VCAP pins).

[stmdude]

nRST is wrong. You shouldnt have an external pull-up, and the cap should be 100nF.

Your chip cant perform a reset the way it is now.

Check figure 32 in the previously linked datasheet.

[Pack34]

Interesting.

Stepping through the initialization code, a hard fault is being thrown when running the RCC_AHB1PerifphClockCmd functions that enable the GPIO ports. Something is happening erratically during initialization.

[Pack34]

Unfortunately, no luck with the changes.

[ade]

What did you change?

STM32s usually don't require much to start other than stable power.  No need for an OSC circuit as it starts up with an internal one.  No need for NRST against because it has internal reset.  Boot1 is ignored when Boot0 is tied to ground, so no need to connect that either.

Maybe try removing stuff instead of adding?  Take out the two OSC resistors (don't need them anyway) and only use the internal oscillator (don't connect a function generator).  Similarly remove the NRST 10K pullup and maybe even the large 1uF cap. 

See if you can get it started as bare bones as possible?

[Pack34]

I made the changes as suggested by marus. I upped the VCAP value to 4.7uF, removed the pull-up on nRST, strengthened the BOOT0 pulldown (10k), and added an additional 10 uF cap in parallel with the Vdd decoupling caps.

The circuit itself "is" bare-bones. The only thing else on the board is a couple SPI sensors.

Stepping through the firmware on boot-up it seems to throw a fault and lock up randomly when setting up the GPIO pins. It doesn't do this consistently in that sometimes it seizes when GPIOA is enabled, sometimes GPIOB, etc.

I've never had issues like this bringing up a micro.

[ade]

Weird.  R6 and R7 still off & crystal not connected?

[ade]

Not sure if you've seen these older threads, maybe they can give you an idea or two:

https://www.eevblog.com/forum/microcontrollers/stm32f4-minimal-circuit/

http://rusefi.com/forum/viewtopic.php?f=4&t=381

[Pack34]

Weird.  R6 and R7 still off & crystal not connected?

I put them back on since it seemed like the oscillator was not at fault. I made this assertion because using an internal oscillator made not change in behavior.

Concerning the boot mode, I'd like to be sure I understand the expected behavior when debugging the code. Boot mode is selected at about the fourth or fifth clock cycle after power on. This should mean that I should be able to step through mode code until after the system clock is initialized. Then maybe execute a few lines of code after that depending on the amount of clock cycles are required for each operation, correct?

If this is the case then what I'm observing seems to be the STM32 being thrown into a different boot mode even though I have BOOT0 pulled down with a 10k and BOOT1 wired to ground.

BUT, if it should throw the chip immediately into the different boot mode when debugging this is not the case.

I did hand assembled these, maybe I damaged these somehow. Although I can program the chip the entirety of the chip is not functional. I will admit that I had originally soldered these in backwards. They have two divets at opposing corners and I had it in backwards. I corrected this by using a hot air gun set to 280C and reseated the chip. I've done this with other chips in the past with no issue, but there's always the chance I did some damage.

I had thought that this wouldn't be the case since it does in fact program properly, but you never know. I've ordered some replacement chips and hopefully they'll be in by Monday.

[tszaboo]

On VDDA have a cap after the ferrite bead. I think 100K for the Boot0 is also too high. Also R7 should be a few ohm, not 220.