Two USARTs on AT91RM9200 (running linux built by Buildroot) are used to send and receive data packets of variable length (typical 513 bytes) at baud rate 250K. Between the data packets is a break of approximately 112 microseconds. USART is set to interrupt on receiving breaks. DMA is used for data transfer. When USART interrupts on receiving a break (RXBRK), the interrupt service routine (ISR) reads DMA data counter to mark the beginning of a new packet in the DMA buffer, and then transfers the data of the packet just received from DMA buffer to device buffer.

The problem I have now is that from time to time when RXBRK interrupt comes and the ISR reads DMA counter ATMEL_PDC_RCR, the counter value is already 1 byte beyond the beginning of the packet. It looks like the RXBRK interrupt is not serviced quickly enough and the DMA already transfer the byte following the break into the DMA buffer when the ISR is invoked.

Would you please give some pointers on what might cause the delay and how to improve it? Thank you!

Presumably you have verified on a scope or logic analyzer that the serial waveform at the time of these failures does match your expectations? ie something more solid than just seeing the first byte of the packet, with no time-tagging for the DMA transactions or ability to probe the chip internally.

Does this occur if the break time is increased? What happens if you reduce the break time? ie develop some bounds for the latency condition, and prove that it really is a latency issue, and not a miss-detection of a break.

What other interrupt activity in the system could preempt the servicing of the USART break? Can you increase/re-order some of the priorities?