This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

UARTE STOPRX on exact byte

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.

image description

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)

Parents
  • 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.

  • Hi RK,

    You made me read the PS again :)
    This is what I am certain is happening.

    1. STOPRX is triggered, at this point we separate two things. EasyDMA and RX FIFO.

    1.a) EasyDma sees the STOPRX immediately and it would try to finish any ongoing transfers from FIFO to RAM buffer. This might be delayed because of the traffic in the system bus. After finishing the ongoing transfer the ENDRX event will be given. The EasyDMA will not pick any new bytes from the RXFIFO. The delay between STOPRX and END event is directly related to the time needed for EasyDMA to finish its ongoing transfer.

    1.b) the RX FIFO will still be able to receive 4 bytes of data after STOPRX is generated and this is not dependent on when ENDRX is generated. It is only depending on how many bytes are coming within next 4 byte transfer time with the set baudrate and how much space is left in RX FIFO. The incoming bytes AFTER STOPRX is triggered should stay in FIFO. You need to trigger FLUSHRX explicitly for moving this to RAM ....

Reply
  • Hi RK,

    You made me read the PS again :)
    This is what I am certain is happening.

    1. STOPRX is triggered, at this point we separate two things. EasyDMA and RX FIFO.

    1.a) EasyDma sees the STOPRX immediately and it would try to finish any ongoing transfers from FIFO to RAM buffer. This might be delayed because of the traffic in the system bus. After finishing the ongoing transfer the ENDRX event will be given. The EasyDMA will not pick any new bytes from the RXFIFO. The delay between STOPRX and END event is directly related to the time needed for EasyDMA to finish its ongoing transfer.

    1.b) the RX FIFO will still be able to receive 4 bytes of data after STOPRX is generated and this is not dependent on when ENDRX is generated. It is only depending on how many bytes are coming within next 4 byte transfer time with the set baudrate and how much space is left in RX FIFO. The incoming bytes AFTER STOPRX is triggered should stay in FIFO. You need to trigger FLUSHRX explicitly for moving this to RAM ....

Children
No Data
Related