This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Atomic FIFO bug report - calling nrf_atfifo_alloc_put twice in a row truncates data in atfifo buffer

I´m running on NRF52840 with SDK version 15.2.0 and trying to use atfifo, and I have observed a bug when writing to the atfifo buffer twice and then reading from the atfifo buffer.

The phenomenon:

1. I´m writing 4 bytes to atfifo but first 3 bytes contains 0.

2. I´m writing many other bytes to atfifo.

3. I´m reading 4 bytes from atfifo but it contains data from both previous writes. The atfifo buffer seems to have been truncated.

I´m running following experimental code deriving from blinky example project on PCA10056:

#define DATA_BUFFER_SIZE 16384
NRF_ATFIFO_DEF(m_data_atfifo, uint8_t, DATA_BUFFER_SIZE);

/**
 * @brief Function for application main entry.
 */
int main(void)
{
    /* Configure board. */
    bsp_board_init(BSP_INIT_LEDS);
   
    NRF_ATFIFO_INIT(m_data_atfifo);

    uint32_t data_size = 169;
    uint8_t data[169];
    data[0] = 0x01;
    data[1] = 0x02;
    data[2] = 0x03;

    nrf_atfifo_alloc_put(m_data_atfifo, &data_size, sizeof(data_size), NULL);
    nrf_atfifo_alloc_put(m_data_atfifo, data, data_size, NULL);

    uint32_t get_size = 0;
    nrf_atfifo_get_free(m_data_atfifo, &get_size, sizeof(get_size), NULL);
    NRF_LOG_INFO("1. get_size: %x", get_size);

    nrf_atfifo_clear(m_data_atfifo);


    nrf_atfifo_alloc_put(m_data_atfifo, &data_size, sizeof(data_size), NULL);
    nrf_atfifo_get_free(m_data_atfifo, &get_size, sizeof(get_size), NULL);
    nrf_atfifo_alloc_put(m_data_atfifo, data, data_size, NULL);
    NRF_LOG_INFO("2. get_size: %x", get_size);

    /* Toggle LEDs. */
    while (true)
    {
        for (int i = 0; i < LEDS_NUMBER; i++)
        {
            bsp_board_led_invert(i);
            nrf_delay_ms(500);
        }
    }
}

My opinion is that get_size should contain same data 0x000000A9 in both printouts, but it´s not. In the first printout get_size contains 0x30201A9, while in second printout it contains 0x000000A9.

  • Hello,

    I changed the order of nrf_atfifo_alloc_put(m_data_atfifo, data, data_size, NULL) and nrf_atfifo_alloc_put(m_data_atfifo, data, data_size, NULL) at the end, and then got 30201A9 in both cases.

    I changed the code to this

        nrf_atfifo_alloc_put(m_data_atfifo, &data_size, sizeof(data_size), NULL);
        nrf_atfifo_alloc_put(m_data_atfifo, data, data_size, NULL);
    
        uint32_t get_size = 0;
        nrf_atfifo_get_free(m_data_atfifo, &get_size, sizeof(get_size), NULL);
        NRF_LOG_INFO("1. get_size: %x", get_size);
    
        nrf_atfifo_clear(m_data_atfifo);
    
    
        nrf_atfifo_alloc_put(m_data_atfifo, &data_size, sizeof(data_size), NULL);
        nrf_atfifo_alloc_put(m_data_atfifo, data, data_size, NULL);
        nrf_atfifo_get_free(m_data_atfifo, &get_size, sizeof(get_size), NULL);
        NRF_LOG_INFO("2. get_size: %x", get_size);

    If you do it in this order get_size will be the same in both cases.

  • Well that doesn´t surprise me.

    I intentionally wrote those two examples because write-read-write and write-write-read should end up in same result if it is a FIFO.

    Moreover, if the first element I write to the FIFO is 0x000000A9 4 bytes, then I will and should expect getting same value back when reading 4 bytes from the FIFO.

    And I would like to know why this is happening too.

  • Hi,

    How is it going with this issue? Is it perhaps delayed because of summer vacation?

  • It's possible. In any case, it has been reported so we just need to wait.

Related