Killed another Teensy 3.5 - but don't know how

P

paynterf

Well-known member
I managed to kill another Teensy 3.5 today when I connected the charging power supply to the robot's charging jack.

After concluding that I killed the first one by connecting the switched ground line of the power jack directly to a Teensy digital input, I decided to abandon that idea entirely and instead look for +12V (appropriately divided down, of course) on the + side of the charging jack. I installed a 4:1 divider using a 30K and 10K resistor, with a 1uF cap paralleling the 10K, as shown in the attached schematic snippet. Here's the code:

Code: 
/*
    Name:       Teensy_Pin_Study.ino
    Created:	12/5/2021 5:04:03 PM
    Author:     FRANKNEWXPS15\Frank
*/

#include "elapsedMillis.h"
elapsedMillis mSecSinceLastPass = 0;
const int LED_BLINK_INTERVAL_MSEC = 200;
int pwm_num = 0;
//const int CHG_CONNECT_PIN = 14;
const int CHG_CONNECT_PIN = A1;

#pragma region CHG SUPP PARAMETERS
//02/06/21 added for charge connection debounce
const int CHG_CONNECT_PIN_READING_ARRAY_SIZE = 5;
int aChgConnectReadings[CHG_CONNECT_PIN_READING_ARRAY_SIZE];
const float CHG_CONNECTED_AVG_THRESHOLD = 400;
const float CHG_DISCONNECTED_AVG_THRESHOLD = 100;
float ChgConnectOldAvg;//this is the 'oldTot' in 'IsChargerConnected(bChgConnect, oldTot)'
long chgStartMsec;//added 02/24/17
volatile bool bChgConnect = false; //updated every MSEC_PER_LOOP Msec
#pragma endregion CHG SUPP PARAMETERS		

void setup()
{

	Serial.begin(115200);
	delay(1000);

	//pinMode(CHG_CONNECT_PIN, INPUT);
	pinMode(CHG_CONNECT_PIN, INPUT_PULLDOWN);
	pinMode(LED_BUILTIN, OUTPUT);
	mSecSinceLastPass = 0;
}

void loop()
{
	if (mSecSinceLastPass >= LED_BLINK_INTERVAL_MSEC)
	{
		mSecSinceLastPass -= LED_BLINK_INTERVAL_MSEC;
		digitalToggle(LED_BUILTIN);

		//check for charger connection
		bChgConnect = IsChargerConnected(ChgConnectOldAvg);

		Serial.printf("%lu\t%3.2f\t%d\n", millis(), ChgConnectOldAvg, bChgConnect);

	}

}

void CheckForUserInput()
{
	const int bufflen = 80;
	char buff[bufflen];
	memset(buff, 0, bufflen);

	if (Serial.available() > 0)
	{
		// read the incoming byte:
		int incomingByte = Serial.read();

		// say what you got:
		//Serial.print("I received: ");
		//Serial.println(incomingByte, HEX); //chg to HEX 02/18/20

		//02/18/20 experiment with multiple commands
		switch (incomingByte)
		{
		case 0x43: //ASCII 'C'
		case 0x63: //ASCII 'c'
				break;

			//left side wall tracking
		case 0x4C: //ASCII 'L'
		case 0x6C: //ASCII 'l'
			break;
		}
	}
}

bool IsChargerConnected(float& oldAvg)
{
	//Purpose: Determine if robot has connected to charger
	//Inputs:  
		//aChgConnectReadings = byte array containing previous readings
		//oldTot = previous readings total
		//curState = current value of bChgConnected
	//Outputs:
	//	true when array total * CHG_CONNECT_PIN_READING_ARRAY_SIZE > CHG_CONNECTED_AVG_THRESHOLD
	//	false otherwise
	//Procedure:
	//	Step1: update prev reading array total
	//	Step2: return TRUE if array total * CHG_CONNECT_PIN_READING_ARRAY_SIZE > CHG_CONNECTED_AVG_THRESHOLD
	//			return FALSE otherwise
	//Notes:

//Step0: change pin from OUTPUT LOW to INPUT_PULLUP and wait 10mS for .01cap to charge
	//pinMode(CHG_CONNECT_PIN, INPUT_PULLUP);
	//delay(10);

	//Step1: update prev reading array total
	int newReading = analogRead(CHG_CONNECT_PIN);
	int oldReading = aChgConnectReadings[0];

	for (size_t i = 0; i < CHG_CONNECT_PIN_READING_ARRAY_SIZE - 1; i++)
	{
		aChgConnectReadings[i] = aChgConnectReadings[i + 1];
		//Serial.printf("%d: %d\n", i, aChgConnectReadings[i]);
	}
	aChgConnectReadings[CHG_CONNECT_PIN_READING_ARRAY_SIZE - 1] = newReading;

	float newAvg = (oldAvg* CHG_CONNECT_PIN_READING_ARRAY_SIZE - oldReading + newReading)/ CHG_CONNECT_PIN_READING_ARRAY_SIZE;
	//Serial.printf("newAvg = %2.3f, oldAvg = %2.3f\n", newAvg, oldAvg);
	oldAvg = newAvg;

	bool retStatus = newAvg > CHG_CONNECTED_AVG_THRESHOLD;

	return retStatus;
}

Screenshot 2021-12-11 142417.jpg

The output from the voltage divider is connected to an analog input (A1 if it makes a difference). I tested this yesterday with my lab power supply set for 12V, and it worked great. However, when I tested it using my 12V MeanWell GST60A12 power supply, the Teensy rebooted a couple of times, and then died completely. No flashing LED (I have the sketch set to toggle the LED every 200mS), no serial output-nada.

Came back today and darned if the Teensy isn't working again! Tested at the A1 input with my lab power supply again - works great (although at 3V, not 12). Moved my lab power supply to the charge jack, and verified that now the analog input reads full-scale at 12V input - no problem. However, if I connect and disconnect the MeanWell supply a few times, I'll get the 'down' USB tone, and the Teensy LED will dim (still flashes, but much dimmer). If I disconnect & connect the USB connector to the Teensy, I'll get the 'up' beat followed almost immediately by the 'down' beat. Looking at the 3.3V output on the Teensy, I can see the voltage go up to 3.3V as it should, but then almost immediately drop back to 1.9V, at which point I get the USB 'down' beat.

There is obviously something different about the MeanWell PS, but I can't for the life of me figure it out. it scopes out fine on the bench, nice clean 12V DC output. Its a switching supply with the 12V output completely isolated (I checked with an ohmmeter) from the input. I'm officially baffled.

Anyone have any experience with MeanWell sealed switching supplies? I've been using this same PS for years as my battery charging station supply for years with no problems with an Arduino 2560 controller.

TIA,

Frank
 
Are you cutting VUSB on your Teensy's ? It seems you should be as you describe external power and connection to a PC.
 
rcarr said:
Are you cutting VUSB on your Teensy's ? It seems you should be as you describe external power and connection to a PC.
Click to expand...

When I power the Teensy from USB, I don't have external power hooked up. In the case of this test, I only have the grounds connected to produce a ground reference for the stepped-down battery charging input voltage. In any case, the +V power to the Teensy goes through a 5V LDO regulator before being applied to Vin, so even if they were both connected at once there should not be an issue.
 
Hello Frank, this statement is worrying.
paynterf said:
Looking at the 3.3V output on the Teensy, I can see the voltage go up to 3.3V as it should, but then almost immediately drop back to 1.9V, at which point I get the USB 'down' beat.
Click to expand...
I would look into this first as it looks like the onboard regulator is giving up due to too much current.

Also, this line in setup():
Code: 
pinMode(CHG_CONNECT_PIN, INPUT_PULLDOWN);
Why do you pulldown the A1 pin? Could that screw up the voltage divider?

Paul

PS: had only good experiences with MeanWell powersupplies sofar
 
PaulS said:
Hello Frank, this statement is worrying.

I would look into this first as it looks like the onboard regulator is giving up due to too much current.

I agree that it sure looks like the onboard regulator is getting dragged down, but I think that symptom is a result of input circuitry damage producing a 'near-short' to ground.

Also, this line in setup():
Code: 
pinMode(CHG_CONNECT_PIN, INPUT_PULLDOWN);
Why do you pulldown the A1 pin? Could that screw up the voltage divider?

Yes, it does 'screw up' the voltage divider, but not enough to matter, and I wanted to make sure the input wasn't floating in case there was some other ESD mechanism floating around.

Paul

PS: had only good experiences with MeanWell powersupplies sofar
Click to expand...

I too have had very good luck with MeanWell products. In fact, my lab power supply uses a 28VDC MeanWell open frame power supply.


So, at this point I plan to use yet another T3.5 in a set of probing experiments. The first one (already performed) was to simply load up a T3.5 with my 'Pin Test' sketch, and place the T3.5 near (but not touching) my robot chassis, and power it from USB only, as shown below.

IMG_6651.jpg


Then run a series of connect/disconnect cycles with the charging plug/jack, and confirm that the T3.5 survives. This worked, as expected (how could it NOT?), and doesn't really eliminate anything other than maybe magic, but it does create a baseline for the following experiments. The next one will be to place the T3.5 on the robot but not connected to anything. Assuming that works, the next step will be to only connect robot system ground to T3.5 ground, with nothing else connected. If the T3.5 survives this one, then (I think) it eliminates ground loops as the cause. We'll see.

Frank
 
Part of that schematic fragment bugs me.

While it isn't shown as being connected to anything else, the INA169 output is connected to a capacitor rather than the required resistor. The INA169 puts out a current that you have to convert to a voltage. With a capacitor I don't know how high that voltage will go but it will be more than you expect.
 
UhClem said:
Part of that schematic fragment bugs me.

While it isn't shown as being connected to anything else, the INA169 output is connected to a capacitor rather than the required resistor. The INA169 puts out a current that you have to convert to a voltage. With a capacitor I don't know how high that voltage will go but it will be more than you expect.
Click to expand...

You have a good eye for discrepancies, but the Adafruit version of this module contains an on-board 10K resistor to produce 1V/Amp voltage output. The 1uF cap is probably not necessary, and isn't actually installed on the robot at this point. Moreover, neither of the outputs from the two 1NA169's (one for run + charge, and one for just run) are actually connected to the Teensy.

Frank
 
So I *may* have a handle on my T3.5-killing problem. After performing the above 'near but not connected' experiment, I followed it with one where the T3.5 was mounted on the robot chassis, but not connected to anything. As expected no problem after repeated charging power connect/disconnect cycles. The next experiment was to connect T3.5 GND to robot GND only - nothing else connected, with power to T3.5 supplied via USB. No problems after repeated charging power connect/disconnect cycles.

Since I now had a common ground reference for the T3.5 and the robot, I was able to look at the waveform at the output of the connect/disconnect resistive voltage divider (see the above schematic). I ran a long series of connect/disconnect cycles using my Hanmatek DOS1102. I observed some very substantial ringing on this line, clearly enough to damage the input, as shown below.

IMG_6654.jpg

On the above trace, the vertical scale is 5v/div, and some of the excursions are close to +/- 20V! After doing some more experimentation, I began to realize that what was happening was the center (positive) contact of the particular 2.1mm plug I was using (left-hand plug in the above photo) was intermittently coming into contact with the grounded shell of the plug, causing a momentary short across the power supply output, which was making the positive supply line, and everything connected to it, to ring badly.

IMG_6655.jpg

I've been using this connector for years with no problems, but the power supply shorting issue never arose because I had a non-conductive docking collar around the charging port and I now think that prevented the center contact from touching the grounded shell of the plug.

I performed a number of connect/disconnect cycles with my lab power supply using the right-hand plug style with a non-conducting tip, and this exhibited no ringing issues at all.

I'm not completely satisfied yet, but I think I might have the smoking gun now. We'll see.

Frank
 
MarkT said:
I recommend moving over to using the styles of connector used in the RC model world, rather than
barrel jacks (many of which I find to be very loose, unreliable and intermittent, as well as pulling
out far too easily).

This pages shows many of the sorts available: https://www.hobbywingdirect.com/blogs/news/14906981-rc-101-battery-balance-connector-type
Click to expand...


Unfortunately, the connector style is mostly driven by the need to charge autonomously. The robot drives itself onto a charging station and plugs itself into the charger. When charged, it backs itself off again. This pretty much dictates a circularly symmetric plug/jack arrangement. See this post for some video showing the docking process.
 
I believe I have now completely solved this issue, by using a LED/photoresistor pair to break the conductive path from the charging circuit to the Teensy. The LED part of the pair is the 2-color LED supplied with most TP5100 modules, installed onto the designed-in PCB pads on that module. The GL5537 photoresistor part of the pair is installed nose-to-nose with the LED to produce basically singe-digit resistances when the LED is illuminated. I tested this on a breadboard setup using a 20K pullup to 3.3V, simulating a Teensy GPIO set for pinMode(PIN, INPUT_PULLUP), as shown below:
IMG_6657.jpg

See this post on my blog site for all the gory details.

Frank
 
You must log in or register to reply here.
Back
Top