UART interrupt lost

[amaesa]

Problem: bytes are lost during UART communication with the module, hardware flow control is enabled, at speed higher than 38400 baud/s, when softdevice enabled and test board is communicating with another NRF52832 module via BLE. Program works properly at 38400 baud/s or lower speed.

Module: NRF 52832

NRF SDK: 15.0

Host computer: Linux Ubuntu 18.04.1 LTS

Configuration: Host pc running a test program connected via serial port (FTDI - UART) to a test board with the NRF52832 module.

Description & example:

The program running on the NRF52 requests an asynchronous, non-blocking read from UART using for 1 byte nrf_drv_uart_rx(UART_INSTANCE, &buffer[0], 1). The call is repeated after a byte is received and processed.

After a random time interval, and several bytes exchanged correctly, the NRF52 seems to be loosing an interrupt signaling reception of a byte (UART driver).

When this interrupt is presumably lost, the NRF52 keeps receiving 4 bytes, then signal to the host pc to stop sending bytes (as indicated in the documentation, this is correct behavior).

The host pc program correctly stops - I call tcdrain() after each write() to the serial port - after it has sent the following last bytes (just an example, actual bytes may vary, depending on when communication stops).

("oldest" byte sent, decimal values)

183

239
220
131

126

(last byte sent)

Debugging the program running on the NRF52, the last byte that the program was able to process is 183.

Bytes 239, 220, 131, 126 are "lost" but presumably in the UART receiver FIFO, as if I look at the register RXD of the UART instance correctly contains the next byte "239". It looks to me the interrupt that should signal that byte 239 is

available is lost and the event "NRF_DRV_UART_EVT_RX_DONE" never executed by my interrupt handler.

I am not really sure how I should handle this case, how to detect when a UART interrupt is lost, and to resume the communication.

Here the rest of the UART instance register when the problem occurs.

TASKS_STARTRX    volatile uint32_t    0   
TASKS_STOPRX    volatile uint32_t    0   
TASKS_STARTTX    volatile uint32_t    0   
TASKS_STOPTX    volatile uint32_t    0   
RESERVED0    const volatile uint32_t [3]    0x40002010   
TASKS_SUSPEND    volatile uint32_t    0   
RESERVED1    const volatile uint32_t [56]    0x40002020   
EVENTS_CTS    volatile uint32_t    1   
EVENTS_NCTS    volatile uint32_t    0   
EVENTS_RXDRDY    volatile uint32_t    0   
RESERVED2    const volatile uint32_t [4]    0x4000210c   
EVENTS_TXDRDY    volatile uint32_t    0   
RESERVED3    const volatile uint32_t    0   
EVENTS_ERROR    volatile uint32_t    0   
RESERVED4    const volatile uint32_t [7]    0x40002128   
EVENTS_RXTO    volatile uint32_t    0   
RESERVED5    const volatile uint32_t [46]    0x40002148   
SHORTS    volatile uint32_t    0   
RESERVED6    const volatile uint32_t [64]    0x40002204   
INTENSET    volatile uint32_t    131716   
INTENCLR    volatile uint32_t    131716   
RESERVED7    const volatile uint32_t [93]    0x4000230c   
ERRORSRC    volatile uint32_t    0   
RESERVED8    const volatile uint32_t [31]    0x40002484   
ENABLE    volatile uint32_t    4   
RESERVED9    const volatile uint32_t    0   
PSELRTS    volatile uint32_t    5   
PSELTXD    volatile uint32_t    6   
PSELCTS    volatile uint32_t    7   
PSELRXD    volatile uint32_t    8   
RXD    const volatile uint32_t    239   
TXD    volatile uint32_t    126   
RESERVED10    const volatile uint32_t    0   
BAUDRATE    volatile uint32_t    30924800   
RESERVED11    const volatile uint32_t [17]    0x40002528   
CONFIG    volatile uint32_t    1   

Thank you for any help.

[Vidar Berg]

Hi,

Does RX reception get re-enabled if an error condition occurs (reported through NRF_DRV_UART_EVT_ERROR driver event) in your application? Maybe you are getting an framing error,etc that effectively disables RX? 

[amaesa]

Hi Vidar, I've actually just found this fix that was posted few days ago, which seems to have eliminated the issue at higher baud rates. https://devzone.nordicsemi.com/f/nordic-q-a/37120/nrfx_uart-bug

[Vidar Berg]

Thanks for the update. I was not aware of this limitation in the UART driver. Fortunately it was an easy fix.

Be aware that you will loose bytes if there are framing errors (error conditions) which might be acceptable in your case. If not you could try to enable HFXO to see if it improves the performance at higher baudrates (sd_clock_hfclk_request).