RE: UARTE internals (bare metal programming): Continuous reception, BREAK condition detection and how to use UARTE like a FIFO

ovrebekk — Thu, 02 Mar 2023 11:42:24 GMT

Hi Michael

In general I would not recommend implementing low level peripheral drivers from scratch, unless you have very specific and challenging requirements. Our low level team have intimate knowledge of the Nordic hardware, and have developed the nrfx drivers over several years based on internal and external input. Even more importantly, these drivers are implicitly tested by thousands of customers (and our own internal tests), meaning any issues in the driver will be reported and fixed much quicker. Even if you are a better developer the most likely outcome is that you will spend a lot of time developing a similar driver that might be better designed but that will have gone through significantly less testing.

With that out of the way, I will try to respond to your specific questions below:

[quote user=""]Question 0: How big is the internal FIFO of the UARTE modules?[/quote]

The RX FIFO is 4 bytes in size.

For TX there is no FIFO.

[quote user=""]Question 1: What happens to the remaining bytes in the internal FIFO when a new STARTRX task is triggered? Will the FIFO content be written to the EasyDMA buffer without date being lost? Or will the bytes in the internal FIFO be discarded when a STARTRX task is triggered? For reliable data reception (that does not miss any bytes on the UART while the receive buffer is switched), it would only make sense to continue writing the internal FIFO content when STARTRX is triggered, especially in combination with the ENDRX-STARTRX short which immediately restarts reception if the buffer is full.[/quote]

Yes, if there are any remaining bytes in the FIFO when you issue STARTRX these will be written first, before any new incoming data.

[quote user=""]Question 1a: When using the ENDRX-STARTRX short, will there no data be lost if the old EasyDMA buffer is full, and the STARTRX task continues reception into the next buffer?[/quote]

That is correct. The double buffer mechanism of the EasyDMA PTR register ensures that handover between the buffers happens immediately, and as long as you ensure to always provide the next buffer before the current buffer is filled up there is no risk of data loss.

[quote user=""]Question 1b: When using the ENDRX-STARTRX short, if STOPRX is triggered before the current buffer is full, because of the short, reception should automatically be continued into the next buffer, just like question 1a mentioned. Will there also be no data loss in this case? Is this the way to manually trigger a safe/robust buffer switch and handle available data?[/quote]

Yes. This is the safe way to be able to read out RX data before the buffers fill up, in case you want a timeout type behavior on the RX side where you can process data after a period of inactivity (our higher level drivers in the SDK provides a similar functionality).

[quote user=""]Question 2: I documented my approach in the following flow chart. Will this work without data loss? My goal is to take advantage of the UARTE capabilities and use large buffers that allow for using low priority UARTE interrupts that do not interfere with other time critical code in the system.[/quote]

Yes, this should work fine. The way we handle timeout in our drivers is that the timeout gets reset every time a new byte is received over the UART, meaning you will get an interrupt if there is no activity on RX for a predetermined amount of time, set by the timeout value.

This means that if you are receiving asynchronous messages of unknown length any new message will be processed after a delay set by the timeout period.

[quote user=""]I consider using a BREAK condition for synchronizing communication shortly before the beginning of a data packet. Unfortinately, there is very little information available about the BREAK bit in the ERRORSRC status word.[/quote]

My recommendation would be to add some packetization protocol to the data instead, rather than use breaks intentionally. I haven't heard about anyone doing that with our UARTE peripheral, and I am not sure how well it would work in practice.

[quote user=""]Question 3: Is the BREAK bit just set by the SoC (when RxD stays low for too long) and must be reset by software? Or is it automatically reset of a rising edge is detected on the RxD line, so that it does automatically reflect the current RxD state?[/quote]

The ERRORSRC register is set by HW and must be cleared by SW, more info here.

[quote user=""]estion 4: Is the BREAK bit only set while reception is active (STARTRX triggered, ENDRX not triggered yet)? Or can I completely stop reception, wait for the BREAK bit to become active (e.g. by polling the bit), and then manually start reception?[/quote]

You will not get framing or break errors if you haven't started RX, no. RX has to be running for these errors to occur.

[quote user=""]Question 5: If I detect a BREAK condition and trigger STARTRX while RxD is still low. Will I get an error event (interrupt) again? Or will the UARTE module just wait for the next falling edge on RxD (which is the trigger for the Start bit of a transmission) and start receiving?[/quote]

You won't get a BREAK condition in this case as explained in 4, but if you start RX while RXD is low you will get a framing and break error shortly after RX is started.

[quote user=""]By the way, it would be nice to have a BREAK event in a future version of the UARTE device for such purposes (and to prevent double events because of the frame error). Just a little suggestion for the engineers ;)[/quote]

This you would have to discuss with one of our sales directors, they are the channels for suggesting new software or hardware features. I can tell you that the hardware guys, like many engineers, are risk averse and won't make changes lightly ;)

[quote user=""]Question 7: What happens if the STARTRX task is triggered while reception is already active? (Will reception be restarted at the next RXD.BUFFER? Will ENDRX be triggered? Or will nothing happen at all?)[/quote]

I am 90% sure it will just be ignored if you trigger STARTRX while you are already in RX, but I will have to get this confirmed with the designers.

[quote user=""]Question 8: Is there any way to access the current state of the RXD EasyDMA unit which reflects the current buffer state in RAM? (If not, can you consider making it available in the next generation of devices? Naming it something like RXD.CURRENTAMOUNT or RXD.PROGRESSED or so? The information is already available in the system anyway...)[/quote]

There is not unfortunately. The easiest way we have found to do this is to count the number of RXDRDY events (either in hardware using a TIMER and PPI channel, or through an interrupt), as mentioned earlier, but this event could happen before the data is actually available in RAM. In order to be 100% sure how many bytes you have received you need to stop RX and read the AMOUNT register.

[quote user=""]Question 9: Considering what I have read in the documentation, it is not reliable to use the RXDRDY event in combination with a counter to manually count the received bytes and use it as the FIFO head, as the reflected data might not have been written to the EasyDMA buffer yet. (Also, I would be a bit worried about glitches when the counter module and the EasyDMA module go out of sync.) Do you agreee that this is not a reliable way to implement a simple and efficient FIFO with UARTE? Do you have any other suggestions?[/quote]

Like indicated in Q8 you can use RXDRDY as an indication that data has been received, but there still might be some delay between this event occurring and the data being available. The safe way is to stop RX and read the AMOUNT register, and use this as a final count that you can then use to update the FIFO.

I guess the problem of having a larger application FIFO that you fill with UART data directly is what to do when you stop the RX in the middle of a transaction. At this point the next buffer will already be configured, and you will get a gap in the FIFO depending on how many bytes were remaining in the buffer when the UART was stopped.

Either you need to keep the FIFO separate from the EasyDMA buffer, which will introduce another memcpy, or you need to accept some gaps in your FIFO, and include a length parameter for each block where you store the exact number of bytes in that block.

Best regards
Torbjørn