Teensy 4.1 flashing, very hot and non responsive (cannot be detected by computer)

G

General_Hex

Active member
Hi,

I was using my Teensy 4.1 with my robot project today when all of a sudden in the middle of running the robot stopped and the teensy started flashing. I thought it strange but as the code was no longer running I turned off the power supply and tried to connected to my computer when I noticed it is no longer coming up in the ArduinoIDE which it was just fine before this.

What to note:
  • The red LED is flashing red 9 times before stopping and starting again 9 times
  • i've tried the reset with 15 seconds to no avail
  • the teensy is heating up significantly
  • no wires or anything were changed or moved prior to this
  • the robot is made of 3D printed material and nothing was near it when this occurred so static shock is unlikely
  • this happened in the middle of the robot's movement
  • the robot has been tested previously with no such problems
  • was running at 600Mhz CPU speed
  • no visible burns or deformities on the teensy

I have previously burned a teensy 4.1 however with that one the red LED no longer turned on, it was very hot to the touch, and the reason of the burning was clear (due to me accidentally short circuiting one of the pins with 5V) so i think there is hope that this one isn't burned. So it would be a great help if you could tell me:
  1. Do you believe my teensy is burned?
  2. if yes what do you believe the cause to be?
  3. if no then how can I fix this issue?
  4. is there any further information I can provide you which may help?

Thank you in advance because I have an upcoming competition this week and this just happened. I have a spare teensy however now I am scared to use the spare because I don't know what caused it and i'm scared it can happen again because i've used this code and robot a lot before and such a thing has never happened.
 
It would be helpful to know/see what you have hooked to your Teensy & how (include the schematic at least, but including pictures would be even better).

Also, the explanation for all of the troubleshooting blink codes can be found at the bottom of <this> page.

Hope that helps . . .

Mark J Culross
KD5RXT
 
I sadly do not have the robot with me right now and we do not have a schematic as we are currently just using breadboards as we planned to finish designing and creating our PCBs in the future. However I can explain what we do have connected to the teensy:

the main power source for the entire robot is a 12V battery which directly powers 4 12V DC motors. Then a wire from the 12V line goes to a voltage step down which decreases the voltage to around 4.7V which is then used to power the Teensy.


The teensy's 3V pin is connected to a power line which is used to power:
  • IMU (Gyro Sensor)
  • 3 ultrasonic sensors
  • IR Sensor (its a Building Blocks robotics IR sensor)

Connected to the teensy's other pins are:
  • PWM wire for each of the 4 motors
  • Direction wire for each of the 4 motors
  • I2C connection for IR sensor
  • I2C connection for IMU

All ground wires of all components including Teensy are connected to the same ground line.


But again I changed nothing during the long time I’ve been just testing the code so if it was an issue with the wiring or something it would have been noticed or effected sooner. If it would help I can send the link of the exact components and the exact pins they are connected to. According to the link you sent it is an ARM JTAG DAP Init Error (9 flashes) but it does not state how I can fix it and I don’t know how to fix that or if it can be fixed so if you could explain the steps to me that would be great. I apologise if I am unable to understand things as well because I am just a high school student who just started working with all these this year and is still new to most of it.
 
Also I just realised that during the few minutes I was panicking about what happened to the teensy I tried doing the 15 second reset then the LED turned stable red but I kept trying to connect and nothing would work so I unplugged it however after more research i just noticed that I should not have unplugged the power while it was resetting so could that be the cause of the ARM JTAG DAP Init Error? if yes how do i fix it? and if that was the cause then that still does not explain why it suddenly stopped working before I made that mistake (and yes it was flashing the same even before I made that mistake or tried a 15 second reset).
 
Just a couple of general comments (point being: any of these could possibly have contributed to the failure of your T4.1):
- Teensy 4.x is not tolerant of anything over 3.3VDC on any pins (except the 5VDC power input, of course)
- depending upon the voltage step down that you used to power your T4.1, some of those types of "regulators" can be very poorly behaved (power surges at startup, poor regulation without a load, etc.)
- electronics subjected to a voltage that exceeds the specification (e.g. an input pin that sees anything over 3.3VDC for any reason and/or any duration, no matter how short/quick) can fail, but this failure may or may not occur immediately (so, running successfully for a long time is no assurance that there isn't still something wrong that likely caused the failure)
- sounds like you may be using some kind of a motor controller
- is it powered by 12VDC, 5VDC, or 3.3VDC ??
- are there any other connections between the controller and your T4.1 besides the PWM signal & the direction signal ??
- is there any way for more than 3.3VDC to unintentionally sneak back thru any of these connections ??
- are the motors diode protected to reduce line bounce as they turn on & off
- the important thing is to step back from your design and/or connectivity & try to look for any possible way for any of the connectivity to accidentally and/or unintentionally subject your T4.1 to voltages in excess of 3.3VDC (the most likely source of your failure)

Hope that helps . . .

Mark J Culross
KD5RXT
 
General_Hex said:
Also I just realised that during the few minutes I was panicking about what happened to the teensy I tried doing the 15 second reset then the LED turned stable red but I kept trying to connect and nothing would work so I unplugged it however after more research i just noticed that I should not have unplugged the power while it was resetting so could that be the cause of the ARM JTAG DAP Init Error? if yes how do i fix it? and if that was the cause then that still does not explain why it suddenly stopped working before I made that mistake (and yes it was flashing the same even before I made that mistake or tried a 15 second reset).
Click to expand...

Try the 15-sec restore as described <here> again.
 
kd5rxt-mark said:
sounds like you may be using some kind of a motor controller
- is it powered by 12VDC, 5VDC, or 3.3VDC ??
- are there any other connections between the controller and your T4.1 besides the PWM signal & the direction signal ??
Click to expand...
No, the motors all have their own built in controllers. the Motors themselves are powered directly by the 12V battery and the only way they are connected to the teensy in any way is the PWM and direction wires they each have (and of course all components share a ground line).

kd5rxt-mark said:
- is there any way for more than 3.3VDC to unintentionally sneak back thru any of these connections ??
Click to expand...
No there is no way because all of the pins except one are connected to sensors and the one that isn't is just connected to a switch which is between that and the 3V line and is used in the code.
kd5rxt-mark said:
- are the motors diode protected to reduce line bounce as they turn on & off
Click to expand...
No the motors are not diode protected as I was unaware of any line bounce that could occur however again the power of the motors are fully seperate from the teensy so a spike in them still should not effect the teensy right?
 
kd5rxt-mark said:
Try the 15-sec restore as described <here> again.
Click to expand...
We are trying to do the 15 second reset again, after 15 seconds a steady red LED is turned on. However after waiting for a while the LED goes back to flashing 9 times and does not turn off nor does the orange LED flash like it says it should in the post you sent me. What could this indicate?
 
Do you have access to an oscilloscope ?? If so, monitor the output of the voltage step down when your robot is turned on to see if the output voltage ever exceeds 5VDC. Other than that (based upon your earlier answers), anything else would just be a guess. You are wise to be afraid to also damage your spare T4.1. If your first one has failed, until & unless you are able to definitively pin down the exact cause (or at least, a strongly suspected cause), there is some likelihood that another T4.1 would also show a failure in the same environment.

Mark J Culross
KD5RXT
 
kd5rxt-mark said:
Do you have access to an oscilloscope ?? If so, monitor the output of the voltage step down when your robot is turned on to see if the output voltage ever exceeds 5VDC. Other than that (based upon your earlier answers), anything else would just be a guess. You are wise to be afraid to also damage your spare T4.1. If your first one has failed, until & unless you are able to definitively pin down the exact cause (or at least, a strongly suspected cause), there is some likelihood that another T4.1 would also show a failure in the same environment.

Mark J Culross
KD5RXT
Click to expand...
Again as stated previously I do not currently have the robot with me so I would be unable to test that and I do have a multimeter I could use if that is the same as an oscilloscope. I have also previously ensured that the voltage step down is stepped down to exactly 4.7V before using it as a power source for the teensy which I hoped would also create a small safety for over voltages. Again it is strange because prior to this the teensy and robot were working fine but then suddenly it stopped.
 
There is an alternate reset process described elsewhere on this forum that you could try (it should not make any difference, but still worth a try). With your T4.1 unplugged from your PC, but with the USB cable plugged into the T4.1, press the PROGRAM button (on the unpowered T4.1). While holding down the PROGRAM button, plug the USB cable into your PC. Keep holding down the PROGRAM button until the 15-sec restore begins (as described in the link provided earlier). Complete the 15-sec restore as described.

Mark J Culross
KD5RXT
 
kd5rxt-mark said:
There is an alternate reset process described elsewhere on this forum that you could try (it should not make any difference, but still worth a try). With your T4.1 unplugged from your PC, but with the USB cable plugged into the T4.1, press the PROGRAM button (on the unpowered T4.1). While holding down the PROGRAM button, plug the USB cable into your PC. Keep holding down the PROGRAM button until the 15-sec restore begins (as described in the link provided earlier). Complete the 15-sec restore as described.

Mark J Culross
KD5RXT
Click to expand...
Tried that and again the LED goes stable red for a while but then it goes back to flashing after about 40 seconds.
 
General_Hex said:
Again as stated previously I do not currently have the robot with me so I would be unable to test that and I do have a multimeter I could use if that is the same as an oscilloscope. I have also previously ensured that the voltage step down is stepped down to exactly 4.7V before using it as a power source for the teensy which I hoped would also create a small safety for over voltages. Again it is strange because prior to this the teensy and robot were working fine but then suddenly it stopped.
Click to expand...

I understand (robot is not with you). My suggestion was for when you (or someone else) has hands-on. As for the multimeter, it's a great tool for setting the static output voltage level (as you have obviously done), but for capturing what happens at power-up, a multimeter is not capable of responding nearly quickly enough. You need something (an oscilloscope fits the need) to capture what happens in real time as the power is applied so you can see exactly what the power is doing.

I'll re-emphasize that electronics subjected to any "stress", no matter how small and/or quick, may fail slowly over time. The fact that your robot has worked for some time may be (temporarily) reassuring, but the fact that it has now failed indicates that the T4.1 has very likely suffered some kind of damage. That's really what you need to figure out and/or solve, otherwise your next T4.1 is almost certainly living on borrowed time.

Troubleshooting is always challenging, especially with the added pressure of impending deadlines. In general, it requires a logical and methodical approach. In the process of troubleshooting, you're basically postulating and speculating on "what could have gone wrong", then step-by-step, eliminating those possibilities. No stone should be left unturned...no possibiliites should be dismissed and/or ignored. The method of elimination cannot be simply "that can't be", but rather must involve taking measurements, and/or putting mitigations in place, where you have either determined (with measurements) "that doesn't happen" or you have assured certainty (with implementation, but taking measurements to back it up is even better) "that can't happen." If you knew the cause, you would probably already have remedied it. I used to sarcastically joke at work "it's really simple, once you've determined the actual cause !!"

I know your current challenge is not "simple", but with lots of persistence, and maybe just a sprinkle of luck, you can & will figure it out. I admire your courage for diving into the Teensy world, and you should be proud of the fact that you have created your robot. And, rest assured, that whatever the cause may turn out to be, that will be one more point of knowledge that you'll be able to add to your accumulating font of knowledge as you tackle bigger and more complicated projects. In the meanitme, we'll do our best to try to help you to get over your current bump in the road.

Mark J Culross
KD5RXT
 
kd5rxt-mark said:
I understand (robot is not with you). My suggestion was for when you (or someone else) has hands-on. As for the multimeter, it's a great tool for setting the static output voltage level (as you have obviously done), but for capturing what happens at power-up, a multimeter is not capable of responding nearly quickly enough. You need something (an oscilloscope fits the need) to capture what happens in real time as the power is applied so you can see exactly what the power is doing.

I'll re-emphasize that electronics subjected to any "stress", no matter how small and/or quick, may fail slowly over time. The fact that your robot has worked for some time may be (temporarily) reassuring, but the fact that it has now failed indicates that the T4.1 has very likely suffered some kind of damage. That's really what you need to figure out and/or solve, otherwise your next T4.1 is almost certainly living on borrowed time.

Troubleshooting is always challenging, especially with the added pressure of impending deadlines. In general, it requires a logical and methodical approach. In the process of troubleshooting, you're basically postulating and speculating on "what could have gone wrong", then step-by-step, eliminating those possibilities. No stone should be left unturned...no possibiliites should be dismissed and/or ignored. The method of elimination cannot be simply "that can't be", but rather must involve taking measurements, and/or putting mitigations in place, where you have either determined (with measurements) "that doesn't happen" or you have assured certainty (with implementation, but taking measurements to back it up is even better) "that can't happen." If you knew the cause, you would probably already have remedied it. I used to sarcastically joke at work "it's really simple, once you've determined the actual cause !!"

I know your current challenge is not "simple", but with lots of persistence, and maybe just a sprinkle of luck, you can & will figure it out. I admire your courage for diving into the Teensy world, and you should be proud of the fact that you have created your robot. And, rest assured, that whatever the cause may turn out to be, that will be one more point of knowledge that you'll be able to add to your accumulating font of knowledge as you tackle bigger and more complicated projects. In the meanitme, we'll do our best to try to help you to get over your current bump in the road.

Mark J Culross
KD5RXT
Click to expand...
Thank you for understanding and trying to assist me. We do not own an oscilloscope and I doubt we would be able to get one in time if we tried. However despite not having the robot we do have the troublesome teensy so we can do any tests/fixes required on the teensy itself.

On that note, do you know of what problems could cause an ARM JTAG DAP Init Error (9 flashes) as that is the error that the teensy is clearly trying to convey to us but I do not fully understand what the problem is or how I could fix it. If you could let me know of common reasons for such an error or explain the error to me maybe we can narrow down what the reason could possibly be.
 
Yes I know and we did but again after releasing it, it stayed stable for 40 seconds and then went back to flashing 9 times and according to links above it should turn off the red LED and start blinking it's orange LED which it did not do.
 
Building on this: (Yes this has been copied and pasted from my other thread because I was told to continue the discussion here)

Hi,

Within the past two days I have burned two teensy 4.1s with a third one being burned months ago. The one burned ages ago I know why they burned (because a pin received more than 3V) however the two that were burned within the last two days I am still unsure as to the reason.

I am currently working on a robot project where the teensy is in this circuit on a bread board (sorry I do not have any photos as I do not have access to the robot right now and I do not have a schematic):

the main power source for the entire robot is a 12V battery which directly powers 4 12V DC motors. Then a wire from the 12V line goes to a voltage step down which decreases the voltage to around 4.7V which is then used to power the Teensy.


The teensy's 3V pin is connected to a power line which is used to power:
  • IMU (Gyro Sensor)
  • 3 ultrasonic sensors
  • IR Sensor (its a Building Blocks robotics IR sensor)

Connected to the teensy's other pins are:
  • PWM wire for each of the 4 motors
  • Direction wire for each of the 4 motors
  • I2C connection for IR sensor
  • I2C connection for IMU
  • Wire connected to switch connected to 3V line used for code (stopping and starting robot without turning off robot)

All ground wires of all components including Teensy are connected to the same ground line.
Motors have built in encoders.


I am tired of these expensive teensy's burning especially for reasons we still do not know, so I want to implement a new circuit to fully protect the teensy. The current plan is this:
  1. Place one Diode (1A rated) on all motors' ground and power to protect teensy from reverse pulse
  2. Place Diode (1A rated) on the VIN pin of the teensy to protect from reverse polarisation
  3. Place 150mA fast burn Fuse on the VIN of the teensy to protect from high current

My questions are these:
  1. Would all these methods work to protect the teensy?
  2. Is this overkill? if yes then how much would I need to do to ensure the teensy doesn't burn?
  3. is there anything else I can do to further protect the teensy?

Notes:
  • I am a high school student new to electronics and teensys so please try to explain things in simple terms as I might not understand or know
  • I can send the exact links of the components or specs of the components if that would help
  • We are on a tight schedule as we have a State competition this weekend and if we cannot get something quickly or in store we are unlikely to be able to get it
  • if there is any further information that would help please let me know
  • the voltage step down already has a diode to protect it from reverse current (2A diode)
 
Driving DC motors or solenoids requires careful attention to clamping diodes and/or snubber circuits to deal with "back EMF" which can create a high voltage spike when the current to the motor switches off. If only diodes are used, the speed of the diode matters quite a lot (eg, slow rectifier diodes like 1N4007 offer less protection).

General_Hex said:
Connected to the teensy's other pins are:
  • PWM wire for each of the 4 motors
  • Direction wire for each of the 4 motors
Click to expand...

Can you give us a clear diagram and photos, so we can see how you've connected the motors. Detailed info for the other connections would also be good... the more & better we can see, the better odds are we might be able to spot problems.
 
You will see in the descriptions of the blinking error codes that 9 blinks is defined as follows:

Code: 
9 Blinks = ARM JTAG DAP Init Error
    The ARM JTAG DAP was detected (4 blinks) but could not be initialized.
    This error is rather unlikely by hardware! However, a software crash resulting in hard fault or CPU lockup (typically very early in startup) can result in this error.

So, based upon this description, you should probably investigate the following:

- is your software crashing ?? Follow the instructions given <here> for including the crash report detection in your setup() function. If/when a failure occurs, make sure that the T4.1 is connected to the Arduino IDE Serial Monitor for the next power-up to see if a crash report is generated. If software is somehow crashing, then the only fix is to determine the true cause and to correct that.

- has an intermittent short (solder balls, metal shavings, crossed wires, etc.) somehow developed in your hardware ?? Only close careful inspection under sufficient magnification (magnifying glass, microscope, etc.) can completely rule this out.

- is the power being supplied to the T4.1 actually well behaved (NEVER exceeding 5VDC, especially at startup). As recommended earlier, monitoring the power output at startup with an o-scope is the best way to make sure that this is not the problem. Even if you don't have an o-scope, one of the other teams at the upcoming competition may have one & be willing to let you use it for a quick check. You could also temporarily disconnect your T4.1 from the power convertor & power it instead from a USB booster battery (stable 5VDC) to see if that changes the stability/survivability.

As for how to actually fix the problem, that really depends on determining exactly what the problem is.

Mark J Culross
KD5RXT
 
PaulStoffregen said:
Driving DC motors or solenoids requires careful attention to clamping diodes and/or snubber circuits to deal with "back EMF" which can create a high voltage spike when the current to the motor switches off. If only diodes are used, the speed of the diode matters quite a lot (eg, slow rectifier diodes like 1N4007 offer less protection).



Can you give us a clear diagram and photos, so we can see how you've connected the motors. Detailed info for the other connections would also be good... the more & better we can see, the better odds are we might be able to spot problems.
Click to expand...
I'm a little confused about what you mean by the "speed" of the diode. Currently we have these diodes and we have a lot of these so would these work: 1N4004 400V 1A DO41

As for diagrams and photos I am currently unable to now but tomorrow morning I will send some photos of the circuit but for now I have tried to explain every wire and component on our circuit here:
General_Hex said:
the main power source for the entire robot is a 12V battery which directly powers 4 12V DC motors. Then a wire from the 12V line goes to a voltage step down which decreases the voltage to around 4.7V which is then used to power the Teensy.


The teensy's 3V pin is connected to a power line which is used to power:
  • IMU (Gyro Sensor)
  • 3 ultrasonic sensors
  • IR Sensor (its a Building Blocks robotics IR sensor)

Connected to the teensy's other pins are:
  • PWM wire for each of the 4 motors
  • Direction wire for each of the 4 motors
  • I2C connection for IR sensor
  • I2C connection for IMU
  • Wire connected to switch connected to 3V line used for code (stopping and starting robot without turning off robot)
Click to expand...

Building on this do you believe the 3 steps I have outlined here are good (or good enough) precautions to protect a teensy even if something were to go wrong:
General_Hex said:
  1. Place one Diode (1A rated) on all motors' ground and power to protect teensy from reverse pulse
  2. Place Diode (1A rated) on the VIN pin of the teensy to protect from reverse polarisation
  3. Place 150mA fast burn Fuse on the VIN of the teensy to protect from high current
Click to expand...
 
kd5rxt-mark said:
is your software crashing ?? Follow the instructions given <here> for including the crash report detection in your setup() function. If/when a failure occurs, make sure that the T4.1 is connected to the Arduino IDE Serial Monitor for the next power-up to see if a crash report is generated. If software is somehow crashing, then the only fix is to determine the true cause and to correct that.
Click to expand...
If by software you mean the code we uploaded to the teensy then no the code is not the issue crashing. Also the issue is I cannot run that crash report code on the teensy because the teensy is no longer detected by my computer in ArduinoIDE so I have no way of uploading that code.

kd5rxt-mark said:
- has an intermittent short (solder balls, metal shavings, crossed wires, etc.) somehow developed in your hardware ?? Only close careful inspection under sufficient magnification (magnifying glass, microscope, etc.) can completely rule this out.
Click to expand...
This is possible but can't be confirmed since I do not have the teensy currently with me but if this is the case is there any method to fix the issue because it seems the teensy still works and isn't fully burned since it flashes


kd5rxt-mark said:
- is the power being supplied to the T4.1 actually well behaved (NEVER exceeding 5VDC, especially at startup). As recommended earlier, monitoring the power output at startup with an o-scope is the best way to make sure that this is not the problem. Even if you don't have an o-scope, one of the other teams at the upcoming competition may have one & be willing to let you use it for a quick check. You could also temporarily disconnect your T4.1 from the power convertor & power it instead from a USB booster battery (stable 5VDC) to see if that changes the stability/survivability.
Click to expand...
While I cannot say for certain that the power source is "behaving" I can say that we have been using the same power source for months and we have never ran into such a problem so if the issue was indeed the power source I believe it would have started effecting things much sooner however again I cannot be sure as I do not have an o-scope.
 
General_Hex said:
I'm a little confused about what you mean by the "speed" of the diode.
Click to expand...

Diodes "switch on" when the forward voltage is over a certain threshold, typically around 0.6V, but like anything that has to deal with real world physics they can't change state instantly. It takes a while for a protection diode to start to conduct and so protect the rest of the system, during this time the voltage can get significantly higher than the steady state clamping level you are expecting. How much higher depends on system capacitance, inductance, circuit layout and lots of other factors. Parts specifically designed for circuit protection will normally switch on faster than general purpose diodes and so provide better protection.

Check your physical layout, the motors and their controllers may have built in protection but if you have digital IO lines running very close to the motors you could get some nasty voltage spikes induced onto wires that have nothing to do with the motors.

One other thing you could look at for protection is adding series resistors to the IO pins. 200-300 ohms in series isn't normally going to have a meaningful impact on a digital signal unless you are toggling it very quickly. It won't protect you from everything but it will limit the currents to the point the chip has a fighting chance of surviving if you drive a signal into an output pin or accidentally put 5 V on to an input.
 
These words aren't giving me a clear picture of how everything is really connected. Maybe others here get it, but I don't. I really need to see photos and ideally a clear and accurate diagram.

When it comes to solving mysterious electronics problems remotely over the internet, please understand there is a world of difference between telling us what you've done (especially with so many words assuring things are correct) versus showing us what was actually done.

Please, take some photos and try to give a clear diagram.
 
PaulStoffregen said:
These words aren't giving me a clear picture of how everything is really connected. Maybe others here get it, but I don't. I really need to see photos and ideally a clear and accurate diagram.

When it comes to solving mysterious electronics problems remotely over the internet, please understand there is a world of difference between telling us what you've done (especially with so many words assuring things are correct) versus showing us what was actually done.

Please, take some photos and try to give a clear diagram.
Click to expand...
I understand and I will be sure to send you full photos of our circuit layout tomorrow. However it is highly "messy" with jumper wires running everywhere so hopefully the text I put above will help decrypt what is going on with the circuit when I send the photos tomorrow
 
You must log in or register to reply here.
Back
Top