Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Hi all,

I'm facing an issue communicating with a UART-based sensor on the NRF52DK (52832).

I've followed the serial_port example and using various forum topics I've got to the point where I can exchange and read data from the sensor using the serial_port methods in IRQ mode. There are 2 issues that come up:

1. If I put "NULL" for the "timeout in ms" parameter in nrf_serial_read() , it seems that the sensor is not able to respond fast enough for my program to receive the transmission and thus I get the NRF_ERROR_TIMEOUT. When NRF_ERROR_TIMEOUT is returned, I  If I do increase the timeout parameter to, say, 1000 ms, the data transmission happens as expected. The problem then, however, is that eventually this might lead to a deadlock. What is the work around to this?

2. How can I decide the size of the read data, if I don't know it until I see what the sensor returns? For example, depending whether the sensor received a command successfully it can return an ACK or NACK with an error code and the size of those transmissions is different. If I put in a larger size of the expected transmission than is actually transmitted, I run into the NRF_ERROR_TIMEOUT again. It seems like there is no way to do that without handling this within the RX event handler, is that correct? What is the best way to handle it?

3. This is not an issue, but it might become later. I'm not completely clear on whether the queues get automatically cleared or not after the RX/TX is done. If not, how can I clear them for RX/TX?

Thanks in advance!

Parents
  • 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

Reply
  • 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

Children
No Data
Related