nRF52 `app_uart_fifo` not using hardware? Overflow errors.

[Gordon]

Hi,

I posted recently about having used the app_uart driver and having problems with an overflow breaking uart receive (devzone.nordicsemi.com/.../)

I decided to try with app_uart_fifo and see if that was any better, but I'm still getting 'overflow' problems.

In fact, looking at the code, app_uart_fifo calls nrf_drv_uart_rx(..., rx_buffer, 1) - so it seems that even if I've allocated a 256 byte buffer for my fifo, and uarte is enabled, the hardware itself won't be used and I'll still get hardware overflow errors if an IRQ occurs at the wrong time at higher baud rates.

Is this the case? I'm using SDK12.3 but it looks to be the same in SDK14 as well.

Are there any examples/libraries available that use the UARTE hardware with a circular buffer, so I can be sure that I won't get overflows - or is there a hardware problem which means it can't be done? It seems odd that Nordic's own libraries don't use it.

thanks!

[Jørgen Holmefjord]

Hi,

It is very hard to prevent overflow without using flow control lins. You can use the ENDRX_STARTRX shortcut to create a circular buffer. The backside of this, is that you will overwrite the buffer if you are not handling the first values in the buffer before the buffer is filled. Typically the user cannot accept data loss, and this circular buffer is therefore not a good solution.

The UART driver support RX double buffering, by calling nrf_drv_uart_rx() two times. This allows you to process one buffer, while the other is filled. Have you tried this approach?

Best regards,

Jørgen

[Gordon]

Thanks! What do I have to do to use the UART driver double buffering with app_uart? Or do I need to use the driver directly?

ENDRX/STARTRX sounds great - realistically all the input data can be handled fast enough - it's just when it arrives while an IRQ is being handled (and I know those will only be of a certain length). Is there an example of using it? It seems nontrivial as the data is not guaranteed to be in RAM after an RXDRDY

[Jørgen Holmefjord]

I can't see that app_uart support the double buffering feature. You will have to use the driver, or the peripheral directly to achieve this. You are correct that it will be nontrivial to know when the samples are present in RAM. Unfortunately, there is no signal except the ENDRX that guarantee that the samples are transferred to RAM.

[Gordon]

Ok, thanks! since it's using DMA, presumably you could be pretty sure that the data was written if you just waited 50 clock cycles or so? I'll give the double buffering a go then - it'll be a lot easier and may just be good enough.

[Jørgen Holmefjord]

Unfortunately, I don't have any hard timing numbers avalable, but I suppose the EasyDMA would be 1-2 bytes behind the received bytes, as shown in the UARTE documentation. Maybe this might be of some help? By counting the RXDRDY events, you should be able to make sure you are not reading faster than the bytes are written.