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

Can't correctly restore data stored with FDS

Hello,

I am using FDS to store three int32_t numbers.

Here is my code for storing :

static void store(void)
{
    int32_t value_A = get_value_A();
    int32_t value_B = get_value_B();
    int32_t value_C = get_value_C();
    int32_t values[3] = { value_A, value_B, value_C };

    NRF_LOG_INFO("Size %d", sizeof(values)/sizeof(int32_t));

    fds_record_t record;
    record.file_id           = FILE_ID;
    record.key               = RECORD_KEY;
    record.data.p_data       = values;
    record.data.length_words = 3;

    ret_code_t err_code;
    err_code = fds_record_write(&record_desc, &record);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_INFO("Stored value A %d", value_A);
    NRF_LOG_INFO("Stored value B %d", value_B);
    NRF_LOG_INFO("Stored value C %d", value_C);

    read_values();
}

Here is my code for reading :

static bool read_values(void)
{
    memset(&ftok, 0x00, sizeof(fds_find_token_t));
    fds_flash_record_t flash_record;
    fds_record_desc_t record_desc;

    while (fds_record_find(FILE_ID, RECORD_KEY, &record_desc, &ftok) == NRF_SUCCESS)
    {
        if (fds_record_open(&record_desc, &flash_record) != NRF_SUCCESS)
        {
            return false;
        }

        const int32_t* values = flash_record.p_data;

        int32_t value_A = values[0];
        NRF_LOG_INFO("Read value_A %d", value_A);

        int32_t value_B = values[1];
        NRF_LOG_INFO("Read value_C %d", value_B);

        int32_t value_C = values[2];
        NRF_LOG_INFO("Read value_C %d", value_C);

        if (fds_record_close(&record_desc) != NRF_SUCCESS)
        {
            /* Handle error. */
            return false;
        }

        return true;
    }
}

Here are the logs (stored values are the correct ones) : 

<info> app: Size 3
<info> app: Stored value A -11810
<info> app: Stored value B -5737
<info> app: Stored value C 200

<info> app: Read value A 536882505
<info> app: Read value B 72429
<info> app: Read value C 100360

What am I missing ? This *looks* like a uint <-> int conversion issue, but I never store nor read as uint ...

Thanks! Best regards

Parents
  • Hi,

    While it may look like a uint <-> int issue on the surface, the actual values are not correct for that to be the case.

    Please note that flash writing operations take a lot of time, and the API for writing FDS records is asynchronous. What happens when you call fds_record_write() is that the write operation gets queued, and you get the NRF_SUCCESS return value if the operation was successfully queued. The write operation itself is not finished until you get an event back that you can receive and handle through the FDS event handler.

    What this means in practice is that with your code excerpts you should expect to read out flash contents that has not yet been fully written, and/or based on the state of flash (and FDS records) from earlier. (The write has not yet happened when you read.)

    For one way to handle this asynchronousity, have a look at the Flash Data Storage Example.

    Regards,
    Terje

  • Hello,

    I have called read() just after for the sake of the example, but in my real code I read the values after restarting the PCB (to restore some configurations), and the issue is the same. So I don't think this is the problem here.

  • Hi,

    Right.

    Can you share the contents of the FDS area?
    You can dump the flash to a hex file using nrfjprog:

    nrfjprog --readcode --readuicr filename.hex

    That will show what is actually stored in flash. (If you cannot or do not want to share more than the FDS part of flash, then you need to manually remove the other parts from the hex file before sharing.)

    Regards,
    Terje

  • :1002E000920000F03DFB0028F6D00E2070BDFFF715
    :1002F000A2FF0028FAD1D4E901034FF0805100EBAE
    :10030000830208694D69684382420ED840F6F8704E
    :1003100005684FF010226D1C09D0056805EB8305B8
    :100320000B6949694B439D4203D9092070BD55694A
    :10033000F4E70168491C03D00068401C02D003E0C8

    FDS takes ranges 0x0002E000 -> 0x0002E007 and 0x0002F000 -> 0x0002F0C3

  • Hi,

    This is not the correct part of the hex file for the FDS area. If you cannot share the full file in public, then please create a private ticket here on DevZone, refer to this thread, and attach the full hex file. Then I can have a look at it in full confidentiality.

    Regards,
    Terje

Reply Children
Related