Note that my test program will show a problem on a UART with or without a FIFO. Your program shows that with a FIFO, problems can occur even when sending/receiving relatively small "packets".
Nice job! This is indeed much simpler than my example code and shows the same issue seen from another function (Serial2.available()).
I hope that @PaulStoffregen can take a look at this some day, as the fix seem to be minimal:
uint8_t variables...
Yes, that's correct. addMemoryForRead() with more than 192 bytes will cause the issue, as far as I understand. Remember that this is only for Serial1 and Serial 2 (HW FIFO) UARTs.
Okay, I do see the assignment statements in cores\TEENSY3 that seem problematic. When you say burst, you mean use of write with a length parameter, like below? If so, it's not hard to imagine prior tests using single-byte writes. I wouldn't call...
Thanks for pushing on the terminology — actually, I noticed that the sender's API is irrelevant. A multi-byte write() and a tight loop of single-byte write()s produce identical back-to-back bytes on the wire. I should not have said "burst"...
Yes, it's confirmed by test — the repro sketch above (attached main.cpp) shows it on a bare Teensy 3.5 with a single jumper. One quick and dirty fix to the issue is to add -DSERIAL2_RX_BUFFER_SIZE=512 to the build_flags, as it forces...
Minimal repro (Teensy 3.5, jumper pin 8 → pin 9) -> Please check attached main.cpp file
Summary
In cores/teensy3/serial1.c … serial6.c, the ring buffer index variables are sized at compile time based on the static buffer size:
#if...