Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

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

  1. #1
    Junior Member
    Join Date
    Jun 2022
    Posts
    10

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

    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?

    Click image for larger version. 

Name:	DS18B20.jpg 
Views:	2 
Size:	40.1 KB 
ID:	28763
    Last edited by MrExplore; 06-20-2022 at 07:44 PM.

  2. #2
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    756
    Did you have it wired exactly as in the graphic, because it shows the GPIOx going into the 3.3V pin?

  3. #3
    Junior Member
    Join Date
    Jun 2022
    Posts
    10
    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

    Click image for larger version. 

Name:	DS18B20_on4.1.jpg 
Views:	7 
Size:	52.2 KB 
ID:	28766

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

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,398
    Your diagram appears to have the DS18B20 connection very wrong. This is the correct DS18B20 pinout:

    Click image for larger version. 

Name:	ds18b20_pinout.png 
Views:	0 
Size:	13.3 KB 
ID:	28767

    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.

    Click image for larger version. 

Name:	ds18b20_diode.png 
Views:	0 
Size:	11.8 KB 
ID:	28768

    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.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,398
    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.

    Click image for larger version. 

Name:	ds18b20_testing.jpg 
Views:	2 
Size:	211.4 KB 
ID:	28772

    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.

    Click image for larger version. 

Name:	screenshot.png 
Views:	3 
Size:	46.2 KB 
ID:	28773

    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.

    Click image for larger version. 

Name:	file.png 
Views:	2 
Size:	38.1 KB 
ID:	28774

    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.

  6. #6
    Junior Member
    Join Date
    Jun 2022
    Posts
    10
    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:

    Click image for larger version. 

Name:	01.jpg 
Views:	8 
Size:	88.8 KB 
ID:	28778

    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:

    Click image for larger version. 

Name:	02.jpg 
Views:	6 
Size:	56.2 KB 
ID:	28781

    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

  7. #7
    Junior Member
    Join Date
    Jun 2022
    Posts
    10
    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:

    Code:
    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!

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,015
    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?

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,398
    Quote Originally Posted by MrExplore View Post
    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).

  10. #10
    Junior Member
    Join Date
    Jun 2022
    Posts
    10
    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
    Last edited by MrExplore; 06-26-2022 at 08:28 PM.

  11. #11
    Junior Member
    Join Date
    Jun 2022
    Posts
    10
    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:
    Code:
    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:
    Code:
    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:
    Code:
    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

  12. #12
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,398
    Quote Originally Posted by MrExplore View Post
    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.

  13. #13
    Junior Member
    Join Date
    Jun 2022
    Posts
    10
    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.

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,398
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •