I saw some similar question, but none is what I am experiencing.
I notice some weird behavior while testing DMA mode, so I made a simple setup:
I set the DMA buffer to be 100 bytes, and a timeout of 100ms, and a custom callback:
Then on PC side, i send message of 10 bytes, this is to make sure there is no buffer switch, only timeout from UART_RX_RDY, to avoid any possible mistake with buffer management.
Baudrate is 921600
WHAT DO I EXPECT:
100ms after i sent the message, the callback app_uart_async_callback() get called with event data rx.buf containing my 10 byte message, rx.offset to be 0, and rx.len of 10
If i send another message, the same as above, only difference is the rx.offset is now 10.
And so on until the buffer is full and all the required callback to change buffer get called
WHAT IS HAPPENING:
while sending the message from pc, the callback app_uart_async_callback() get called with event data rx.buf containing ONLY X bytes, rx.offset to be 0, and rx.len of X, where X is between 1 and 10; the TIMEOUT is not respected at all!
What is worse is that i do NOT get a second callback with the remaining data!
Now, at this point, if i send an extra message lets say 1 bytes, the callback is called and all, with rx.len = 1, but as result i see the OLD data that was not served!
MY CONCLUSION:
- according to docs, the TIMEOUT should start at the END of the last bytes, as it is inactivity, this is NOT happening
- even if timeout is counting since the first message is received, ad 921600 baud i should be able to receive 9216 bytes before timeout
- clearly something is wrong in the way the timeout for UART_RX_RDY or the event rx.len is calculated!
- this lead to possibility where data is received, and my application has NO WAY to know it has been
- UART_RX_BUF_REQUEST and RELEASED seems to work properly and get called at the right time, with the correct amount of data in rx.len. SEEMS because due to the delay output, is a bit difficult to notice if data is missing without a proper automated test.
