Skip to main content
Joe.H
Joe.H
Associate III
May 22, 2019
Solved

What could cause a STM32F427 to hard fault when GPIO port is set to output

  • May 22, 2019
  • 3 replies
  • 1996 views

I just received version 2 of a board I designed. It has two STM32F427 on it. One a 144 pin used for main processing and the second a 100 pin used to control IO.

The 100 pin MCU uses Ports B, D, E (all as outputs) to control outputs.

Version 2 of the board is all hand assembled and soldered by an assembly house in China.

I've had firmware running on Version 1 for weeks so I know the software is not causing the hard fault.

The board is drawing about 200 ma more than it should which would indicate an issue somewhere.

I debug the operation of the 100 pin MCU (output ports) to jump to the hard fault vector when any of the pins associated with ports B, D, E are set to being an output.

I've looked hard at the board and parts under a microscope and do not see any solder bridges.

I do see a lot (about .25v) of noise/hi freq oscillation on both VCAP pins. The voltage is clean on the VCAP pins of the 144 pin CPU.

What would noise or oscillation on either of the VCAP pins suggest as being an issue?

Both caps are 10UF 6.3v Low ESR caps.

What GPIO related event would cause a hard fault?

Any ideas or suggestions as to what the issue may be is welcomed.

Thanks.

Joe

This topic has been closed for replies.
Best answer by Joe.H

I thought I would follow up with what the issue was.

Hard faults were occurring because flash data (LDR) instructions would have bits set when they were supposed to be zero as in address in CCM 0x10000000 being loaded into a register as 0x18000000. Bit 27 was always set when a fault occurred because the address was outside the memory range.

Issue was the .25 v oscillation riding on top the voltage at the VCAP pins which supply 1.8v to the MCU's digital core.

This prototype build was terrible - solder bridges and now I find out - incorrect part usage.

The ceramic caps used on the VCAP pins have no marking and look the same as other caps so I speculated that the wrong caps were installed. I removed the VCAPs from an earlier build and replaced them .... AND ... all is well now!!!

The China assembly house used standard caps instead of low ESR and it oscillated - causing random flash read bit errors.

What a waste of 27 hours of my time -- tracking down bad board assembly!!!

Just thought I'd share in case someone else has a similar issue.

Thanks for your replies.

Joe

3 replies

Tesla DeLorean
Tesla DeLorean
Guru
May 23, 2019

I use a Hard Fault Handler to report the faulting registers and location.

Issue sounds like a part orientation issue, or one where the pin ordering isn't correct. Walk the schematic and PCB traces. Start with supply pins.

The VCAPs are supposed to be 2u2. Oscillation perhaps that the regulator is overloaded.

Check clock sources, and internal settings, output clocks via PA8 (MCO)

Check PLL and Flash wait states.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
waclawek.jan
waclawek.jan
Super User
May 23, 2019

The fault may well be consequence of a hardware problem, 200mA excess current is a lot. Something ought to be hot.

The primary power source is OK and clean?

Version 2 means PCB redesign? Couldn't a ground (or power) discontinuity slip in? Measure directly on the mcu pins (and by that I mean on the pins, not next to them, applying as little vertical force as possible, or even prying them carefully to the side, to reveal bad solder joints), ALL ground pins including the power supply ones.

As Clive said, the VCAPs are not the specified ones; if you have the specified quality 2u2 at hand, it should be easy to change them. If not, is the excessive current and ripple on VCAPs present when the mcus are held in reset? If yes, that might indicate problem with VCAPs, if no, it still might be the VCAPs but I'd look elsewhere first. Reset mcus individually - still issue? As painful as it sounds, at this point you might need to write a test program, which wiggles individual pins.

JW

Joe.H
Joe.HAuthorBest answer
Associate III
May 23, 2019

I thought I would follow up with what the issue was.

Hard faults were occurring because flash data (LDR) instructions would have bits set when they were supposed to be zero as in address in CCM 0x10000000 being loaded into a register as 0x18000000. Bit 27 was always set when a fault occurred because the address was outside the memory range.

Issue was the .25 v oscillation riding on top the voltage at the VCAP pins which supply 1.8v to the MCU's digital core.

This prototype build was terrible - solder bridges and now I find out - incorrect part usage.

The ceramic caps used on the VCAP pins have no marking and look the same as other caps so I speculated that the wrong caps were installed. I removed the VCAPs from an earlier build and replaced them .... AND ... all is well now!!!

The China assembly house used standard caps instead of low ESR and it oscillated - causing random flash read bit errors.

What a waste of 27 hours of my time -- tracking down bad board assembly!!!

Just thought I'd share in case someone else has a similar issue.

Thanks for your replies.

Joe

Terms & ConditionsAccessibility statement