Two Teensys 3.1 dead after a few hours in operation ...

Status
Not open for further replies.

wkorosec

Member
Hi,
I bought two Teensy 3.1 last week from http://shop.boxtec.ch/ (Switzerland). I connected it to my Macbook Air - no problems to download and run programs on it. After a few hours the first Teensy stopped working. Unable to download code - even after restarting the Mac an unplugging the USB cable. Also tested on my PC-Box. The same happend to the second Teensy - stopped working after about one hour :mad:

I solderd pins on the Teensy to use it on a breadboard, but had no other hardware attached, no 5 Volt stuff ...

Any help or idea - I am frustrated ....

Best regards & many thanks for your help
Wolfgang
 
You have omitted to post some basic info in your frustration.
Any console message from the teensy loader that you could copy paste ?
There is usually some form of system response of the teensy uploader when there are problems connecting to the Teensy and it is rather unlikely that you've destroyed it by just connecting it to a USB. I've hade a few "accidents" when trying to test things in a hurry and find the Teensy to be quite a resilient beast!

What Arduino Environment. And Teensyduino version are you using ?
 
Last edited:
I'm really sorry this has gone so badly. From only the limited info in this message, I can't possibly know what happened.

It sounds like you've already tried the obvious things, rebooting, using different computers, etc. Here's a troubleshooting page with solutions to the most common problems.

http://www.pjrc.com/teensy/troubleshoot.html

If that doesn't help, I'd really like to arrange to get those 2 boards back. I'd like to work with them here and try to understand what went wrong. I'm happy to swap them for brand new ones. I know this may not be very practical if you're in Europe, but if the troubleshooting page doesn't help, this is probably all I can do.
 
I am curious. Did they work again after a while to cool off?

My bet is you shorted a pin with a solder bridge, and the chip is overheating. There is 'usually' a fuse that will reset when it cools off. Do you have a magnifier to check your work?
 
From only the limited info in this message, I can't possibly know what happened.
Dear colleagues,
thank your very much for your rapid and helpful information and especially Paul for his friendly offer to replace the boards !!!

More information about this problem:
Computer: Macbook Air, OS X 10.9.1 (Maverick)
IDE: Arduino 1.0.5 with Teensyduino 1.18.RC1
Followed the procedure on the troubleshoot page without success ...

As already mentioned:
Same effect on my PC-box, no 5Volt or higher voltage involved, no electrostatic environment, both boards worked perfectly for a while ...

Verbose output of loader:
Code:
21:19:41: Teensy Loader 1.18-rc1, begin program
21:19:41: Listening for remote control on port 3149
21:19:41: initialized, showing main window
21:19:41: remote connection opened
21:19:41: remote cmd: "comment: Teensyduino 1.18-rc1 - MACOSX"
21:19:41: remote cmd: "dir:/var/folders/mx/km_m9cmd127fmrc_rlkwnwtc0000gn/T/build7003605266018879305.tmp/"
21:19:41: remote cmd: "file:UniPhone.cpp.hex"
21:19:41: File "UniPhone.cpp.hex". 14460 bytes, 6% used
21:19:41: remote cmd: "status"
21:19:41: status data sent
Nothing happens after pressing button.

When connected to USB:
3.3 V between GND and 3.3V out (3rd pin)
3.3V between GND and Program Pin
0V Between GND and Program Pin when button pressed
100 mV between GND and RESET Pin - no change when button is pressed.

No heating up of components when connected to power, soldering is OK (for DIY level - I hope...)

IMG_0686.jpg

Best regards & many thank for your help,
Wolfgang
 
Computer: Macbook Air, OS X 10.9.1 (Maverick)

Can you quickly check "About This Mac" for the specific model?

For example, on my MacBook Pro (which has 10.7 Lion), "more info" says "17-inch, Late 2011", and "System report" says the model identifier is "MacBookPro8,3". Apple changes this stuff sometimes, so Maverick might has slightly different names. It would help if you could get the model identifier.


100 mV between GND and RESET Pin - no change when button is pressed.

That's definitely not right.

But are you measuring reset on the edge of the board, which is now DAC/A14 on Teensy 3.1. On 3.1, the reset signal moved to a test pad on the bottom side. Details are at the end of this page.

http://www.pjrc.com/teensy/teensy31.html

Normally reset should be 3.3V when your not pressing the button.

If it is 0.1 volts, the big question would be whether it's a DC voltage, or occasionally pulsing to 3.3V for short times. Some multimeters can read that with frequency mode or AC voltage mode (where you'd see zero if the pin is truly a DC voltage, or some significant number if it's pulsing with a low duty cycle).

Pulsing behavior on reset can indicate bad code somehow got loaded onto the Teensy 3.1 memory. The chip has a watchdog timer that will keep rapidly rebooting the chip. Each time it reboots, the reset line goes low.

When you press and hold the pushbutton, the Mini54 will drive the reset line low while you're holding the button down. It would be tricky to keep a multimeter lead on that reset pad while pressing the button, but if you can do that somehow, you might be able to observe if the 100 mV changes to nearly zero volts in response to holding the button. That could give some indication if the Mini54 is doing its job.

Then again, the most effective thing might be to just send those boards to me and we'll get replacements shipped out to you. It's up to you if you want to poke at it to learn more.
 
Hi Paul,
About This Mac:
Code:
Hardware Overview:

  Model Name:	MacBook Air
  Model Identifier:	MacBookAir4,1
  Processor Name:	Intel Core i5
  Processor Speed:	1.6 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	3 MB
  Memory:	4 GB
  Boot ROM Version:	MBA41.0077.B0F

No difference in voltage (about 0.1 V in AC and DC mode) between ground and reset when pressing the button (Reset = small pad on the bottom side) .

I sent you the two Teensys today.

Many thanks for your kind help and your excellent customer support !!!!!!

Best regards,
Wolfgang
 
Hi
some vague guesswork:
I configured UART0 into single wire mode as described in the handbook:
http://www.pjrc.com/teensy/K20P64M50SF0RM.pdf , page 1055

"LOOP MODE Select: Loop mode where transmitter output is internally connected to receiver input. The receiver input is
determined by RSRC.
Receiver Source Select: Single wire UART mode where the receiver input is connected to the transmit pin input signal."

_input_C1 |= 32+128; // Single wire mode

Could it be possible that this configuration killed the two Teensys ?? - Do not dare to try that with my new one

Best regards,
Wolfgang
 
Hi Paul,
here it comes...

First experiments with a telemetry systems - the Teensy reads data from sensors and sends it to WLAN bridge.
The LED will blink for a while and the Teensy will keep transmitting bytes on port 1.

Code:
#define MSB_Baud     38400  // Serial baudrate for Unilog & MSB Sensors
#define DISPLAY_Baud 115200 // Serial baudrate for iMSB display
#define DEBUG_Baud   115200 // Serial baudrate for debug port
#define DEBUG_COM    Serial
#define MSB_COM      Serial1
#define MSB_COM_C1   UART0_C1  // <----- Handbook page 1055
#define DISPLAY_COM  Serial2


#define LED 13

void transmitMLink(int sensor_id, byte data1, byte data2, byte data3) {
  // Example:
  // Sensor                                  11   12   13   21   22   23
  // 1    2    3    4    5    6    7    8    9    10   11   12   13   14   15   16   17   18   19   20
  // 0x02,0x00,0x30,0x34,0x34,0x00,0x40,0x06,0x41,0xFA,0x00,0x52,0x6E,0x01,0x00,0x00,0x00,0x00,0xAB,0x03 
  // Adr. 4, value class 1 "Voltage", 12.5 Volt + no alarm; Adr. 5, value class 2 "Current", 18.3A + no alarm 

/* ----- DEBUG CODE -----*/
  DEBUG_COM.print("Decoding ");
  DEBUG_COM.print (sensor_id);
  DEBUG_COM.print ("==> ");
  DEBUG_COM.print(data1, HEX);
  DEBUG_COM.print(" ");
  DEBUG_COM.print(data2, HEX);
  DEBUG_COM.print(" ");
  DEBUG_COM.print(data3, HEX);
  DEBUG_COM.print("  ");
  DEBUG_COM.println();
  DEBUG_COM.flush();
/*----------------------*/ 

// Test data
//  int disp_message[] = {0x02,0x00,0x30,0x34,0x34,0x00,0x40,0x06,0x41,0xFA,0x00,0x52,0x6E,0x01,0x00,0x00,0x00,0x00,0xAB,0x03};
  int disp_message[] = {0x02,0x00,0x30,0x34,0x34,0x00,0x40,0x06,0x41,0x00,0x1B,0x23,0x52,0x3F,0x01,0x00,0x00,0x00,0x00,0xAB,0x03};
  
//  disp_message[9] = data2;
//  disp_message[10] = data3;
  
  for (int i = 0; i < 21; i++) {
    DISPLAY_COM.write (disp_message[i]);
    DISPLAY_COM.flush();
    DEBUG_COM.print (disp_message[i],HEX);
    DEBUG_COM.flush();
  }
}

void setup() {
  //enable serial ports
  MSB_COM.begin(MSB_Baud); 
  MSB_COM_C1 |= 32+128; // Single wire mode   <--------------------
  DISPLAY_COM.begin(DISPLAY_Baud); 
  DEBUG_COM.begin(DEBUG_Baud);
  
  pinMode(LED, OUTPUT);  
  boolean led_on = true;
  
  DEBUG_COM.println("Set Unilog to MLINK Mode");
  // sends an address (0x00 to 0x0f) to the bus every 6ms to switch the Unilog device to MLINK/MSB mode
  for (int n=1; n < 100; n++) {
    digitalWrite(LED, led_on); // blink during initializing Unilog
    led_on = ! led_on;
    for (byte i=1; i< 16; i++) {		    
        MSB_COM.write(i); // send sensor address
        MSB_COM.flush(); // make sure send is complete
        delay(6); // wait up to 6ms for answer
    }
  }
  
  digitalWrite(LED, false); // led off after init   
  DEBUG_COM.println("init done");    
}

void loop() {
  byte data1;
  byte data2;
  byte data3;
  byte dummy; 

  int sensorSeenCounter = 0;
  
  while (true) {  
    for (byte i=1; i< 16; i++) {
      while(MSB_COM.available() > 0) { MSB_COM.read(); } // throw away any received bytes		    
      MSB_COM.write(i); // send sensor address
      MSB_COM.flush(); // make sure send is complete
      dummy = MSB_COM.read(); // read the byte we just sent
      delay(6); // wait up to 6ms for answer
      if (MSB_COM.available() == 3) { // 3 bytes received means: got valid reply
        data1 = MSB_COM.read();
        data2 = MSB_COM.read();
        data3 = MSB_COM.read();
        transmitMLink(i, data1, data2, data3);
      } 
    }
  }
}

Best regards,
Wolfgang
 
Your 2 boards arrived here on Saturday. We're shipping 2 replacements today.

I haven't dug into what happened with your 2 boards..

I did program this code onto 2 brand new Teensy 3.1s here. Both seemed to work fine. I was able to upload many times to each board. Whatever happened with your 2 boards is a mystery. So far, I haven't been able to reproduce the problem here.
 
Hi Paul,
thanks a lot for you kind help and your outstanding customer service.
In the meantime the new Teensy 3.0 and the 3.1 are working without any flaws. I even dared to use my Mac Book Air and the breadboard again. The only thing I replaced is the USB cable.

Best regards and many thanks again!
Wolfgang
 
One thing that was not checked was if the Reset button(s) are shorted. Could be a manufacturing defect or perhaps a solder wisker got where it didn't belong. That could explain the 0.1V on the reset whether or not the button was pressed...

John :-#)#
 
I actually have a similar situation over here - I have many Teensy boards, but they are for reproducing the same robot many times. I have now toasted 2 boards just ....from trying to program them. They haven't been attached to anything. The first one I thought that maybe it could have been my fault somehow (electric-static environment, maybe?? Off chance?) But I am also using a Mac OS 10.9 and well, both my 3s have been killed while I have been attempting to upload code to the new 3.1s. I threw one out but I could mail you this other one? It's the same thing with the chip getting really hot to touch when I attach a USB. My solder job seems fine...

Erin
 
It's the same thing with the chip getting really hot to touch when I attach a USB. My solder job seems fine...

That doesn't sounds the same at all. I have those 2 dead boards here on my desk. Neither gets even warm, certainly not hot to touch.

Any chance you could measure the 3.3V and 5V power on your board?
 
Hi,
I am the ex-owner of the two dead Teensys 3.1 - they did not get hot while alive nor a after stopping work ...
jrr's (Post 14) of a shortened reset button sounds plausible - but another strange manufacturing defect could also be the reason for the failure.

Switched to my standard environment - MacBook Air, OS X 10.9.1, standard breadboard. The only thing I replaces was the USB-cable and I upgraded to the latest IDE.
My new Teenys 3.1 and 3.0 are still alive and working as expected.

Best regards,
Wolfgang
 
Hi Paul,
the replacement for the two dead Teensys arrived today :)
Thanks a lot - this is outstanding customer service !!!

Best regards,
Wolfgang
 
Hi Paul -

I measured the 3.3v on the board,....nobody home there. I mean it might just be a freak static electrical accident, I guess it was really really cold in Montreal when this happened...
 
If you're getting zero volts on the 3.3V line, look for a short somewhere between 3.3V and GND.

Reading 0.0V, or very close to zero, is actually a sign the short might be a piece of metal. Usually when chips fail as a short, they aren't as good a conductor as real metal, so it's common to see a little more voltage if the chip is causing the short.
 
Status
Not open for further replies.
Back
Top