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

[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?

[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]

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]

As long as you are comfortable that the programmer you are using is able to drive a 100nF capacitor easily, since I assume the programmer is connected to nRST too. Otherwise a 1k in series with the reset capacitor will assist there. I agree though, this would only affect the ability to program, nothing to do with the problems you were experiencing. I have found on the L4 that it was easy to damage the processor through the programming cable, by getting the wiring wrong (in our case we used a 6-pin connector, and inserting it 180 degrees flipped would cause the damage). Symptoms of damage were minor, just an increase from 2uA (normal) to 4 or 5uA in the current consumption. However, this value usually increased over time. In one case the unit failed 3 months (and half a continent away) later, with processor still running, but drawing excessive current, flattening the battery very rapidly. It sounded like some sort of latchup.

[BKN636]

Ive checked the pinout of the debug connector numerous times. Although its prone to flipping the connector 180°, doing so would result being not able to flash/program/debug at all (and im pretty sure i didnt flipped it in between). So i would say the damage isnt coming from this direction.

But ill add a footprint for an optional series resistor just in case, thanks. Wouldnt have thought that the debugger actually has to supply the current for the cap at the reset pin.

[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.

[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.

[BKN636]

The first thing that came to mind when i saw those waveforms is that theres some I/O conflict, i.e. µC pin functions conflicting with each other.

On a freshly fitted board, UART RX & TX both work fine.

Just to make sure, ive disconnected the RS232 transciever completely from the µC via desoldering some stuff. (R32, R35 & Q5)

On its own in idle mode, the MAX3250 is floating at 3V3 at RX on pin 2 (R1out) like its supposed to. (correct me if im wrong)

Then i tried to directly connect MAX3250 Pin 2 and the µC UART RX Pin directly via wire (following the datasheet) and i also got those glitches which can been seen in the uploaded waveforms. Which to me points to a damaged or conflicted µC-pin or rather a completely fried internal I/O Port.

[JGerb]

What did the micro pin do when you disconnected the MAX chip from the UART? did it float or did it jump to some voltage? It should float (or be weakly pulled up, if you've enabled that)? You may have a short to another pin somewhere, of course, but you've probably looked for that already. And it can't be a stray solder ball because you've already replaced the micro a few times. Or e.g. Q5 might be the wrong part (assembly houses do make mistakes sometimes).

My question is, if the pin is damaged or conflicted, what is driving the waveforms? It must be a conflict with another pin or source, either within the micro or outside.

[BKN636]

RX pin is floating steady on its own at 1,45V. Nothing seems to be driving it to Vdd or GND. So my suspicion is that theres an internal short inside the whole I/O Port Bank to an internal clock signal or some other internal signal