possible ESD/Power Supply issue with T3.6 on robot

paynterf

Well-known member
I recently upgraded my 4-wheel autonomous wall-following robot from a Mega2560 main controller to a Teensy 3.5, and managed to (I think) kill a T3.5 after repeatedly connecting/disconnecting the battery charging probe to the robot. The probe is a simple 2.1/2.5 mm plug that fits into a mating jack with a contact that gets lifted away from the power supply minus when the probe is engaged. I use this line to tell the Teensy when the charger gets connected (so I can stop the motors and monitor the charge, etc). The PS is always active, so there is no issue with PS rise times.

I had gotten the robot built up to the point of testing the charger functions when I started noticing that the T3.5 was rebooting each time I connected the charger. Then I noticed I didn't have to actually connect the charger - all I had to do was touch the probe sleeve to the inside of the jack (so only the minus of the supply was connected to the minus side of the robot power system) to cause the reboot. Then I noticed the teensy power draw had increase from about 300mA to about 600mA and things on the board were getting a bit warm, and after that the Teensy became intermittently unusable.

I looked at the power supply (MeanWell GST60A12-P1J DC-DC 120VAC/12VDC) output. It's output looks very clean as would be expected. However, when I looked at either output of the PS with respect to the minus side of my robot power system, I saw what looks like a 60Hz 110VAC waveform - yikes! After some thought I realized this was because the two power systems (robot and MeanWell PS) are totally separate and do not have a common reference, so what I'm measuring (I think) is just the 110AC 60Hz that is everywhere in space. If I measure the robot minus side with respect to the PS minus (or plus) side, I still get some 60Hz signal, but only a few volts P-P, probably due to the fact that my robot is housed in an aluminum chassis and has fairly short circuit runs. Of course, when I connect the charger to the robot, the two minus sides are physically connected, so all is wonderful again, EXCEPT there seems to be something like an ESD event just as the two systems come in contact, and it is this event that seems to be causing problems.

Here's the schematicView attachment 26775

And some photos of the layout

View attachment 26776
View attachment 26778
View attachment 26777
211203 Robot Chassis 2.jpg
211203 Robot Chassis 1.jpg

And, of course, the full code is attached

I don't believe the code is really relevant here, except for the setup() function and the IsChargerConnected() function. This same MeanWell PS has been charging my previous robot (everything basically the same except with a Mega2560 instead of a T3.5) literally for years with no problems, with the same method for detecting charger connect/disconnect.

I am beginning to suspect that the charger connect/disconnect line, connected to a digital input on the T3.5 with INPUT_PULLUP specified, may be transmitting something like an ESD pulse to the T3.5 when the PS probe first touches the charger input jack, and because it is set up as an input, it is at high impedance. I was thinking that I might change the code to make this line an output with a LOW output, and only change it to an input when I want to actually check for a connection. Also, I was thinking that it might be advisable to add a series RC filter on this line, or even a resistor across the normally-shorted pins that would become a voltage divider with the T3.5 pullup resistor, but with a value that would still allow for a HIGH detection when the pin was changed from output to input_pullup. I looked at the M4 documentation for the pullup resistor values, but couldn't find them, so I'm at a loss there.

I would appreciate any ideas or thoughts regarding this issue. I'd like not to burn up too many more T3.5's before figuring this out, if at all possible. Also, before anyone starts laughing too hard at this setup, please understand this robot operates only indoors in an air-conditioned environment, and this same setup has been running for years without any problems. I only decided to upgrade to achieve a better wheel-turning geometry, and decided to upgrade the main controller from a Mega 2560 to a T3.5 at the same time.

TIA,

Frank


For all the gory details, you can see my blog post here.View attachment T35_WallE3_V3.ino
 
Connecting any input pin directly to something which the user can touch is a bad idea. Of course I just finished reading Henry Ott's book from start to finish so that final chapter on ESD may color my thinking a bit.

The series RC filter is certainly a good idea.
 
Interesting that you cite Ott's book. I still have the 1976 edition that I read cover-to-cover back in my days as a design engineer when EMI/ESD was first being encountered as an issue with solid-state circuits. Once we realized that inputs now had generally orders of magnitude higher input impedances and generally orders of magnitude lower damage thresholds and were therefore orders of magnitude more susceptible to ESD/EMI (especially with the new-new-new cool CMOS stuff), then we had to start implementing pin-for-pin ESD/EMI protection because they weren't yet 'baked in' to the products. MOV's weren't available then, so we used back-to-back Zener diodes a lot. Since those early years ESD/EMI pin protection has gotten so much better that I now expect the chip designer to take care of that problem, which is why I was a bit surprised that the T3.5 succumbed (assuming that's really what happened) while the Mega 2560 didn't.

I am now thinking that a simple RC filter might be sufficient here, especially if I change the algorithm to have this line be a LOW output normally, changing it to an input only to sample the voltage for a few mS every 200mS or so. I can make the series resistance (the R) arbitrarily (sort-of) large because it's current (and therefore it's voltage drop) goes to zero when the connection to circuit ground is broken, allowing the input pullup to pull the voltage to the positive rail. The pullup resistor would still have to charge whatever capacitance (the C) is used. I finally found a reference (https://www.rlocman.ru/i/File/2017/11/02/ATSAM4E16C.pdf) that shows the pullup resistor value as typically 100K, so if I use a 0.01uF cap I'll have about a 6mS rise time - maybe a bit long compared to my planned 200mS loop time, but still maybe OK.

This one input line sure does seem the likely culprit, but I might be committing other "crimes against Teensy" that I just don't recognize yet. Thoughts?
 
Unused GPIOs should be set as outputs or at the very least have their internal pull ups enabled so that they don't float. While the pins on CMOS devices will usually have clamping diodes on them those are useless for protection against ESD. You have to provide that. (See also "The Art and Science of RS-485" from Circuit Cellar describing ESD problems with RS485 transceivers.)
 
Hmm, didn't need to worry about that with the Mega2560. Guess I'm going to have to get a little smarter now, working with Teensy vs Mega2560 - sigh
 
BTW, the electrical reference for the T3.2 and T3.5 show that all 5V tolerant digital I/O pins are internally clamped to VSS with an ESD diode, so at least negative ESD transients are handled. Unfortunately, there is no ESD clamp to VDD, so that is something I'll have to address with this particular input.
 
That is not an ESD clamp. It is simply there to protect against voltages which would trigger the internal parasitic SCR between Vdd and Vss. You still have to limit current through the clamping diodes. Not sure how the Vdd side gets along without the clamp.

I just finished reading the second edition of Ott from front to back and that final chapter on ESD is a scary one. Just put it in a box with no connection to the outside world. It's the only safe way. :)
 
I just finished reading the second edition of Ott from front to back and that final chapter on ESD is a scary one. Just put it in a box with no connection to the outside world. It's the only safe way. :)

Sometimes it does seem that way, doesn't it? ;-)
 
Back
Top