Teensyduino Bug(?): "Bricking" of T4 on program upload

Status
Not open for further replies.

DerekR

Well-known member
For the past three days I've been trying to track down a bug that "bricks" the T4 on program upload! I now believe it's a genuine problem in the Teensy code.

I was preparing some Audio Library compatible objects for upload to GitHub. These had run on T3.2 and T3.6 for 3+ years without a problem. I thought I would give them a quick try on the T4 (with Audio Card) before submitting to GitHub - BIG MISTAKE - the T4 was immediately bricked on upload. I, of course, thought it must be my code. I had a helluva time recovering from the bricked state. The problem was that COM20 (the t4's comm port) was being destroyed, and after holding the PRGM button for 15 secs it would try to restart and reload the corrupt program which bricked it again.

In the end, I tried compiling "blink", and then doing the unbricking procedure, so that a valid program would be uploaded. That worked and COM20 was restored and the T4 was functional until the corrupt code was uploaded again. I spent hours looking at my code, and tried it again on the T3.2 and T3.6 (with Audio Card) with no problems.

So, I decided to look at the T4 code. The simple demos blink, fade, etc all worked without problem. So I moved to trying the Audio examples and found that I could in fact cause the bricking in

File -> Examples -> Audio -> Hardware Testing -> PassThrouhStereo

I chose this example because of it has a similar structure to my code. It worked - so I started looking at the differences.

The breakthrough came when I copied the loop() from PassThroughStereo into my code and then voila all of a sudden my code loaded and worked!!! No more bricking or loss of COM20. But an empty loop() in my code didn't work - so it appeared that it was not my code that was causing the problem.

I went back to looking at PassThroughStereo again. Here's its loop function:
Code:
elapsedMillis volmsec=0;

void loop() {
  // every 50 ms, adjust the volume
  if (volmsec > 50) {
    float vol = analogRead(15);
    vol = vol / 1023.0;
    //audioShield.volume(vol); // <-- uncomment if you have the optional
    volmsec = 0;               //     volume pot on your audio shield
  }
}
It is very simple and basically does nothing other than adjust the volume. So I commented everything out. And the T4 was bricked on upload!!!. I put things back one at a time and found that

PassThroughStereo will brick the T4 unless in contains the analogRead() line in its loop().

So I went back to my code, and put an analogRead() in my loop() and it started to work as advertised for the very first time! I checked it with a function generator and 'scope and the audio in and out is as it should be.

To summarize:
1: There seems to be a serious bug somewhere in the T4 code that causes the Teensy COM port to be compromised/inoperable so that it is no longer possible to communicate with it until a reset and upload of a functioning sketch.
2: I didn't mention it above, but rebooting/powering down the PC does not restore it, neither does powering the Teensy off and on.
3: I can replicate the problem on pure Teensyduino code, and my own code also requires the same fix to allow it to function.

I have no idea what's going on, or why the analogRead() might fix it. Any suggestions? Could I have a bad T4?

I should mention that I'm using Arduino 1.8.10 and Teensyduino 1.48-beta1. PC is Windows 10.
 
Please try to repro with TD 1.48 beta 2 released today.

A change was put in - there was an issue introduced in beta 1 that might explain something like this.

startup.c
Move PIT timer init after CPU clock set
7 hours ago
 
@defragster: Fantastic - works like a charm. It was driving me crazy!
I find it hard to believe that I'm the only one who had this problem.
Thanks a bundle,
Derek
 
@defragster: Fantastic - works like a charm. It was driving me crazy!
I find it hard to believe that I'm the only one who had this problem.
Thanks a bundle,
Derek

Problem was only new to Beta 1 and it did hit a few people leading to finding it. But it was not a 100% problem depending on sketch.
 
Status
Not open for further replies.
Back
Top