Teensy 3.0 CPU very hot

florin

New member
Hi,

I am using Teensy 3.0 for more than one month now (good fun!) including powering it from a LiPo battery. Today I have hooked an OLED display (SSD1306) and while setting it up (loaded the Adafruit's SSD1306 library and it worked) I've noticed that the CPU on the board got extremely hot. After a few unsuccessful tries to find the cause I've unsoldered all peripherals from the board.
The board is still functional. SPI, I2C and Serial all work just fine. I was running at 24MHz anyway and I didn't change that setting in a long time. Now I've loaded the blinker that works as expected. Still, the CPU is running extremely hot, I barely can hold my finger on it and I clearly know that the CPU never got this hot before.
Is there anything that I can do to remedy this or is there any way to debug this behaviour?
The environment is Arduino 1.0.4 and the latest Teensyduino 1.13 (upgraded yesterday).

Thanks!
florin
 
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.

As Florin mentioned, 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:
Never mind, found it. Yes, it was getting hot when on battery, which the processor can detect through its ON_BATTERY signal, fed to pin 14. I haven't implemented that feature yet in software (say: I never read that pin). I didn't set it to input either, as all pins are in input mode by default on startup.

What I had implemented, though, was this rotten bit of code. I used it to debug a very specific situation on an early prototype (that didn't have the ON_BATTERY signal yet):

Code:
#define DEBUG_FAILURE_TRIGGER_PIN 14

...

#ifdef DEBUG_FAILURE_TRIGGER_PIN
	cout << "Setting failure pin" << endl;
	pinMode(DEBUG_FAILURE_TRIGGER_PIN,OUTPUT);
	digitalWriteFast(DEBUG_FAILURE_TRIGGER_PIN,LOW);
#endif

...

So, the Teensy sent a LOW to the pin, while it was held on HIGH externally. That means that the chip will sink quite some current and start to overheat. No good...

Does anyone have information about the influence of the port DSE (drive strength enable) bit in this situation? The "pinMode" function sets it for output pins, (probably in order to be able to drive LEDs and other high-current devices). What is the exact effect if the bit remains unset? Does it act as a current limiter or will it blow up the chip even easier, as the low-current driver output won't be able to handle the higher current? Furthermore, I didn't find any information in the datasheet about the max source and sink current with DSE unset. Anybody knows?

The only thing I still have to discover is why it heated up only sometimes when on battery...
 
On Teensy 3.1, all the pins have the drive strength feature. On Teensy-LC, only 4 pins have it. The pins without ignore the DSE bit.

Freescale's documentation says this bit enables strong drive strength. On Teensy 3.1, the spec say 2 mA and 10 mA recommended max current. On Teensy-LC, the specs are 5 mA and 20 mA... so you get higher current, but only 4 pins are configurable.

However, the maximum current that can actually flow is MUCH higher than these recommended current specs. Freescale is very conservative in how they rate their parts.

They don't document what's actually inside the chip, but it's not too difficult to guess if you've designed a chip before. Output pins are driven by two huge transistors (huge relative to other stuff on the chip). Logic circuits make the 2 gate control signals for the 2 transistors, based on all the on-chip stuff that might want the output driven high or low. Conceptually, you might think of several things combined together by a logic gate that drives the output pin... but actually, more gates (with small transistors) make 2 control signals that ultimately turn the 2 huge output transistor on or off.

Huge transistors are actually banks of smaller ones connected in parallel. They probably tied the gates of 20% of output transistors to the control signals directly, and the other 80% of the mosget gates get driven by the control signals combined by logic with the DSE signal. When DSE is set, the 2 outputs allow all the transistor segments to control the output, but when it's cleared, fewer of the transistor segments are used.

It's actually likely to be a bit more complicated, because the pins also have a slew rate limiting feature.... so there's also some analog circuitry involved in controlling the gate drive.
 
Thank you, Paul.

So, from what I understand, it's more likely to blow the chip when DSE isn't set, as the same current would probably flow through less transistors, right?

If it were, it means that you never ever should short an LC pin that isn't rated for high current. Did someone run that test already?

Anyway, thanks for setting th bit for us in the library. Might have saved a Teensy's life.
 
Back
Top