Serial timeout issues with nrf_serial_read() and nrf_serial_write() with nrf_serial_mode_irq.

RE: Serial timeout issues with nrf_serial_read() and nrf_serial_write() with nrf_serial_mode_irq.

nikostpn — Wed, 29 Jan 2020 15:45:46 GMT

Jørgen,

Thank you so much, this is helpful!

RE: Serial timeout issues with nrf_serial_read() and nrf_serial_write() with nrf_serial_mode_irq.

Jørgen Holmefjord — Wed, 29 Jan 2020 15:05:50 GMT

I requested to convert the ticket to public space, you need to accept it before it is converted.

1. This section refers to calling the APIs from interrupt context of other peripherals, it does not refer to the IRQ mode used in the nrf_serial library. I'm not sure how the library implements support for timeout=0. To me, it looks like this will generate a TIMEOUT error immediately, but I can have overlooked something in the code.

2. I would recommend that you filter this error before passing the error code to APP_ERROR_CHECK() macro, for instance like this:

uint32_t read_bytes = 0;
ret_code_t err_code = nrf_serial_read(&serial_uart, &c, sizeof(c), &read_bytes, 1000);

if(err_code == NRF_ERROR_TIMEOUT)
{
    if(read_bytes > 0)
    {
        //Process received data
    }
    else
    {
        //Try read again
    }
}
else
{
    APP_ERROR_CHECK(err_code);
}

RE: Serial timeout issues with nrf_serial_read() and nrf_serial_write() with nrf_serial_mode_irq.

nikostpn — Tue, 28 Jan 2020 19:32:52 GMT

Hi Jørgen,

First of all, I can make this question public, but I actually posted another question which has the same content, essentially, because I only got one notification when I was editing this post yesterday that it is under review and no further indications of what is happening to it, so I thought it got deleted. I think your answers are a bit more direct than the other engineer's answers to the question and I would like to make this answer available to others too. What is the best way of going about that?

Now, onto the actual questions:

1. Oh, alright. I thought that in the documentation that is what was stated:

"Do not use synchronous API (timeout_ms parameter > 0) in IRQ context. It may lead to a deadlock because the timeout interrupt cannot preempt the current IRQ context."

2. That makes sense. Would I ignore the TIMEOUT error within the weak_error file or when the actual program runs without the debugger it doesn't actually switch to NRF_BREAKPOINT?

3. That makes sense, thank you.

Thank you so much!

RE: Serial timeout issues with nrf_serial_read() and nrf_serial_write() with nrf_serial_mode_irq.

Jørgen Holmefjord — Tue, 28 Jan 2020 16:13:56 GMT

Hi,

1. If you put NULL, the timeout will expire immediately, causing the TIMEOUT error that you see. This is expected. How can increasing the timeout parameter lead to a deadlock?

2. The p_read parameter will indicate the number of received bytes. The NRF_ERROR_TIMEOUT error can be ignored if this is expected in your application. Setting the SERIAL_BUFF_RX_SIZE parameter to 1 will configure the UART(E) peripheral to receive a single byte at a time and place this into the FIFO, making sure you do not miss any data. However, if you have many other high priority tasks that need to be handled in your application, this may block the serial library from updating the buffer pointer fast enough. An alternative can be to use the async libUARTE library, which implements reliable communication over UART.

3. The serial_rx/serial_tx functions will pull the data out of the queues. You can call the functions nrf_serial_flush()/nrf_serial_rx_drain() to force this.

Best regards,
Jørgen