STM32G473 IO Cells getting hammered due to motor induced ground bounce?

[rfish.749]

This PWA is running multiple BLDC motors. we have some serious noise issues on the ground plane, but want to understand what we are seeing. this is the output of PD2, configured as an push-pull output (driving an LED w/ 20k resistor to ground. when running the motors, we see this on the pin. when the motors are off, it's a steady high signal. We are also seeing this on other various IO pins. The 3.3V / DGND at the processor is stable. Can't share any schematics/layout etc. but we know the noise is due to the motor switching We don't see any transients below 660mV (where the ESD diodes turn on) and these transients are very short 10ns [not ideal obviously]. It could almost be explained where the high side output FET is getting turned off and the low side output FET is getting turned on, then quickly being released and the output being switched to OD. alot to get corrupted, but maybe not! Would this be caused by some power transient on the pins or DGND or what? thanks!

[S.Ma]

Until someone provides a better answer, I would go back to basic signal integrity:

Identify the dominant current path loops areas (which acts as antenna). High slew rate will affect others especially high impedence ones.

In differential pairs, the loop is formed usually with a twisted pair for single ended signal, the loop is formed witg supply rails.

200ps per inch propagation delay makes 50 inches for 10ns, so decoupling caps close to supplies seems not a tuning parameter here.

Maybe adjust the slew rate with gpio speed register to reduce transient. Reduce possible crosstalks (90 degree angle tracks crossing...)

[cedric H]

Hello @rfish.749​,

What you are describing could have several possible causes. We will list some of them, but it will not be exhaustive.

1/ Do we have two GND planes? If so, an inappropriate connection that connects these two planes together by an unwanted path could cause high current to flow in the wrong place. This can happen through the GND connections of oscilloscope probes.

2/ The ground lead of oscilloscope probes are great antennas. If the loop is too close to the switching power, there may be measurement artifacts related to this.

3/ Is the GND plane equipotential? Is the use of many of the vias to link the planes together there? If the plane of GND is not equipotential, strong currents may not pass through where it would be expected.

4/ The proposed screenshot seems to be the evolution of the GPIO output voltage when it is forced into high mode (logic 1). Considering the voltage level (-660mV compared to the high level), one could think that it is the ESD diode of the circuit which is set ON. However, if this were the case, we should have a level of +660mV above the high level and not below. the most probable hypothesis is not a switching on of the ESD diode between the output and the Vdd of the microcontroller but rather a coupling (to be determined) between the measurement probe and the power stage.

Hope it helps.

Best Regards

Cedric

[rfish.749]

thanks for the help -

1) yes, it's an 6 layer board. it has digital GND on 2, 3 and 5 under the processor. I have the motor ground connected at one location. the GND planes are not tied heavly together - just the normal through-hole for caps and other ground pins. we are looking at trying to improve the steering of the motor ground away from the processor and closer to the power connector. We cut the ground tie and wired the grounds at a different point and saw better results, but still the orginal scope picture.

2) measured with diff probe directly at the pin with a 2" ground wire - pretty sure that signal is real

3) can't really tell, but we will add more vias to keep them tighter on the next pass.

4) we think that the -660mV is the ESD diode to Vss is getting turned on. we did some tests and see that it does start to fully turn on at ~600mV and fully turns on at -660mV, so it seems that something is sucking alot of current out of the pin/IO ring somewere. Haven't found that source yet. we initially bandaided this by adding a 4.7nf cap right at the processor pin to DGND - seemed to help those pins, but still shows up on other pins.

still trying to isolate the issue