How to destroy a Teensy, or, what NOT to do

[MrExplore]

Hi All,

Mistakes, we all make them. But we also learn from our mistakes.

I think I might have fried/destroyed/killed my first Teensy today, so sad

- Wouldn't it be nice if we could learn from each others mistakes?
- Would it be an idea to have a central thread of how you damage, kill or destroy a Teensy
- Would it be valuable to post your mistakes for others to learn from, and the other way around, learn from others mistakes ?

I think so.

So I'll start off with my first fried Teensy.

This is what I think happened...

The board I destroyed: Teensy 4.1
How did I destroy it: By connecting V+ of a DS18B20 with resistor to Vin on the Teensy

I was trying a DS18B20 temperature sensor wired up like below, with a 4.7K resistor between V+ and the signal wire.
First I had the V+ on the 3.3V pin and I couldn't read the sensor.

So I thought, lets see what the sensor does when I feed it 5V from the Vin pin.
As I understand the Vin pin is at 5V when connected to USB, so I put the V+ of the sensor to Vin.

Overlooking that the V+ was bridged to the signal pin via the resistor. So I actually put 5V on an input pin this way?
(Teensy 4.1 pins are noy 5V tolerant)


Is my assumption correct or is there hope?

[BriComp]

Did you have it wired exactly as in the graphic, because it shows the GPIOx going into the 3.3V pin?

[MrExplore]

Sorry, the image might be confusing. I found it and its actually not a Teensy.

The way I had it hooked up was like this:

R = 4.7K



Making this schematic I'm like, yaeh, that was probably a dumb idea...

[PaulStoffregen]

Your diagram appears to have the DS18B20 connection very wrong. This is the correct DS18B20 pinout:



Looks like you've connected +5V to the GND pin, GND to the DQ pin, and Teensy pin 2 to the VDD pin. All 3 pins are connected to the wrong place!

If you had used 3.3V power, this probably wouldn't have been so bad. But 5V power really increases the risks of damage if you connect a chip the wrong way. To understand why, the silicon body of most chips acts as a big diode. It is an artifact of the way chips are manufactured, where transistors of different types are created inside regions of different material. The junction of those regions of N and P type material forms a diode. It's usually called the "body diode". Normally this diode never conducts, because the cathode is the positive power and its anode is the negative power rail. Here's a visualization of the body diode inside a DS18B20.



Just now I measured a DS18B20 chip with the diode mode of my Fluke 77 multimeter (which uses approx 0.6 mA test current) and sure enough, it measures 0.614 volts with that test current flowing from GND (red multimeter lead) to VDD (black lead). The DS18B20 chip, or at least a genuine Maxim one, definitely does have this body diode. The many cheap counterfeit chips on the market are probably the same. All modern (since the late 1980s) CMOS chips are made this way.

If you were to connect a DS18B20 the wrong way as shown in the diagram on msg #3, the internal body diode will cause the 5V power to directly drive pin 2 with approx 4.4V. That will very likely damage your Teensy 4.1, because the pins aren't supposed to be driven higher than 3.3V and going over about 3.9V with any substantial amount of current flow is very bad.

[PaulStoffregen]

Now, about the original question of the 4.7K pullup resistor connected to 5V power. While it's not advisable and does stress the Teensy pin somewhat, the 4.7K resistor issue alone does not destroy a Teensy 4.1. The ESD protection diode connected inside Teensy 4.1 between the digital pin and 3.3 power is able to protect Teensy from damage when the current is limited to only from the 4.7K resistor.

To put this to the test, I wired it up just now on my workbench and connected my oscilloscope to watch the 1-wire signal.



I ran the OneWire DS18x20_Temperature example. The only change was to configure for pin 2, so I could test with the same circuit (but connecting the DS18B20 properly) as shown in msg #3. It's definitely working. Here's the result in the Arduino Serial Monitor.



Turns out the chip I used is actually DS18S20. It's also pretty warm on my workbench with 2 desk lamps with old incandescent bulbs pointing at the surface.

Here is the waveform my oscilloscope sees.



This scale is 1 volt per division. You can see most of the time at logic high is around 3.8 to 3.9 volts. That is the action of the 5V power causing approx 0.25 mA to flow through the 4.7K resistor and the ESD protection diode to 3.3V. Fortunately Teensy always consumes much more than 0.25 mA on its 3.3V power line, so this extra current doesn't raise the 3.3V power up. If a much larger current were to flow, it could damage the chip by driving the pin too high, but damage would also be very likely if the current flow were more than Teensy's power consumption and the 3.3V power line were to get pulled up higher.

So again, I want to emphasize this connection with the 4.7K resistor is not advisable, even though the 0.25mA current doesn't destroy Teensy 4.1. It does put some stress on the ESD protection diode, which probably isn't good long-term.

But the real problem is this sort of connection with 5V power is very risky if you might connect the hardware the wrong way. If the DS18B20 chip is connected wrongly, as in the diagram on msg #3, or if the wires come loose and the 5V power accidentally touches the data pin wire for even the fleeting moment, those sorts of mistakes absolutely will destroy Teensy 4.1.

[MrExplore]

Wow, that is the most elaborate and detailed forum reply I ever had
Thanks for that and all the additional info.

First, my apologies for posting dodgy schematics of found images (post #1) and a Fritzing schematic I threw together at 6:30 this morning and shows wrong connections (post #3).

So to get to the bottom of this took my actual sensor and cut off the shrink tube to see the connections.
TLDR version: I messed up the connection of the resistor between V+ and the Data line.


Here is my sensor and the actual connections:



V+ to V+, Ground to ground and Data to Data, all seems fine right?

No not really, this is what I saw when opening it up:



I think this is where it went wrong. As you mentioned:

...if the wires come loose and the 5V power accidentally touches the data pin wire for even the fleeting moment, those sorts of mistakes absolutely will destroy Teensy 4.1

In the image above it is clear that there probably was a direct connection between the 5V and the data line due to improper isolation and bad soldering. While having the V+ connected to the 3.3V I couldn't read the sensor but it didn't destroy the Teensy. Connecting the V+ to 5V and thereby putting 5V on an input via the short, yeah, that probably killed it .

I do have a 4.1 backup (I always order double or triple in case of this like this).
I'll take extra care of soldering it up in a safe way so this doesn't happen again.

@Paul: I really feel kinda sorry for ruining one of your Teensies

[MrExplore]

Ok,

So who's next? No one? Ok then I'll go again...

I had my Teensy 4.1 running a web-/socketserver with temperature sensor, TFT screen, RTC battery and joystick attached, serving a web interface from the SD card. Everything worked fine until I edited the files on the SD card, put it back in and... the Teensy seemed to be dead.

It was not as bad as I thought. After some sweating and swearing I found the SD is not initializing:

void setup(){

  Serial.begin(115200);

  Serial << "Checking SD Card" << endl;
  
  // Ceck SDcard =====================================================
  
  if (!SD.begin(chipSelect)) { 
    
    Serial << "SD Card failed" << endl;
    return;                                             // init failed
  }

- "Checking SD Card" prints fine
- After a few seconds the serial monitor loses connection and reconnects
- Again "Checking SD Card" prints out
- One out of ten times "SD Card failed" (partially) prints

What I tried:
- Formatting the SD card
- Try two other SD cards
- Going back to working code versions

For now I took out all SD card and webserver code and run an HTML locally.
The Javascript sets up the websocket connection and this way it works as expected.

However, what did I do to damage the SD card reader?
I took out and inserted the SD many times the past days but what was it that killed it? Mechanical damage, ESD?

Thanks for reading!

[defragster]

Does the SD card work right on a computer? Or is it really damaged?

Some T_4.1's with many card swaps here in testing and no such issues yet as far as the SD Socket failing - though I have an sd card or two in quarantine, not sure if they are good.

How much power is coming from where and how much is in use with the connected hardware? Is it possible the SD card current draw is just maxing out the available current and it is 'failing' for that reason?

[PaulStoffregen]

What I tried:
- Formatting the SD card
- Try two other SD cards
- Going back to working code versions

Not seen on this list things tried is running the card diagnostic programs, specifically File > Examples > SD > CardInfo or File > Examples > SdFat > SdInfo (and showing us a screenshot or exact copy of whatever they print).

[MrExplore]

Thanks for the feedback

Does the SD card work right on a computer?

Yes it does, yes they do, all tested cards are readable on my windows laptop

How much power is coming from where and how much is in use with the connected hardware?

Power comes from the USB on my desktop workstation, I don't think that's the problem.
I've swapped and used the SD many times without any issue.

Not seen on this list things tried is running the card diagnostic programs, specifically File > Examples > SD > CardInfo or File > Examples > SdFat > SdInfo (and showing us a screenshot or exact copy of whatever they print).

Thanks, I will try that tomorrow and report back ok.

EDIT: I did not hotswap the SD

[MrExplore]

Ok, I tried the suggested examples CardInfo and SdInfo and guess what, they both gave output on the SD cards. So I uploaded my webserver code and yes, that also "magically" worked again. I've tried to think about what I had done or changed but can't come up with anything.

However, I'm not sure about the history of these cards, I picked them up at the local phone repair shop and chances are they have been used pretty intensively in phones.

Today I put in a new unused card and I haven't had any problem since.

So my guess would be faulty unreliable SD cards?



The output from SdInfo:

On the 8GB card:

SdFat version: 2.1.0
Assuming an SDIO interface.

type any character to start
init time: 111 ms

Card type: SDHC

Manufacturer ID: 0X2
OEM ID: TM
Product: SA08G
Version: 6.1
Serial number: 0X1E260D48
Manufacturing date: 6/2013

cardSize: 7744.78 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true

OCR: 0XC0FF8000

SD Partition Table
part,boot,bgnCHS[3],type,endCHS[3],start,length
1,0X0,0X82,0X3,0X0,0XB,0X94,0XE7,0XAD,8192,15118336
2,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
3,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
4,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0

Scanning FAT, please wait.

Volume is FAT32
sectorsPerCluster: 64
clusterCount:      236096
freeClusterCount:  236079
fatStartSector:    12694
dataStartSector:   16384

type any character to start

On the 16 GB card:

SdFat version: 2.1.0
Assuming an SDIO interface.

type any character to start
init time: 8 ms

Card type: SDHC

Manufacturer ID: 0X1B
OEM ID: SM
Product: 00000
Version: 1.0
Serial number: 0X57FD9301
Manufacturing date: 10/2011

cardSize: 16007.56 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true

OCR: 0XC0FF8000

SD Partition Table
part,boot,bgnCHS[3],type,endCHS[3],start,length
1,0X0,0X82,0X3,0X0,0XC,0XFE,0XFF,0XFF,8192,31256576
2,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
3,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
4,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0

Scanning FAT, please wait.

Volume is FAT32
sectorsPerCluster: 64
clusterCount:      488256
freeClusterCount:  488223
fatStartSector:    8754
dataStartSector:   16384

On the 32GB card:

SdFat version: 2.1.0
Assuming an SDIO interface.

type any character to start
init time: 216 ms

Card type: SDHC

Manufacturer ID: 0X3
OEM ID: SD
Product: ABLCD
Version: 8.0
Serial number: 0X4C27B3B1
Manufacturing date: 3/2011

cardSize: 31914.98 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true

OCR: 0XC0FF8000

SD Partition Table
part,boot,bgnCHS[3],type,endCHS[3],start,length
1,0X0,0X82,0X3,0X0,0XC,0XFE,0XFF,0XFF,8192,62325760
2,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
3,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
4,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0

Scanning FAT, please wait.

Volume is FAT32
sectorsPerCluster: 64
clusterCount:      973584
freeClusterCount:  973567
fatStartSector:    9362
dataStartSector:   24576

[PaulStoffregen]

I've tried to think about what I had done or changed but can't come up with anything.

Any chance the power supply available to Teensy was different? Maybe different computer, or different USB port or hub, or longer or different cable?

The combination of 600 MHz CPU, Ethernet, and certain SD cards (especially when writing where large internal blocks get remapped) can draw quite a bit of current. If you're getting it all from the USB cable, small differences in the upstream USB power source or the gauge of the wires inside the USB cable can make quite a difference.

[MrExplore]

I used the same computer, usb cable, port. Also no change in the attached TFT, sensor (DS18B20), joystick or connected CR2032 for the RTC.

The most annoying errors, are those that cannot consistently be reproduced. (MrExplore, 2022, and surely many before)

At this point I would really like to blame the SD cards, there is still an itch to get to the bottom of it though.
But since I haven't had any problems with the brand new SD card, I'm willing to let that go.

[PaulStoffregen]

Info in msg #11 sure looks like all 3 cards are working properly.

I have no more guesses left as to the cause of trouble. Only suggestion I have at this point is to add more ways your program shows status, so you'll have more info than "the Teensy seemed to be dead" next time something goes wrong. One common approach is a "heartbeat LED" which slowly blinks as your program runs, maybe even blinks at differing speed depending on what it's doing (eg, waiting on SD card, waiting on network activity, etc). If you're using 1.57-beta, maybe also look at the new (and not yet well documented) CrashReport breadcrumbs feature.

[MrExplore]

Yeah debugging and troubleshooting, my all time favorite past time
Breadcrumbs, sounds interesting, I'll look into it when it's a bit more documented, ok?


But here's an update.

Disclaimer: I'm just guessing here, I'm not an expert and it's still kinda vague.

I have taken out of the equation:
- the TFT display. MSP2202 TFT using the ILI9341_t3n library
- the timer "Timer.h", http://github.com/JChristensen/Timer

Good news, so far the SD initialization problems are gone.

I'm not sure if it's the TFT or timer library that might have caused issues.

1. I'm not testing the TFT again because I only used it for feedback, demo, debugging

2. It seems like standard Arduino timer libraries do not play nice on a Teensy.
I had several "Could not compile for Teensy 4.1" issues without any further info, with different timer libraries.


Anyway, my web- and socketserver is working and seems to be stable now.

I'm controlling hardware over the internet, yay Teensy!