UART event handler continually called with event APP_UART_TX_EMPTY

[Phil]

We are using nRF52832 with SDK_15.3.0 running the Nordic UART service (NUS) example.

Out of the box we find that the uart event handler is continually being called with event APP_UART_TX_EMPTY..   I would  expect that this event would only occur at the point the TX FIFO becomes empty.  

Looking into the source it appears that NRF_DRV_UART_EVT_TX_DONE event is continually being triggered.  I am assuming (and could be wrong) that this  event is set when the UART hardware transmit buffer becomes empty, after the last bit is clocked out.  

My concern is that the uart event handler is a call-back function that ultimately is called from the uart interrupt.  This would indicate that the uart interrupt is continually occurring.  It's as if an interrupt is not being acknowledged in the driver. 

Could someone please confirm this.

How can we prevent the uart event handler being called contrinuously, preferably without modifying the uart driver source?  Is there a setting to enable this event?

[Marjeris Romero]

Hi Phil,

Looking into the source it appears that NRF_DRV_UART_EVT_TX_DONE event is continually being triggered. 

Are you sure the NRF_DRV_UART_EVT_TX_DONE is continually being triggered in your application? I don't see this happening when I test the ble_app_uart example... If you for instance check the ble_app_uart example, and try to send a message through BLE to the device using nRF Connect, then wait a few seconds so you know the message is finished being printed though UART, and then set a breakpoint in line 111 at app_uart_fifo.c (after NRF_DRV_UART_EVT_TX_DONE), you will see that the application is not stopping here.

The uart event handler is not being called continuously. Have you done any changes to the ble_app_uart example? Can you share your code?

Best regards,

Marjeris

[Phil]

Problem sorted.  Debug code was sending a byte to the UART, from within the UART interrupt.  Of course sending a byte causes the TXRDY event to occur and triggers another interrupt, which caused the debug code to run....   A circular problem.

My mistake.  However, the upside is that we will change to using the Serial Port Driver in SDK_15.3.0 and use UARTE.

Thanks for everyone's suggestions.