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)

[parco]

I only know to STOPRX when I see that an idle time of 1.5ms occurs. There is unfortunately no way of anticipating when that might be beforehand.

[esja]

Ah, I see. Then I did misunderstand somewhat :)

And the external UART gives you no time to process after signalling package end by the 1.5ms idle time? I.e. you need to be able to receive next message immediately?

Seems like you could have used the RXDRDY event from the legacy UART to count bytes received after STOPRX and use that in the kind of suggestion RK made above. Have you tried checking that out if that still does anything?

[Susheel Nuguru]

Hi,

The manual was written with flow control in mind and I see that the interpretation for the non flow control part is not clear. When the flow control is not enabled, the 4 bytes waiting timeout is still enabled allowing the UARTE to receive 4 bytes. The text that says that the "bytes has to be in succession" is little confusing and I think it should have said that "UARTE will be able to receive upto 4 bytes after STOPRX has been triggered (which is equal to RXTO, still enabled when flow control is not enabled)".

parco, Are you expecting that when you trigger STOPRX you will get ENDRX event immediately? This will not happen even if RXTO is disabled when flow control is not used. This is because when you trigger STOPRX, UARTE could be in the middle of receiving a byte and it will not stop until it receives that byte completely, so according to your protocol you will receive that extra byte anyways. so instead of 7 bytes you might have 8 bytes in your buffer depending on when you triggered STOPRX.

[parco]

Aryan, I'm a bit confused. In the first paragraph you say the UARTE will wait and receive up to 4 bytes to the buffer after a STOPRX. But in the second paragraph you say it will stop once it receives that byte completely. What's actually happening during testing is the first scenario with 4 bytes, and the manual figure 95 shows what you describe in second paragraph. I'm just a bit frustrated since it is deceiving.

[Susheel Nuguru]

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?