error codes for APP_UART_COMMUNICATION_ERROR

[ms360]

I'm seeing a few of these errors in my uart evt handler

I cannot seem to find where these are enumerated in app_uart_fifo.c or nnrf_drv_uart.h or nrfx_uarte.h.

Question 1 - Where can I find these?  

<error> app: APP_UART_COMMUNICATION_ERROR : 1 00
<error> app: APP_UART_COMMUNICATION_ERROR : 5 00
<error> app: APP_UART_COMMUNICATION_ERROR : 4 00

Here is the code generating that log - 

NRF_LOG_ERROR("APP_UART_COMMUNICATION_ERROR : %d %02x", p_event->data.error_code, NRF_UARTE0->ERRORSRC);

When this happens, I try to run

app_uart_flush();

app_uart_close();

APP_UART_FIFO_INIT();

Question 2 - Is there a better way to recover? 

Thanks!

[Vidar Berg]

Hello,

The error message is including the value from the UART ERRORSRC register. 1 = OVERRUN, 2 = PARITY, and so on. 

When this happens, I try to run

app_uart_flush();

app_uart_close();

APP_UART_FIFO_INIT();

What happens if you don't do this? The app uart library should "recover" (i.e. re-enable reception) by itself if you just ignore the APP_UART_COMMUNICATION_ERROR event. 

Best regards,

Vidar

[ms360]

Thanks Vidar. The double digit hex value is the ERRORSRC register in my log. 

The single digit that precedes it is p_event->data.error_code, which is showing 1,4,5 in this case. 


I am considering trying nrfx_uarte to see if this still happens 

[ms360]

Just to expand, I'm running at 115200 baud, and I'm sending 8 bytes every 100ms, and about 21ms later, I receive 66 bytes. This does not seem like a lot to cause an overrun. 

[Vidar Berg]

I would recommend considering the Libuarte - advanced UARTE driver in that case. It allows you to work with larger DMA buffers in addition to supporting double buffering. The /examples/peripheral/libuarte example demonstrates how the driver can be integrated. 

[ms360]

Awesome thank you. I'll follow up.

[Vidar Berg]

ms360 said:

Just to expand, I'm running at 115200 baud, and I'm sending 8 bytes every 100ms, and about 21ms later, I receive 66 bytes. This does not seem like a lot to cause an overrun. 

this was less data than I expected. Are there any other interrupts except that may be blocking the UART ISR? The internal UART HW FIFO buffer is 4 bytes + 1 byte in your DMA buffer so I would have assumed that it should be able to keep up with this. 

[ms360]

I am using several app_timer, I'm not sure if that has any critical sections. 
There is also I2S driving a ws2812 like display, triggered in app_scheduler. 

I am also not using 

APP_TIMER_CONFIG_USE_SCHEDULER, I am pushing tasks to the scheduler from interrupts. 

[Vidar Berg]

The app timer callbacks are invoked in the RTC IRQ context (unless the module is configured to use the app scheduler). However, if you are always receiving the same fixed number of bytes (66), it may be easiest to use the nrfx_uarte driver directly. This reduces complexity in buffer handling (no byte counting is needed, and you will not receive an RX interrupt until the buffer is filled).

https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/hardware_driver_uart.html 

[ms360]

Each response has a fixed number of bytes, which is known ahead of time when I make the request. Interesting suggestion tho.

I got libuarte kind of working. I was getting intermittent responses depending on the timeout counter. Is that a receiver to idle timeout? I couldn't find many details. 

I tried both processing the data with the queue in app scheduler, or skipping the queue and adding bytes to my ring buffer from the interrupt. both yielded the same results. Then when I connected a logic analyzer to the hardware, it sparked and now I'm waiting for a new shipment of hardware. 

[Vidar Berg]

ms360 said:

Each response has a fixed number of bytes, which is known ahead of time when I make the request.

As long as you know the number of bytes ahead of time it should be easy to use the UART driver directly. This require fewer resources and has lower complexity compared to the UARTE driver.

ms360 said:

I got libuarte kind of working. I was getting intermittent responses depending on the timeout counter. Is that a receiver to idle timeout? I couldn't find many details. 

Yes, the timeout is to detect when the receiver has stopped receiving new data, but I'm not sure how this could lead to intermittent responses.