What can sabotage Serial communications on a Due?

I'm still plodding away at testing my Nextion UI with a Due. Everything was working great: I could receive scads of data from the Nextion device over Serial1, could send commands to it, everything was fine, bidirectional comms all good. Now very suddenly from one iteration to the next, "everything is broken" and as usual I am wondering what the heck just happened :-)

Serial1 (nextion interface) is set to 9600 baud. Serial (programming port) is set to 9600 baud. I'm logging messages to the Monitor as I debug my Due code. Mostly, communications are working... I'm receiving touchscreen events and parsing them correctly, right byte count, right termination sequence, all good.

Until I ask the Nextion to send me a whole series of messages in a row. Then something breaks so badly that I can't even do a Serial.println any more.

Log output:

Trying to parse msg: 
Error parsing line of component dump output from Nextion

Hop

Code for that last line:

if (!nexti_dump) {
           Serial.println(F("Got non-standard start byte from nextion!"));
        } else {
           Serial.println(F("Hoping this is a line of dump output"));
        }

So, clearly something got broken very badly, because this "dump data" interaction was working perfectly earlier today. My question is, what kind of failure can make a Serial.println die in mid output? I wouldn't have thought that was even possible :-)

After this last partial output, I never get any more output on that instance of Serial Monitor. But if I close it and re-open it, I find my sketch is still running, and I can get sensible monitor output... until I trigger the data dump feature again. Here's a snip from the Serial Monitor after it's been reopened (recovering from the original glitch), after the same data request:

0x73 BEGIN dump data from nextion!
Trying to parse msg: 
Error parsing line of component dump output from Nextion

Hoping this is a line of dump output
End of nexti msg found
Trying to parse msg: 3,1,433,39,40,40,109,Hots,m0
3,1,433,39,40,40,109,Hots,m0
Hoping this is a line of dump output
End of nexti msg found
Trying to parse msg: 3,2,33,60,50,50,109,Hots,m1
3,2,33,60,50,50,109,Hots,m1
Hoping this is a line of dump output
Trying to parse msg: 8 20 41 27 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 0 0 0 0 0 
8 20 41 27 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 0 0 0 0 0 
Hoping this is a line of dump output
Trying to parse msg: 8 20 41 27 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 0 0 0 0 0 0 
8 20 41 27 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 0 0 0 0 0 0 
Hoping this is a line of dump output
Trying to parse msg: 8 20 41 27 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 0 0 0 0 0 0 0 
8 20 41 27 8 0 a1 29 8 0 a1 29 8 0 a1 29 8 0 a1

Observe that the first couple of messages received from the Nextion are quite reasonable. But after that, for whatever reason, the string I'm trying to parse becomes a bizarre repeating pattern of byte values. Then it hangs (the visible output). I close the monitor and restart it, trigger the dump again and get a different result: back to "Hop" (incomplete Serial.println). So it's not quite repeatable.

I'm reasonably sure that the Nextion is sending the right data and that it's the Due that's losing its mind...

I do realise that the tiny code snippet above offers zero insight into what my sketch is actually doing :-) I'm just wondering if it should mean something to me when a Serial.println sends only partial text to the monitor -- is that a specific symptom that should point me in a certain direction?

I got in the habit of using the F macro on Leonardos and Unos, to save memory. Is it dangerous in some way I never noticed before? Probably don't need it with the Due's generous memory.

Time to give up and get some sleep. What a setback! I was making big exciting progress up until now :-) tomorrow I'll strip the code back down to basics and see what happens.

Oh yeah, I do use String quite a bit, and have read here and there that some C purists do not consider it clean or safe. What I'm seeing here does kind of look like memory stomping, and it happened very suddenly after making "minor" changes to code, so...?

Tazling: So, clearly something got broken very badly,

Do you still have the working code and can you compare it to the non-working code?

Please post the complete program.

...R Serial Input Basics - simple reliable ways to receive data.

Alas, I have not been rcs-ing this code as I go. But tomorrow when more awake I will strip it back to basics and try again.

There is no explicit use of interrupts in my sketch, just Serial reads and writes.

Does the incomplete Serial.println suggest anything to the more experienced Arduinist? That’s all I really would like to know, is whether I should perceive it as a big obvious smoking gun that points at X.

Sounds like a buffer overrun. These can trash unpredictable “other data” depending on positioning in the binary, so it’s possible for new code to stop working even if the bug is quite old.

I was afraid of that. And no SEGV to alert me. I hate buffer overruns w/no crashdump to pick through.

OK, we'll do it the hard way. I'll strip it back to minimalist and proceed step by step. Are the warnings about String to be taken seriously? I use String a lot because I find dealing with strings as char pointers or arrays is so clunky (I came from the world of more weakly typed languages with stronger string processing features).