Teensy 3.1 possibly overheating somehow

Status
Not open for further replies.

devicer

New member
I am having a problem with a teensy 3.1 i bought, it's working ok to upload code but when i attached it to an external supply (measured at 4.96v) it quickly starts to get very very hot.
Should i be seeing a noticeable temperature increase at all? Last loaded code was the neopixel strand test. This happens when no other wires are attached apart from GND and Vin either side of the USB connector. I have a few wires soldered direct to SPI pins and for the OCTOWS2811 library which i was testing previously before noticing the temperature problem but it still occurs when they're all disconnected and the USB too. One other thing of note is that the heat seems to be purely centred on the main chip. I've been disconnecting before long in case i'm damaging it.

Could it be a short somewhere and is there a good way to establish further what the issue could be? I only have a standard digital multimeter available, no scope atm :(

Cheers!
 
It should not get very hot. Even running at 96 MHz, the chip gets only slightly warm.

Usually a hot chip means something is shorted somewhere.
 
I'm duplicating my other post here, hoping to find a response:

I'm facing sort of the same problem here. Here's my schematic:

Printing Preview.jpg

I've cut the trace between VUSB and VIN. A physical switch allows to power the Teensy either through a battery (Li-Ion, 3.7V) or through VUSB. Two connectors supply 3.3V to peripherals, either through Teensy's internal 3.3V regulator or via an external MCP1700 voltage regulator. A sensor board and an SD card are always powered from Teensy's 3.3V output. They should NOT need more than the 120 mA that the internal voltage regulator can supply.

I haven't yet traced the exact circumstances under which the Teensy gets hot. I have the impression, though, that it's when it's running on battery with no USB bus connected. The board gets extremely hot, but continues to work.

Has anyone made similar experiences and found a solution?

Thanks in advance, I'll post further insights as soon as I have some findings...
 
Last edited:
Just for the records: I found the error. Stupid, as always.

Double-checked the pin assignments and found that obsolete and rotten piece of debug code in a library. I had put it there to discover a very specific problem, long ago and forgot about it. It configured pin 14 (which is directly connected to the battery voltage) as an output and set it to LOW. That pin sank quite some current...
 
Last edited:
I've had the same issue on 3 Teensy 3.1's. I've triple checked wiring, but that doesn't mean there still isn't an issue somewhere.

I'm trying to run 2 MPU9250's (I2C0, I2C1), a RS232 Serial com, and a CANopen control protocol. This is a lot of data going through, but the Teensy is getting hot to the touch, and then won't respond. I will attempt to check wiring again, but is there any way that this could overheat with so much I/O happening at the same time? I'm also running off of a computer motherboard, (Commell LS-37B), so not sure if this could be the issue either.

Any help would be awesome!

Thanks!
 
cjohnston,

I have to correct myself. Yes, there was the described software bug that caused a short-circuit, but that wasn't the cause of my overheating.

It still occurs occasionally when the Teensy is running on battery. Never saw it when running on USB, but that may be because the USB port is limited to 500 mA. Once I was able to measure it and the Teensy system drew a whole ampere from the battery. Under normal conditions, the whole system with sensors and radio pulls 130 mA.

As you can see from the schematic above, I have a separate voltage controller for the radio and the Teensy's 3.3 V output is only used for the sensor board (GY-80) and an SD card. No overcurrent here - I think.

WHEN it overheats, it seems to happen even before calling setup(). The K20 reaches about 70-80ºC (measured with an infrared thermometer). I then turn it off and on again and generally it works without any problem.

Given that my system consists mainly of standard modules (Teensy, GY-80, SD card, voltage regulator MCP1702, battery charger MCP73832 and radio module NRF24L01+), I didn't include bypass capacitors for the modules, as all of the have some on board. For the voltage regulator and the battery charger, I used the recommended values. The 220uF capacitor in the VCC line exists to provide me with an additional millisecond or so on a power fail. I use the power fail interrupt to save the current status in EEPROM and recover when the power returns.

Some of the modules are optional, but it seems to me that the problem occurs in all possible configurations.

Here's my question to the more experienced circuit designers: Is it possible that the circuit starts to oscillate due to spikes on the power line and that this causes the observed overheating? If so, what would be the most appropriate measure? Where (physically) should I add more bypass capacitors? Or is a ferrite bead in the power cable more effective?

I'm pretty clueless on this. My ham radio knowledge is a bit rusty and I'm more inclined to the digital world. But somehow this behaviour doesn't seem digital at all...

I built a test bench with another Teensy, a power mosfet and a 0.1 Ohm resistor in series in the power line to measure the current. I switched the system on and off for hours, without a single overheating event.

I thought of a software workaround that measures the Teensy's temperature and resets it in case of high temperature. But if the problem is caused by power oscillations, that wouldn't make any difference.

Really, I'm clueless. Any idea will be highly appreciated...
 
Thanks for the info...

I'm having a different problem however, my boards are toasted. When I plug them into the USB, I only see 0.9V on the 3.3V pin. What's strange is they would tend to run fine for about 1-2 hours, and the I wouldn't be able to push uploads, but the CPU would still see the serial port, and then I couldn't push any updates at all and the CPU didn't recognize it. Not to mention by this point the chip could have fried eggs no problem.

Is it possible there was a bad batch of chips?

One question I do have is if there is any amount of processor load or software that could cause this. Assume I ran an overclocked chip (96MHz) utilizing every I/O port available and doing a bunch of math in its downtime, could it overheat from this?

Thanks!
 
@jbliesener
Are you connecting the output of the Teensy 3.3V regulator directly to the output of the MCP 1700 output
without any diodes to protect against back currents ?
 
One question I do have is if there is any amount of processor load or software that could cause this. Assume I ran an overclocked chip (96MHz) utilizing every I/O port available and doing a bunch of math in its downtime, could it overheat from this?
Thanks!

No, not from overclocking or "math".
But perhaps too much current on the pins ?
You could disconnect all pins and try again to test this.
 
change your code to loop without doing GPIO output.
I have mistakenly damaged the push-pull output port on a pin causing an internal low resistance path = heating.

No doubt you've verified 3.3V is what it should be.
 
@mlu

Thanks for your feedback. I admit the schematic's resolution isn't perfect, but there's no connection between the Teensy's 3.3V output and the output of the MCP1700. The external connectors on the right hand side are powered by a signal called "+3.3V", which is provided through a jumper called JUMPER3 or JP2 right next to the (optional) MCP1700. In its default setting (without the MCP1700), JP2 connects it to +3.3VP, which is Teensy's 3.3V output pin.

When you supply the board with the MCP1700, you'll cut that default solder jumper between pins 1 and 2 of JP2 and connect pins 2 and 3, which will supply the +3.3V line through the MCP1700. In that configuration, +3.3VP only supplies the sensor board and the SD storage.

Here's a picture of the solder jumper on board. Do you see the trace between the right two pins?

screenshot7.png
 
Last edited:
I've had both - a Teensy 3.1 and 3.0 bricked yesterday.

Running the SparkFun regulated 5V->3.3V Xbee regulator adapter that has worked well for years on other boards including the Arduino.
Fed by a separate 5V regulated power supply connected on VIN and GND.
Serial1 (RX1, TX1) to the Xbee is on pins 0,1 and a PWM output on pin 3.
Logic control pins only (motor powered separately) using pins 4, 8, 20 and 16 for DigitalWrite High/Low.

Works fine with external power OR USB independently. Ran the Teensy all night - no issues.

Then I cut the trace as suggested by the USB pad since I wanted the option to update the code periodically. Disconnected all logic pin connections to Teensy board.

Results:
1. Now completely unable to update code on the board via USB
2. Next, Applied the 5V regulated power to VIN/GND
3. No code update possible either
4. Removed all external power and USB cable. Re-soldered the trace.
5. Applied USB power only. Teensy 3.1 which became extremely hot. Same result on Teensy 3.0
6. Within 15 seconds - both were bricked as USB port does not see the Teensy's anymore. Instead, Teensy gets very hot with just USB cable now.

I'm not sure if both the Teensys failed at step 2 - the only step where something could have happened.

Any ideas appreciated.
I'm beginning to seriously worry about the trace cutting suggestion as sub-optimal too.

Vic
 
Last edited:
Status
Not open for further replies.
Back
Top