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)

[esja]

Hi,

First off, I think RK has made some great insights here, so thanks!

I can tell you that the RXTO is generated via an internal timer which is counting on the baud rate clock. Thus, if you have ample room in your RX buffer, following a STOPRX, it will take the time it takes for 4 bytes to transfer (even if no byte is transferring) for the ENDRX to be generated (followed by the RXTO). If you only have room for say 2 more bytes at STOPRX, then if the external uart is transferring continuously you would get ENDRX after those 2 bytes, and RXTO after 4 bytes, and 2 bytes would be left in the FIFO for you to push.

It could have been designed to have this feature optional, i.e. that you could make it close the RX buffer immediately or after any byte that was currently in progress, and then generate ENDRX. This is not the case in the hardware on nrf52 though.

I gather you want the protocol to not relate to a fixed number of bytes received, but rather a fixed timing of each message with a variable amount of bytes received? You just want a clean split on each of the messages? Perhaps there is an alternative (albeit a bit cumbersome) approach you can try. If I’ve misunderstood I suppose you can disregard the rest.

Use a TIMER on the nrf52-side: start the timer on RXSTARTED, give a compare event on TIMESLOT-(4*Baudrate), stop the UARTE based on the compare event.

If you keep MAXRX larger than the absolute max bytes you can receive on that baud rate in the timeslot of your protocol, you know that all the bytes in the buffer at ENDRX were transferred as part of a single message. Then do a restart on RXTO and the new RXPTR will be in effect, a new RESTARTED will restart the TIMER etc. The period your UARTE is unable to receive would be basically zero.

[parco]

Thanks for the writeup. It's unfortunate the option to "close RX" is not available in hardware, I feel as though the FLUSHRX task should have that functionality, but it doesn't.

I'm not sure what TIMESLOT would be equal to. Since the messages are variable length, the time each will take is also variable.

[esja]

But you know when to trigger STOPRX from the CPU? i.e. even if it varies between the messages? The main point was to trigger STOPRX "the time it takes to transfer 4 bytes" earlier than you currently do it to be sure that all bytes in the current RX buffer was from the same message.

[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?