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