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.

[parco]

Thanks @RK. Does any of that change if I'm not using Hardware Flow Control?

Say for instance I had a stream of bytes coming in at 9600 baud, b1 b2 b3 b4 b5 b6 b7 b8 .. bN

If the STOPRX was issued during b5, an ENDRX will fire allowing me to collect b1-b4. Then I can change pointers and issue a FLUSHRX to collect the rest b5-bN?

[RK]

That's covered in the manual as well - they have a note about what happens when you are not using flow control. It's not however clear what happens to a byte in-flight when you stop the UARTE, seems to indicate it stays in the RX FIFO and doesn't get copied via DMA, but it may well depend on how late you stop it.

Not entirely sure what use case this would really matter for however. If you know you want 4 bytes, then set it up to receive 4 bytes and that's what you'll get, and you can update the memory address when you have them and continue. If you don't know until you've read the bytes, set it up to receive more than 4 bytes, stop it, copy anything extra to the start of the buffer, set the pointer up offset by a byte or two if necessary, flush and restart it.

[parco]

I'll give this a shot, thanks!

[parco]

No luck so far, it seems the ENDRX interrupt is being fired about 4 bytes after the stop rx, which doesn't seem to agree with the manual.

The timing is strict with this protocol and I do need to be able to force an ENDRX while still receiving in another buffer. I have a feeling by using STOPRX to do this is causing bytes to be lost.

[Susheel Nuguru]

Hi,

You also said " it seems the ENDRX interrupt is being fired about 4 bytes after the stop rx, which doesn't seem to agree with the manual"

Quote from the spec

The UARTE is able to receive up to four bytes after the STOPRX task has been triggered as long as these are sent in succession immediately after the RTS signal is deactivated. This is possible because after the RTS is deactivated the UARTE is able to receive bytes for an extended period equal to the time it takes to send 4 bytes on the configured baud rate.

The above mentioned behavior makes sense because when you do a STOPRX which in turns deactivates the RTS signal, the peer device might take some time to see that it should stop sending more bytes if the flow control is simulated. So UARTE on nRF52 allow 4 more bytes to be transmitted. Also note that when This is also similar with UART with no EasyDMA

When flow control is enabled, the UART will deactivate the RTS signal when there is only space for four more bytes in the receiver FIFO. The counterpart transmitter is therefore able to send up to four bytes after the RTS signal is deactivated before data is being overwritten. To prevent overwriting data in the FIFO, the counterpart UART transmitter must therefore make sure to stop transmitting data within four bytes after the RTS line is deactivated.

I think if you want the other side to stop transmitting immediately after STOPRX is triggered, then use flow control and make sure that the peer uart also has hardware flow control (not CPU simulated flow control)