Updated to IDE 1.8.19, Teensy 3.2. Now CRASHES on Serial.print

Cyclist

Member
I just updated to IDE 1.8.19 and Teensyduino 1.57. Previous IDE was 1.8.10.
I successfully compiled, loaded and ran an old, reliable program (no changes) on Teensy 3.2.
Program runs normally until a Serial.print is executed. Then it locks up.

Any thoughts or suggestions?
 
No idea. Works on programs I run.

Might help to know additional information, like see source code or at least a minimal program that makes it hang.
 
No idea. Works on programs I run.

Might help to know additional information, like see source code or at least a minimal program that makes it hang.

Thanks Kurt. I've solved the problem but it leaves behind a puzzle as to why my code ran, bug free, when compiled with 1.8.10. I've greatly simplified the culprit procedure below. Adding the final statement, InChar = 0, fixed the problem. A little mystery.
This procedure is executed periodically. It adds InChar to a string and testing for keyword commands. Failing to clear the InChar after each pass was very naughty. But why did I get away with it on 1.8.10? I no longer have an installed 1.8.10 to make further tests.

Code:
void RecSerial()          //  Receive Serial Data to modify certain variables
{
   while (Serial.available() > 0)
    {
        InChar = Serial.read();
        InString = InString + char(InChar);   // Concatinate multiple InChar's into string
    }

      if (InChar == 10)        // If it's a LF, process input string
      {
        InString = InString.substring(0, InString.length() -1);    // Strip the LF

         if (InString == "test")   // An example of many key word tests
           {
             delay(2000);
           }

        InString = "";          
        InChar = 0;       // Added to fix crash after updating to IDE 1.8.19           

      }
}
 
Last edited by a moderator:
Thanks Kurt. I've solved the problem but it leaves behind a puzzle as to why my code ran, bug free, when compiled with 1.8.10. I've greatly simplified the culprit procedure below. Adding the final statement, InChar = 0, fixed the problem. A little mystery.
This procedure is executed periodically. It adds InChar to a string and testing for keyword commands. Failing to clear the InChar after each pass was very naughty. But why did I get away with it on 1.8.10? I no longer have an installed 1.8.10 to make further tests.

...

Setting this seems essential: InChar = 0; // Added to fix crash after updating to IDE 1.8.19

When called without any Serial.available() if the prior exit was with:: if (InChar == 10)

It will enter that code again because InChar seems static based on the SNIPPET of code. On entry to RecSerial() this should always be set to 0 or some accepted value: InChar = 0;
> It could also start with: if ( !Serial.available() ) return;

And with NULL InString then length -1 isn't meaningful or valid. This was wrong and it just happened to not get 'caught' as it was running before.

The fact that there was an IDE change between 1.8.10 and 1.8.19 could just be a timing issue with device input or code execution from calling code calling more often, just ending by chance on the "== 10" or some speedup in TeensyDuino processing.
 
Setting this seems essential: InChar = 0; // Added to fix crash after updating to IDE 1.8.19

When called without any Serial.available() if the prior exit was with:: if (InChar == 10)

It will enter that code again because InChar seems static based on the SNIPPET of code. On entry to RecSerial() this should always be set to 0 or some accepted value: InChar = 0;
> It could also start with: if ( !Serial.available() ) return;

And with NULL InString then length -1 isn't meaningful or valid. This was wrong and it just happened to not get 'caught' as it was running before.

The fact that there was an IDE change between 1.8.10 and 1.8.19 could just be a timing issue with device input or code execution from calling code calling more often, just ending by chance on the "== 10" or some speedup in TeensyDuino processing.

Thanks, Defragster.
After some thought, I came to a similar conclusion. It looks like my code made frequent, unnecessary passes through this code and timing could well have made the difference. (There were many tests for key words that I did not list in this example code). I got away with this error on several gadgets that shared this same code. I've never bought a lottery ticket but maybe I should. And maybe analog designers shouldn't write code. :)
 
Back
Top