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

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


  • 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

  • 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

  • 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

  • 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



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



Children
No Data
Related