What exactly does the nrf_serial_flush?

[Fernando Fontes]

Hello, 

I'm doing a project with Zigbee using the nRF52840 and I want to read some sensors that talk via UART. 

I have ported with success the nrf_uart example but after discovering that this library doesn't have support for multiple UART instances I've changed to the nrf_serial library. 

Everything is working, but I'm lacking some understandings regarding for instance the nrf_serial_flush() function. What is the purpose of this function? In the beginning, I thought that the purpose of this function was to clear out the buffer and assure the transmission in a blocking state. However, that's not true.

I want to be able to toggle a GPIO pin after the transmission done, like having a transmission done pin. How can I do that? I'm using DMA and for now, the only way that I discover to do that was by using the nrf_queue_is_empty() function to constantly check if the queue is already empty.... That solves the problem but creates an unnecessary overhead to the CPU in my option because I'm polling the nrf_queue_is_empty() function.

Thanks in advance,

Best regards,

Fernando

[Fernando Fontes]

The NODEB will only reply to NODEA upon receiving the terminator character ('\r') so I don't think so. But I will add a small delay to eliminate this possibility. 

I'm not handling overflow and framing errors. When does the overflow occur? 

#define SERIAL_FIFO_TX_SIZE 100
#define SERIAL_FIFO_RX_SIZE 100

#define SERIAL_BUFF_TX_SIZE 1
#define SERIAL_BUFF_RX_SIZE 1

Those are my defines, so in theory, since the FIFO size is always bigger than the data sent from both nodes, the overflow shouldn't occur right? But even if I decided to go with a smaller FIFO, since I'm lopping the nrf_serial_read function, that shouldn't also be a problem, since the FIFO is always being clear out? 

What I'm doing before transmitting is clearing both transmit and receive buffers, so that messages pendent to send or to receive don't interfere in the new transmissions.

[Fernando Fontes]

Just tested and it is indeed a frame error. I added an event handler for the NRF_SERIAL_EVENT_DRV_ERR, and now, every time I get this framing error I'm un-initializing and initializing again the serial module. This kinda solves my problem, but I'm constantly receiving framing errors and losing messages. Why these framing errors are happening so often? I'm using FreeRtos... I read some threads with related issues when using the UART with the freeRtos... 

[Susheel Nuguru]

I do not think that the framing error is due to the FreeRTOs+UART combo. Framing errors normally happen due to clock accuracy differences on both ends of UART. Please check the HFCLK clock accuracy (more specifically clock that effects the UART baudrate accuracy) on both ends to see if both nRF UART and the peer UART's clocks are drifting away with time? 

If it was FreeRTOS+UART combo that causes the problem, I would expect it to be OVERRUN error and not FRAMING error. 

FreeRTOS port we have does not touch any HFCLK and does not touch any peripheral (other than RTC) registers for the RTOS/Kernel to work. So I would not suspect the combo right away. 

[Fernando Fontes]

I'm only running the ret_code_t err_code = nrf_drv_clock_init(); to initialize the clock.

I noticed that this function is a legacy one, could it be the reason? Should I waste some time trying to change these functions?

[Susheel Nuguru]

Do you have XO HFCLK on your board? If so you should also call nrf_drv_clock_hfclk_request to be able to explicitly start the crystal. If you have not done this, then most probably you are using internal RC HFCLK which is less accurate and would explain why you get framing errors so often.