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]

... work out when it's stopped sending, however it also seems still to have the 4 byte limit. That would make sense to me if, after sending STOPRX the UART stopped putting characters in the data buffer and started buffering them in the RX FIFO, immediately. That, to my mind, is what I'd expect it to do. Then the 4 bytes make sense as it only has 4 bytes of FIFO.

What it seems to do however is KEEP moving received characters to the data buffer, even though you asked it to please stop. At that point it doesn't really have a 4 byte limit, it could keep going until the data buffer is full + 4 more bytes, but it still stops after 4. I can see why, it separates the RX part into the FIFO from the EasyDMA part out of it again. To my mind it would be more consistent if the STOPRX task immediately stopped the DMA and no more bytes went to the data buffer, and any new arrivals stayed ...