• State Not Answered
  • Replies 33 replies
  • Subscribers 67 subscribers
  • Views 10308 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 113632
Options
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

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.

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
  • 0

    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.

  • 0 in reply to RK

    In the first paragraph I was saying about Receive TimeOut RXTO, In the second paragraph, I said that UARTE cannot stop in the midst of receiving a byte, the first paragraph and the second paragraph are saying two different things. The manual actually seems to concentrate on flow control, it did not say anything what happens when you are not using flow control. I tried to mention that even without flow control, the RXTO is still there, so you will see that delay. The manual DID NOT conflict with the behavior you are seeing, its just that it did not mention the non flow control part explicitly.

    @RK, do you agree to what I say? seems like my wordings are still confusing for parco, could you put it in better words?

Reply
  • 0 in reply to RK

    In the first paragraph I was saying about Receive TimeOut RXTO, In the second paragraph, I said that UARTE cannot stop in the midst of receiving a byte, the first paragraph and the second paragraph are saying two different things. The manual actually seems to concentrate on flow control, it did not say anything what happens when you are not using flow control. I tried to mention that even without flow control, the RXTO is still there, so you will see that delay. The manual DID NOT conflict with the behavior you are seeing, its just that it did not mention the non flow control part explicitly.

    @RK, do you agree to what I say? seems like my wordings are still confusing for parco, could you put it in better words?

Children
No Data
Related