NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR without explanation

[Kenzi]

I'm getting an occasional NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR, it often takes over 24 hours to reproduce, and the libuarte appears to be generating garbage after the error happens.

We're using SDK 16, SoftDevice 132 v7.0.1, and the device is sitting on an RS485 token bus.

The issue is pretty much identical to this one: https://devzone.nordicsemi.com/f/nordic-q-a/74726/getting-nrf_libuarte_async_evt_overrun_error-after-long-time-of-use  I saw no cause or resolution to it.

NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR is for the hardware FIFO, correct?  Or does this also occur when DMA is full?

I'm guessing that DMA is not doing its job, so it must be some kind of timer conflict. I'm using Timer1 and Timer2 for libuarte.

Our DMA is using 8 buffers with a size of 255.  Our interrupt routine simply moves any incoming bytes into an internal software buffer, so these buffers appear to be way overkill. It would have to be a pretty serious interrupt latency for this to be a problem.

There appears to be some correlation with a lot of Bluetooth devices advertising nearby; when Bluetooth is turned off, we do not see this issue.

Not sure where to go from here.

[Simonr]

Hi

The case you linked to was resolved with the latest reply from Roy, where he says that the latest changes to their libuarte init function and increase to their buffer let them run the application for several days without issues. 

Libuarte has detection of RX buffers not being set on time (this may occur when the HWFC isn't used). Libuarte_async will report that as the NRF_LIBUARTE_ASYNC_EVT_OVERRUN_ERROR. This event will contain the number of dropped bytes as well.

Best regards,

Simon

[Kenzi]

Our DMA buffers are already at maximum size.  I am trying two different timers like Roy did, we'll know if that fixes it in few days.  But in the mean time, I'm trying to understand other reasons why this could happen, because I'm not seeing any obvious evidence of it being a timer conflict or a delay long enough to cause a DMA overflow.

By 'RX buffers' you mean the 6-byte hardware buffer?

By HWFC, you mean hardware flow control - CTS/RTS?

Are you saying that if HWFC is not enabled, DMA may not be fast enough to keep the UART's RX buffers from overflowing?  Or does this only happen if the DMA's target buffers are full?

Is there any explanation for why the UART seems to go belly up and receive only garbage after this point? (Does that point to a timer/counter conflict?)

Thanks,

- Kenzi

[Simonr]

Hi Kenzi

With the RX buffer I'm referring to the libuarte RX buffer that is set in the application. If these are not freed fast enough in the NRF_LIBUARTE_ASYNC_EVT_RX_DATA event, you may run into errors.

Yes, by HWFC I mean hardware flow control, sorry. I should have specified.

Not using HWFC might not let the DMA pause transmissions when necessary to let a new buffer be available.

Best regards,

Simon