What exactly does the nrf_serial_flush?

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Fri, 09 Jul 2021 12:04:19 GMT

Ok, thanks for the support. Great help :).

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Fri, 09 Jul 2021 11:55:15 GMT

[quote user="Fernando Fontes"]How is handled the reception in this implementation? Is it by interrupts? I know that there is an event handler putting the RX data into a buffer, but is this module still using easyDMA?[/quote]

Yes, it is interrupt based which is handled in nrfx_uarte.c/nrfx_uart.c. If EasyDMA is used or not depends on what you have set in nRF5_SDK_17.0.2_d674dde\integration\nrfx\legacy\apply_old_config.h NRFX_UARTE_ENABLED which inturn depends on your settings in sdk_config.h. Just set UARTX_ENABLED and UART_EASY_DMA_SUPPORT to 1 in sdk_config.h and you will see that easydma will be used though the hal driver nrfx_uarte.c

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Fri, 09 Jul 2021 11:03:33 GMT

Well, I switched to the app_uart_fifo implementation. It's a lot more stable than the nrf_serial. Libuarte would be my next option. But since app_uart_fifo seems to be stable I will stick with this one.

However, I've just finished the implementation a few minutes ago. It would be great if you could explain a few things about app_uart_fifo implementation.

How is handled the reception in this implementation? Is it by interrupts? I know that there is an event handler putting the RX data into a buffer, but is this module still using easyDMA?

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Fri, 09 Jul 2021 10:46:05 GMT

[quote user="Fernando Fontes"] I'm starting to think that this is somehow a priority-related issue... Is that possible? How are the DMA to RAM transfers being handled? Do I need to change the priority values?[/quote]

The priority of ISR handling becomes very important if you are not using HW flow control. But with this, i would still expect to see overrun errors and not framing errors.

[quote user="Fernando Fontes"]One of the tasks that I'm running in parallel is a Zigbee application and I noticed that with that task off, the framing errors are very low.[/quote]

I cannot put my head around this behavior. Are you seeing less errors per average transaction or are you seeing less errors per average time? Because if it is the second, I could understand as Zigbee task and stack taking more time to process its data and giving UART ISR less time to process its data.

[quote user="Fernando Fontes"]Yes, I have both 32Mhz and 32.768kHz external clocks. I tried to call the nrf_drv_clock_hfclk_request[/quote]

nrf_serial is somewhat less preffered library over libuarte and is also a reason we removed it from latest SDKs. Can you please try to move to libuarte? I know that this sounds like work, but there could be only two possibilities to explore. One is clock inaccuracies and the other is possible nrf_serial bug. I know that the libuarte is very stable so atleast we can exclude one suspecting direction.

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Thu, 08 Jul 2021 08:08:16 GMT

Yes, I have both 32Mhz and 32.768kHz external clocks. I tried to call the nrf_drv_clock_hfclk_request and the behavior is still the same. One of the tasks that I'm running in parallel is a Zigbee application and I noticed that with that task off, the framing errors are very low. So, I did a quick search to see if the easyDMA of UART1 is using repeated addresses but I guess no. I'm starting to think that this is somehow a priority-related issue... Is that possible? How are the DMA to RAM transfers being handled? Do I need to change the priority values?

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Thu, 08 Jul 2021 07:03:39 GMT

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.

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Tue, 06 Jul 2021 15:08:05 GMT

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?

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Tue, 06 Jul 2021 07:38:44 GMT

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.

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Mon, 05 Jul 2021 15:42:19 GMT

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...

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Mon, 05 Jul 2021 10:26:00 GMT

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.

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Mon, 05 Jul 2021 09:26:35 GMT

[quote user="Fernando Fontes"]

With the NODEB turned off, the NODEA is able to tranmitt forever without any problems (allways this data: 0x01 0x30 0x30 0x02 0x53 0x31 0x03 0x45 0x41 0x0d : 10bytes at 9600 bps).

With the NODEB turned on and responding after receiving the sent command, the NODEA after a while starts to send corrupted data and stops receiving the response from the NODEB (data: 0x01 0xc0 0x02 0x4a 0x0a 0x45 0x90 0xf8, 0x01 0xc0 0x02 0x2a 0x1a 0x45 0x90 0xf8 , ...)

[/quote]

Sounds like NODEA starts to misbehave both in transmit and receive when NODEB starts to send data. While you are waiting for the flush to happen, it is possible that the NODEB sends too much data that it might cause an overflow error in NODEA while waiting for the TX flush to happen? How is your application handling errors like overflow and framing errors? What is the size of the nrf_serial RX and TX buffers?

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Fri, 02 Jul 2021 11:20:55 GMT

Hmm, this is quite odd.

Let me explain my setup. I have MAX485 IC connected which will translate incoming messages to serial UART. Well RS485 handles both transmitted messages and received messages on the same line. So, I need to toggle a PIN to enter in transmit mode (which will then ignore the incoming data) and then toggle it again to quickly enter in receive mode.

This is already done thanks to your first explanation. Something like:

// Switch to transmit mode 
TOGGLE_TO_TRANSMIT_MODE;
// start writting to the FIFO
ret = nrf_serial_write(&serial1_uarte,
                buffer,
                buffer_size,
                &p_written,
                NRF_SERIAL_MAX_TIMEOUT);
// check if we write all the buffer data
if ( (p_written != buffer_size) || (ret != NRF_SUCCESS) ) {
    retval = pdFAIL;
}
// block until successfully transmit all the data
while ( nrf_serial_flush(&serial1_uarte, 0) != NRF_SUCCESS );
// Go back again to receive mode
TOGGLE_TO_RECEIVE_MODE;

Then, I switch to a polling state where I check for data until receiving a terminator character or timeout. Something like:

// try to read from serial until receiving the terminator or timeout
while( ((xTaskGetTickCount() - ticks) < timeout_ms) &&  (c != terminator) ) {
    // read in non-blocking mode
    ret = nrf_serial_read(&serial1_uarte, &c, sizeof(c), NULL, 0);
    // byte received?
    if (ret == NRF_SUCCESS) {
        if ( buffer_size > *read_bytes ) {
            buffer[*read_bytes] = c; // save this character
            *read_bytes = *read_bytes + 1; // increment
        } else {
            return pdFAIL; // max buffer size received
        }
    } 
}

So, I did a bit more testing and I experienced the following:

Nomenclature:

> NODEA: NRF52840 DK

> NODEB: Generic UART handler device

With the NODEB turned off, the NODEA is able to tranmitt forever without any problems (allways this data: 0x01 0x30 0x30 0x02 0x53 0x31 0x03 0x45 0x41 0x0d : 10bytes at 9600 bps).

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Fri, 02 Jul 2021 04:43:19 GMT

Hmm, seems like the nRF UART and the peer UART lost sync. This normally happens at high baudrates mostly when not using hardware flow control and when there are framing or overrun errors and it depends on how your application has handled it. Overrun error might be less harmful if your application is prepared and designed to tell the peer to retransmit it. But framing errors are a bit tricky as you might have to let the peer trasnmit the whole sequence of chars even after the framing error, reset nRF UART peripheral and then ask the peer to retransmit the whole sequence again to reestablish the sync.

Easier would be to tone down the baudrate a bit and if possible use hardware flow control.

RE: What exactly does the nrf_serial_flush?

Fernando Fontes — Thu, 01 Jul 2021 15:40:49 GMT

Hi Susheel,

Thank you very much for your explanation. It seems to work. However, now I'm having a strange behavior on the serial communication.

Everything is working for a while and suddenly I start to receive strange characters on the serial port and the

nrf_serial_read function stops working.

Increasing the FIFO size seems to improve, but does not fixes the issue... Do you have any idea of what could be the reason? I'm handling the serial port on a task (using freertos) and I understand that it could happen to lose some characters if the FIFO overruns, but why stop receiving at all? And what is the reason for the strange characters on the serial TX port?

Do you have any idea of a possible reason for that? Maybe I should give up on using DMA ...

Best regards,

Fernando

RE: What exactly does the nrf_serial_flush?

Susheel Nuguru — Tue, 29 Jun 2021 19:19:26 GMT

[quote user=""]Everything is working, but I'm lacking some understandings regarding for instance the nrf_serial_flush() function. What is the purpose of this function?[/quote]

I understand that the name is a bit confusing to what this function actually does. When you define the instance for nrf_serial using NRF_SERIAL_CONFIG_DEF you have a _sleep variable which is the function pointer for the application-specific sleep function.

nrf_serial_flush only keeping calling this sleep function until the serial queue is being handled in the background (in the uart interrupt) or the timeout happens. It does not brute force a flush as the name suggests.

[quote user=""]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? [/quote]

nrf_serial_flush is a synchronous cal which does not return with NRF_SUCCESS until the transmit queue is empty. So you can check the return value of nrf_serial_flush and toggle the pin.