Teensy 3.6 looses programming

dundakitty

Well-known member
Under what circumstances would a Teensy 3.6 loose its programming?
Several times I've had a Teensy 3.6 appear to die but really it just needed re-programming. I have to hold down the reset button for 15 seconds and then the Teensy 3.6 comes back to life.
The teensy 3.6 is in an MP3 player application, as documented here: https://forum.pjrc.com/threads/55551-posted-RCA-118-quot-tombstone-quot-MP3-player
I play the "radio" for a half-hour almost every night then turn it off. After several months the teensy 3.6 appears dead and has to be reprogrammed. Power-cycling doesn't have any affect. When I attach the USB cable the computer doesn't see a teensy present. Only after holding down the reset button does the computer see the Teensy and it can be reprogrammed.
After reprogramming the teensy 3.6 works fine for several months, then one day it will appear dead.

Does anyone have an idea where to look?
 
I would say it's unlikely the T3.6 is "losing" its program, as opposed to being corrupted by something your software is doing. I checked the original thread and don't see any links to code. Are you using EEPROM or saving any data in flash? Those come to mind as things that could eventually corrupt your program flash. As a first step, it might be worthwhile to see if you can update your project from TD 1.54 to the latest 1.59b2. There have been two compiler updates, big changes to SD, etc. Maybe the problem will resolve by doing that, and if not, at least you're looking for something with the latest tools, which will make it easier for others to try to help.
 
The code is only reading from EEPROM, it's not saving any data there. I do use Serial to read commands and update the EEPROM, but I'd have to have the USB connected for that and it is only rarely connected. Even then the code only writes to EEPROM if the data from Serial is properly formatted. I've compiling with TD 1.58, I'm waiting for TD 1.59 to come out of beta.
My current thought is a power-supply transient during power-up. I'm using a 12v 3-amp power supply for the audio board, then a 5v buck switching regulator for the teensy. It's possible I have too large of a filter capacitor after the switching regulator. I'll have to tear the "radio" down to get to the board to check.
 
I just had a 2nd T3.6 lose it's programming. After a power "flicker" the T3.6 appeared dead. The PC didn't even see the T3.6 over the USB connection. After holding the reset button down for 15 seconds the PC could see the T3.6 and I could reprogram it.
The power supply for this T3.6 is a simple 5v wall-brick. The 5v/USB trace is cut on the T3.6 and I only connect the PC when needed.
 
I just had a 2nd T3.6 lose it's programming. After a power "flicker" the T3.6 appeared dead. The PC didn't even see the T3.6 over the USB connection. After holding the reset button down for 15 seconds the PC could see the T3.6 and I could reprogram it.
The power supply for this T3.6 is a simple 5v wall-brick. The 5v/USB trace is cut on the T3.6 and I only connect the PC when needed.

This exact thing happens to me and the Teensy 4 when I compiled my code and it produced code that (I think) was too big for the teensy. When not uploading and just building, the compiler says space free for local variables is a negative value.

If I tried to upload that it compiles just fine, works for a few seconds and then crashes and loses connection. Unplugging the USB and plugging back in does nothing, you have to press the button and then recompile with code that works.

My guess is something goes out of bounds in memory somewhere.
 
This exact thing happens to me and the Teensy 4 when I compiled my code and it produced code that (I think) was too big for the teensy. When not uploading and just building, the compiler says space free for local variables is a negative value.

If I tried to upload that it compiles just fine, works for a few seconds and then crashes and loses connection. Unplugging the USB and plugging back in does nothing, you have to press the button and then recompile with code that works.

My guess is something goes out of bounds in memory somewhere.

When 'free for local' is <=0 this code github.com/PaulStoffregen/teensy_size/blob/main/teensy_size.c#L99

Should cause a build error to be displayed. At this point the build is complete and the HEX remains and could be uploaded - but would not function, and the build should break stopping the upload attempt? Though Teensy.exe loader may have the path and could upload?

But this would be different than claiming valid code was there once for some time and then seemingly goes away.

Cases where 'working' code goes missing has been reported but not observed AFAIK. If the Teensy.exe is active and has a path to a HEX file (and the ELF file to confirm the target that would stop pushing code for the wrong MCU) it can be triggered to erase and reprogram a connected device. Unless the code overtly writes to the program flash area the code on a healthy Teensy should persist indefinitely (i.e. some years). If the code relies on some EEPROM or other elements to run 'properly' then those program choices would generally be suspect for failure to run.
 
Should cause a build error to be displayed.

Indeed this is supposed to cause an error and not allow upload.

Maybe some non-Arduino software like PlatformIO is in play here?

Or perhaps we have a previously unknown bug where known bad code is being allowed?
 
Indeed this is supposed to cause an error and not allow upload.

Maybe some non-Arduino software like PlatformIO is in play here?

Or perhaps we have a previously unknown bug where known bad code is being allowed?

This was noted:
Code:
When [U]not uploading and just building[/U], the compiler says space free for local variables is a [B][U]negative value[/U][/B].

If it shows NEG that should trigger ERROR and stop, but the note says build not upload. So Teensy.exe may have HEX Path from that or prior build? A button press would then proceed?

So, some user intervention occurred to move to upload reported bad HEX? An alternate IDE might mishandle the build error - but note says it wasn't expected to upload. But any prior working HEX was replaced.

Without a way to repro that seems to be behind the 'T_3.6 loss of programming' as well - unless there is a code path to unexpectedly halt execution (p#6) - or flash overwrite?
 
If this is PlatformIO, maybe an issue should be opened? They really should be checking the return status from teensy_size and consider the build a failure if it returns any error.
 
Back
Top