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:
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.
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
}
}
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.