STM32 custom board hardware errors

[BKN636]

Hello everyone,

im currently working on a custom pcb which uses the STM32L031K6 and im having some troubles with it.

Ive attatched the schematic and some oscilloscope measurements.

Fault description:

-random signals and floating voltage levels on various I/O pins

-fault occurence ranges from minutes to hours

-3rd board revision, changed several periphal ICs, same error pattern

-errors seems to occur at random, even when the board is in idle (no h bridge switching)

Board I/O:

-rs232 via uart (MAX3250)

-12bit dac via i2c (MCP4725)

-16bit adc via spi (INA240+ ADS8864)

-3 digouts for h bridge control (no pwm, just steady state enable/disable)

-1 digout for current control ic (drv110), gives static enable signal (drv110 drives h-bridge low side switch via pwm)

-2 digouts for led

-1 internal 12bit adc

Supply:

-24V lab supply behind transformer

Debug probe:

-Segger J link edu mini via usb isolator

Things ive tried:

-closely observed 3v3 supply, seems clean, no overvoltage during start up or sudden shut downs, tried several different switching controllers on each board revision, all seemed fine to me

-tried several compilers, eclipse, keil & atollic, projection creation & µC initialisation via cubemx, created projects with "normal code" (which seems to run decent on some board revisions), and some with no functional code with setting all digouts to zero

-tried all combinations for digouts & alternate functions, pushpull, open drain, /w & w/o pullup/pulldowns

-replaced µC numerous times, all seem to get faulty after a while (perhaps faulty batch/damage during storage?)

-obviously the i/o ports seemed to get damaged, but why several at the same time?

Appreciate any help from you guys.

Kind regards

[TDK]

Once it occurs, it doesn't recover, right? Which pins in particular get damaged? Always the same ones?

Sounds like a hardware issue, probably overvoltage on pins due to some external source, maybe during inrush or some other event. Use the information about which pins are damaged to track down the issue. Are pins ever powered while the chip is off (VDD=0)?

[BKN636]

It seems to me that most of the I/O Pins get faulty from time to time. That includes UART, I2C and Digouts. However they dont seem to recover after the board has been powered off for a while.

[JGerb]

I had another look at the waveforms you showed on UART RX, and they still don't make any sense to me. Either the GND reference was periodically coming adrift (scope GND?) or the pin is not being driven properly, or there's a break in the GND / 3V3 in the PCB somewhere. I'd also have a look at what equipment and power supplies are grounded or AC coupled to GND. The other possibility is some sort of I/O conflict - i.e. the line isn't floating because it's not driven, but is fighting another driving source. If you see those waveforms again, try and have a look how "stiff" the signal is to find out which of those it is. I usually tap it with my finger to inject a weak 50Hz signal.

[andy2399]

You don't seem to have the RESET pin pulled high.

A floating reset pin may give you periodic problems.

Andy

[TDK]

The STM32L0 has an internal pullup on NRST.

[BKN636]

Reset connection looks to be in order when checking the HW guideline.

[Tilen MAJERLE]

Hi,

please check our HW development guideline for STM32L0 series.

https://www.st.com/resource/en/application_note/dm00112257-getting-started-with-stm32l0xx-hardware-development-stmicroelectronics.pdf

[JGerb]

My 2c worth (forgive me if I explain what may be obvious):

It looks like your boards have isolation, perhaps motor controllers, and some high current / high-voltage stuff going on. I'd have a look to make sure something in this environment isn't killing your micro :

1) That micro has no clamps for positive over-voltage on the I/O. Thus it can be broken easily by any kind of inductive spikes or ground bounce. When a pin dies, try measuring resistance to ground and to +3V3. That may give you some clues. Also check the resistance values while the micro is powered up and while off. If you see a resistance path to GND in the order of kΩ, suspect a HV spike with low energy behind it. If you see ohms, something with current behind it has trashed the pin. See if you can still measure the negative clamping diode for the pin to check if it's still there. If you have inputs coming from off-board or high-current/voltage sources, isolate with a few hundred to a few kiloohms in series (Adjust R53 according to your needs), AND add a clamp to supply, and then another resistor in series as well (R3 can be as low as 100 ohms, but do your calculations assuming an ESD hit of 8kV from a 2k source) - if there is e.g. a negative going spike, you don't want the current shared between your protection diode and the internal protection diode. I use the scheme below for all inputs that travel any distance or to a pushbutton or LED anything that might pick up static from a user/machine. A BAV99 can take 2 or 4A for a microsecond and is almost free and has practically no leakage. If you can't clamp to your 3V3 rail due to too little current draw (micropower designs e.g.) then clamp to a shared transzorb, even if you have to pre-bias it to supply.

2) Check your grounds. Make sure there is no ground shift happening due to high currents in the groundplane/fill. Make sure both VSS pins are connected to each other very solidly, and to same GND as your input signals. If you have high current, make sure your micro is on its own, quiet, ground with no current flowing in it. And a nice ground fill underneath it if you can. If you're on a 2-layer PCB, you may struggle. Check for placement of switching regulators and other sources close to the micro, especially keep the SW pin away from the micro.

3) The input pins can't be damaged by a 3.3V signal injected when the micro is off, you'd have to go > 4V above Vdd to do that. But it can be damaged by negative going signals in excess of 20mA.

4) Suspect the firmware. If you can reproduce the fault, try and get debug output of the GPIO registers of the affected ports.

5) Check for EMC. If you don't have equipment for this, take a seek coil out of an old hard drive and wire to a BNC into your oscilloscope. Wave it around in the vicinity of the PCB and play "warmer warmer colder colder" till you can see what's coming out of where.

6) Check that reset line - I think there's supposed to be a 1k resistor in series with the cap on the reset line. And a push-button can be a nice place for static to enter a micro, so consider whether it needs a clamp.

7) Check the layout carefully, look for routing of all pins going to the micro. If they run close to high dv/dt nodes, especially for long runs, you need to shift them elsewhere.

[BKN636]

1. While the µC is off, no pins are externally powered. There are no external board inputs directly to the controller, except for the debug probe (which connection to the PC is isolated via Meilhaus USB-ISO)
2. I tried to keep as close as possible to the HW development guideline, especially on page 30. I will still be trying to find any error ive made while checking the guideline, thanks.
3. Ill include some additional protection via BAV99 at controller pins and a 3V6 Zener at the output of the 3V3 switching regulator in my next revision, thank you for that idea.
4. I tried to keep all funcional groups (µC, 3V3 switching regulator, RS232, H-Bridge) as far away from each other as possible, so theres minimal interference with each other, local ground shifts or anything alike. I uploaded the PCB as well. However, im aware that the ground connection underneath the µC seems to be lacking, so that might cause the issue.
5. As with the firmware - i flashed the µC with "normal code" and with "empty dummy code" both with initialized hardware peripherals (both with fresh new, clean CubeMX projects), so i have my doubt its a software problem
6. Another thing ive tried is desoldering most of the periphal ICs, so the pins arent connected to anything and flashed the µC with setting all pins to Digout and let them toggle periodically, which they did just fine. Which to me would be a sign that the pins arent permamently damaged, would it not?

[Dvorak.Peter]

It looks to me that this schematic is haunted by evil spirits from the past.

The so called bridge driver is :

FDMQ8205A is GreenBridgeTM2 series of quad MOSFETs for a bridge application so that the input will be insensitive to the polarity of a power source 

[BKN636]

I know the FDMQ8205A in this case maybe is a bit off-use, but it looked like an ordinary h-bridge to me. (however oddly small package for 8 amps) I got it running to about 3amps and the case got barely over 40°C

On each board revision i tried out a different power stages.

-DRV103, internal low side MOSFET - worked fine

-DRV110 with an external low side MOSFET and shunt voltage sense/current control - worked fine

-H-Bridge with FDMQ8205A & DRV110 (current revision) - also works

[BKN636]

Thank you for your input so far guys. Ill much appreciate any new ideas. Especially after a few weeks of being stuck...

Ive uploaded the PCB and a measurement of the Vdd supply.

[BKN636]

Another thing that comes to mind is how to proceed with unused µC-pins, as that might also cause issues. The HW guideline doesnt seem to be clear to me on this issue.

Connect unused pins to GND and set them up as inputs with pullups/pulldowns enabled?

[JGerb]

I agree with you about being able to toggle all pins, seems to imply no permanent damage to the output circuitry, however, silicon doesn't always blow cleanly. It can be possible to blow the transistor that drives low, but not the one that drives high, in an output, or vice versa, or to create a resistive leakage path through silicon. And you can damage the input and not the output circuitry in a pin, of course, or vice versa.