Hi Robin, and thanks for the time you have taken to share your serial examples.
First I'll describe my problem in more detail:
The problem appears to be unique to Leonardo-based Arduinos, i.e. those in which the AVR itself is used to provide the USB interface, but which appear as a COM port on the PC, like any other Arduino.
Sometimes, and I haven't established what causes this to start or stop happening, the Arduino keeps receiving bytes from the PC into its serial buffer, but the number returned by Serial.available() never advances above 1. The example code I gave in my first post demonstrates this.
This means that an Arduino program that waits to receive, for example, 4 bytes before parsing them, will stop reading bytes from the serial buffer, because Serial.available() >= 4 will never be satisfied, even when the bytes have been received. This is what I mean when I say it (the buffer) is not performing its function.
When this happens, and the PC keeps sending data, (usually only 1 or 2 bytes more), this in turn causes the PC serial terminal to stop responding. I've witnessed this with both with the Arduino terminal, and Termite. The programs freeze completely until the Arduino is unplugged, or the Arduino reads the waiting bytes from the buffer. I don't think this could happen with the FT232-based Arduinos, because the sending PC receives no information about what's happening in the Arduino's buffer, but as I said above, perhaps some interaction of the USB routines running on the AVR and the PC's USB-serial driver is causing the lock-up. I don't know.
As for your code...
I see from your code that you create your own 32 byte buffer for received serial characters: receivedChars. You check for newly arrived characters using Serial.available() > 0 and read them straight into the second buffer.
I think your method would help with the problem I describe above, as long as it is called frequently enough. It means there is no need for the Arduino's serial buffer to hold more than one byte, and Serial.available() is never required to return the true number of bytes in the buffer, as long as it returns >0. But it is a workaround rather than a solution, and it seems a shame to have to implement a second serial buffer in a program to mask the fact that the 64 byte buffer that already exists isn't working.
I hope this makes everything clear. If I can provide any more information please let me know.