To clarify the issue.
AFAICT, you loop reading in data until there hasn't been any data for the time taken to send 5 bytes.
Definitively an issue and will add a check for that. I have lots of extra space in the processor, so the buffer is roughly 3 times larger than the largest allowed packet.
it's a bit confusing! So, from what I can make out your problem is that something (test PC or something) sends 8 bytes and some boards see those 8 bytes while some boards see 9 bytes. OK?
Have you verified the received data to determine that a) the 8-byte ones see the correct 8 bytes, and b) the 9-byte ones see 8 correct bytes and whether the extra byte is at the start or end (or middle)? That kind of info can quickly lead to the cause of the problem.
Yes, that is exactly the issue. The AVR is connected to a PC over RS485, the AVR uses a RS232 to RS485 transceiver and the PC uses a RS485 to RS232 to USB-COM.
I can control the exact amount of data being sent from the PC and can confirm it with a logic analyzer.
The extra byte is always at the end of the transmission and always contains zeros.
Do you ensure the receive buffer is empty before enabling the interrupt?
The buffer index variable is always reset when entering the ISR, the entire packet is received within the ISR.
That is, might the ISR be triggered by existing data before the real data turns up?
Not sure, the receive buffer is only written to in the RX ISR and is separate from the transmission buffer.
I have verified this by using "Data breakpoints" to see if the buffer is written to when not intended.
The RX buffer is also parsed in a separate function separate from the ISR to ensure that the packet is good.
Do you check the UART status flags at any point to see if there are errors (frame error, overrun, etc)?
I have previously had error checking where I would abort the interrupt if any of the error flags were set. The Frame Error (FE) flag would be set almost all the time anywhere in the packet on some boards even though all bytes were received without any problems. This was a while ago and I completely forgot about it until now, might be reflections in the RS485 line? The signal looks relatively good on the scope which is why I’m asking about the software.
You talk about other interrupt-driven processes ongoing. Could any of these override the USART interrupt? If so, do any of them touch the USART registers?
Not complete sure what you mean, the AVR can que up to two interrupts if I remember correctly and all other interrupts are executed incredibly quick so I doubt that they would effect the RX interrupt. I also disable some interrupts when entering the RX ISR and reset other asynchronous counters to avoid any ISR conflict.
Thanks for the input!