UARTE: uart_fifo_read() - 4th byte always 0x00

[Brett]

Hi,

I am not sure where to go next, so looking for some debug help.

Setup:
I am using the 9160DK - the 52840 is being used as an ANT+ receiver, where it forwards on UARTE to 9160.

I have taken the code back to the basics, where I send 8 bytes containing 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 from the 52840 to the 9160, of which I receive the following on the 9160:

01 02 00 00 05 06 07 08
01 02 00 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 00 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 03 00 05 06 07 08
01 02 03 00 05 06 07 08

As can be seen from above, the 4th byte is always 0x00 and the 3rd byte is occasionally 0x00 - and I cant work out why. 

52840:

I am using nrf_libuarte_async_tx to send the 8 bytes - which appears to be working - as I can see most bytes correctly on the 9160.

9160:

in uart_cb():

while (true)

{

  data_length = uart_fifo_read(x, &uart_buf, 1);

  if (data_length != 1) { 

    printk("\n");

    break;

  }

  printk("%02X ", uart_buf);

}

Other:
* Both devices are set for, 115200 and HW-FC Off (or not set).



Before attaching my entire project here, is there anything obvious that could cause this to happen ?  And, any ideas on the best way to debug this ?

regards

-brett

[Kenneth]

Can you try to set all uart buffers (on both peers) to 'static volatile' to ensure they are not reused for other purposes by the compiler?

If that does not help, do you have access to a logic analyzer so you can look at the serial data, just to confirm if it's indeed nRF52840 or nRF9160 that is the problem here?

Kenenth

[Brett]

The 'static volatile'  didnt make any difference - same issue.

I have just ordered a logic analyzer, so I will get back to you in a few days.  i will keep testing other things, and if it magically starts works, I will update this case.

regards
-brett

[Brett]

Hi Keneth,

I have it working, but not sure really why, hoping you can clarify something.

In the original code, after the async_tx call, 

err_code = nrf_libuarte_async_tx(&libuarte, (uint8_t *)p_page_data, page_size );

I have a free call, too free from the malloc.

free(p_page_data);

Q: Could this free happen before the data is completed on the UART ?

Why I ask this is because if I add the following delay between the tx and free - it all works and I dont miss any random packets.

nrf_delay_ms(1);

Fails:

err_code = nrf_libuarte_async_tx(&libuarte, (uint8_t *)p_page_data, page_size );
NRF_LOG_INFO("return nrf_libuarte_async_tx : %d", err_code);
APP_ERROR_CHECK(err_code);
free(p_page_data);

Works:

err_code = nrf_libuarte_async_tx(&libuarte, (uint8_t *)p_page_data, page_size );
NRF_LOG_INFO("return nrf_libuarte_async_tx : %d", err_code);
APP_ERROR_CHECK(err_code);
nrf_delay_ms(1);
free(p_page_data);

The confusing part to me is, its always the 4th (occasionally the 3rd) packet that gets dropped, maybe thats due to timing?

regards
-brett

[Kenneth]

Brett said:

free(p_page_data);

Q: Could this free happen before the data is completed on the UART ?

Yes, since the nrf_libuarte_async_tx() occurs asynchronous (non-blocking).

Kenneth

[Georgiy Lutsenko]

Hi all
I had a similar issue.
I am using 9160 and see the same problems with UART.
I checked the sent data from another device with an analyzer. (The data is correct).
But there is a problem on the 9160 side.
For receiving and sending I use interrupts:

static void DtRS485_uartCallback(const struct device *pDev, void *user_data)

{

    uart_irq_update(pDev);

    if (uart_irq_rx_ready(pDev)) {

       uint8_t data_length = 0;

       data_length = uart_fifo_read(pDev, uartBuf, sizeof(uartBuf));

       if (spRxFifo != NULL) {

            if (data_length > 0) {

                DtFIFO_pushBuffer(spRxFifo, uartBuf, data_length);

             }

        }

    }

    if (uart_irq_tx_ready(skpUart)) {

        uint16_t size = DtFIFO_availableForRead(spTxFifo);

        if (size > 0) {

            DtGPIO_pinSet(DIR_RS485, true);

            DtFIFO_popBuffer(spTxFifo, sBufTX, size);

           uart_fifo_fill(pDev, sBufTX, size);

         }

        if (uart_irq_tx_complete(skpUart)) {

          uart_irq_tx_disable(skpUart);

          DtGPIO_pinSet(DIR_RS485, false);

        }

    }

}

What is the UART interrupt priority?

Thanks. 

Best regards,

Georgiy

[Brett]

Hi Kenneth,

I can open a new issue if required, but I am still working on the same problem - maybe.

Do you have a link or video that I can review which shows how to connect a logic analyser onto the nrf9160dk, so that I can monitor between the 52840 and 9160 chips.

All runs fine for about 10 minutes and then I get all 0x00's on the 9160 and I am not sure if its the 52840 or the 9160.  For some reason debug on the 52840 is not working the way I need it to, and its hard to see where the problem is.

regards
-brett

[Kenneth]

Brett said:

Do you have a link or video that I can review which shows how to connect a logic analyser onto the nrf9160dk, so that I can monitor between the 52840 and 9160 chips.

You should only need to connect GND to common ground between DK's. Then connect the RXD and TXD pins to two input pins of the logic analyzer, then start tracing from the logic analyzer, if you set the baudrate in the logic analyzer you should be able to observe the data on byte level.

Kenneth