Avoid lost bytes on STM32/USARTv1 with RTS/CTS Topic is solved
Posted: Mon Jan 02, 2023 10:53 pm
In uart_lld_serve_interrupt() of the STM32/USARTv1 implementation, the following line reads the data register, clearing it by that:
(void)u->DR; /* SR reset step 2.*/
This causes a problem in the following context:
- DMA is IDLE
- An send operation is started
- The UART receives a single byte and RTS goes up
- the send operation completes and uart_lld_serve_interrupt is called
- uart_lld_serve_interrupt reads the DR, clearing it
- a call to uartStartReceive should receive the byte it, but it's already gone
This scenario requires the changes from my previous request as DMA wouldn't be in the idle state when the byte is received. However, I guess it's possible to construct a race condition where the data register is read (as part of TX complete/uart_lld_serve_interrupt) at the very same moment/clock cycle the byte was stored there by the UART peripheral, just before DMA got a chance to read it out - very unlikely, but not impossible.
A simple fix would be to remove that line from the UART driver. I'm not aware of a reason to read the data register in the interrupt handler, after all, it was received and should be provided to the application.
Background: I was running our Bluetooth A2DP Source demo that streams music to a remote speaker and got dropped bytes when the new read request was issued after the first byte of the next packet was received and the TX complete fell between those two events. After commenting this line, the demo worked as expected.
(void)u->DR; /* SR reset step 2.*/
This causes a problem in the following context:
- DMA is IDLE
- An send operation is started
- The UART receives a single byte and RTS goes up
- the send operation completes and uart_lld_serve_interrupt is called
- uart_lld_serve_interrupt reads the DR, clearing it
- a call to uartStartReceive should receive the byte it, but it's already gone
This scenario requires the changes from my previous request as DMA wouldn't be in the idle state when the byte is received. However, I guess it's possible to construct a race condition where the data register is read (as part of TX complete/uart_lld_serve_interrupt) at the very same moment/clock cycle the byte was stored there by the UART peripheral, just before DMA got a chance to read it out - very unlikely, but not impossible.
A simple fix would be to remove that line from the UART driver. I'm not aware of a reason to read the data register in the interrupt handler, after all, it was received and should be provided to the application.
Background: I was running our Bluetooth A2DP Source demo that streams music to a remote speaker and got dropped bytes when the new read request was issued after the first byte of the next packet was received and the TX complete fell between those two events. After commenting this line, the demo worked as expected.
