• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 124 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289546
Options

fstorage writes to incorrect address when SD s140 is enabled

user116413

In our code, we wish to store some data in flash via fstorage API. For this project we use
SDK 17.1.0 and the following (reduced) sample code

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
.evt_handler = fstorage_evt_handler,
.start_addr = 0xff000,
.end_addr = 0xfffff,
};

static void write_word(uint32_t address, uint32_t data)
{
ret_code_t rc;
rc = nrf_fstorage_write(&fstorage, address, &data, sizeof(data), NULL);
APP_ERROR_CHECK(rc);
}

write_word(0xFF004, 0x55339977); wait_for_flash_ready();
write_word(0xFF000, 0xDDDDAAAA); wait_for_flash_ready();
write_word(0xFF008, 0xEEEEBBBB); wait_for_flash_ready();
write_word(0xFF00C, 0xAAAAEEEE); wait_for_flash_ready();
write_word(0xFF010, 0xCCCCBBBB); wait_for_flash_ready();
write_word(0xFF014, 0xAAAAEEEE); wait_for_flash_ready();

Early on, the following is called
ret_code_t rc;
rc = nrf_fstorage_init(&fstorage, &nrf_fstorage_sd, NULL);
APP_ERROR_CHECK(rc);

Expected is data written to flash address 0xFF000 and above
actual data seems to be written to 0x4xxxx instead of 0xFxxxx

The patterns are not found elsewhere on flash!

./nrfjprog -f nrf52 --memrd 0x4F600 --n 128
0x0004F600: 22014B15 480621F7 FFB6F7F4 FE8CF7FF |.K.".!.H........|
0x0004F610: BF00E79D 20016890 A55A5AA5 000617D4 |.....h. .ZZ.....|
0x0004F620: 00061694 55339977 0009F004 DDDDAAAA |....w.3U........|
0x0004F630: EEEEBBBB 0009F008 AAAAEEEE 0009F00C |................|
0x0004F640: CCCCBBBB 0009F010 0009F014 00061778 |............x...|
0x0004F650: 00061710 00061798 000617B4 B083B500 |................|
0x0004F660: F8AD2300 F8AD3004 00403000 0001F040 |.#...0...0@.@...|
0x0004F670: 0004F88D 46692202 F002A801 F89DFBB1 |....."iF........|


Also it appears that DDDDAAAA is written after 55339977. When running the software
without the softdevice and direct flash access via nrf_nvmc_write_word() the correct
location is used

Is there something obvious that we fail to see ?

  • 0

    Hi,

    Have you verified that the patterns you read from 0x4F600 are written by the fstorage library, and that this is not just part of the application firmware written to flash? Since the data is static, it will be part of the firmware and stored in flash when you flash the firmware.

    Do you use the default implementation of wait_for_flash_ready() from the flash_fstorage example? Have you verified that this function returns and that the code can continue with the rest of the fstorage calls? If you have the softdevice enabled along with BLE activity, the flash writes may not suceeed if your BLE activity prevents the softdevice scheduler to fit it between the events. See SoftDevice timing-activities and priorities and Flash memory API.

    Best regards,
    Jørgen

  • 0 in reply to user14926

    Hmm, you are correct. When all is good, the 'pattern' should show up at two locations when the flash is dump:ed

    Silly me and thanks for bringing that to my attention.

    Yes, I have used the default implementation of wait_for_flash_ready() aswell as 'my own'. Will focus some more on this !

    but I do get:

    | ¦ ┆ case NRF_FSTORAGE_EVT_WRITE_RESULT:
    | ¦ ┆ {
    | ¦ ┆ ┊ | LOG_INFO("--> Event received: wrote %d bytes at address 0x%x.",
    | ¦ ┆ ┊ | ¦ ┆ ┊ | ¦ ┆ ┊p_evt->len, p_evt->addr);

    MAX retries is set at default 8 and should be plenty, given that BLE is not connected nor broadcasting

    I am sure the fault lies with us, but I just don't see it (yet)

    As a test, I changed location and found in the hex dump

    :020000040009F1
    :10F0000083F4040083F4040083F4040083F4040014
    :08F0100083F4040083F4040002

    So something seems to get written, but not the correct data. I have verified that correct data is handed over to the softdevice, but I understand I need to dig deeper here

    Thanks for getting me back on track and away from the above mistake!

  • 0 in reply to user14926

    For very very unclear reasons, it seems to work today

    The thing is, I don't recall doing any permanent changes. I did some testing with the number of retries and the queue size but then reverted. I did add a new erase flash 'flow' and added Result to the event printout (for debugging purpose)

    Peculiar, but I am happy for now

Related
Terms of service