UARTE STOPRX on exact byte

[parco]

Hi there,

I'm issuing a STOPRX at a specific time but I'm noticing that more bytes are being put into the buffer from after the STOPRX was issued.

Is there a way to stop the UARTE on the exact byte and process, and receive all bytes from that point on to a different buffer?

Please advise.

UPDATE

After triggering a STOPRX, the UARTE will hang around for a few more bytes, placing them in the same buffer and then calling ENDRX. This is problematic since these new bytes are part of a different message.

Here you can see that STOPRX is triggered during some small idle times, yet the ENDRX doesn't happen till much later.

This results in ENDRX being called with 11, 6 and 1 bytes read (when it should be 6, 6 and 6 bytes read)

[RK]

No. The documentation addresses this. if you're using nRF52 (UARTE so I assume so) up to 4 bytes can be received after the STOPRX task. How many actually are depends on what's on the other end transmitting data to you, if it's slow stopping after the RTS signal is deactivated and keeps sending more data, the UARTE is going to receive it. I assume you're using hardware flow control.

Those bytes however go into the RX FIFO so you can update the memory buffer pointer after you get the ENDRX event and then flush to start those bytes off in your new buffer.

[RK]

It is pretty confusing and the docs on this aren't the very best. Let's try another way of looking at it, I thought about it a bit just now.

Once you start a receive the UART will continue to receive until the sender stops sending. The only exception is if the UART runs out of space, when it has no choice but to stop.

Since UART is async, you never know the other side has stopped, so it infers it when there is no activity for a time dependent on the baudrate. If that time passes, it assumes the sender has stopped.

The RX FIFO is 4 bytes long, so in the usual case where you have received MAXCNT bytes and your data buffer is full, it can only receive 4 more bytes at which point, even if the sender is still sending, it has to stop.

This is where the STOPRX case, to me, seems inconsistent. It's still continues to receive while the other end send and it still uses the timeout to ...