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

nrf_fstorage_erase return NRF_SUCCESS, but doesn't erase memory.

Hello,


I'm on nrf52DK PCA10040, SDK15.2

I'm sure it's quite basic, but I don't get it. I just need to write actually two uint32_t value in flash memory (so FLASH_DATA_LENGHT =2). For it, I use the last page of my device:

void flash_init()
{
  ret_code_t rc;
  nrf_fstorage_api_t * p_fs_api;
  p_fs_api = &nrf_fstorage_sd;
  fstorage.start_addr=nrf5_flash_end_addr_get()-PSTORAGE_FLASH_PAGE_SIZE ;
  fstorage.end_addr=nrf5_flash_end_addr_get();
  rc = nrf_fstorage_init(&fstorage, p_fs_api, NULL);
    APP_ERROR_CHECK(rc);
}

then I made a write_function:

void flash_save()
{
  ret_code_t rc = nrf_fstorage_erase(&fstorage, fstorage.start_addr, 1, NULL); //just one page to erase
      if (rc != NRF_SUCCESS)
    {
        NRF_LOG_INFO("nrf_fstorage_erase() returned: %s",
                        nrf_strerror_get(rc));
    }
  wait_for_flash_ready(&fstorage);
  nrf_fstorage_write(&fstorage,fstorage.start_addr, flash_data, FLASH_DATA_LENGHT*sizeof(uint32_t), NULL);
  wait_for_flash_ready(&fstorage);
}

I don't think it's necessary to wait for flash to be ready, mainly for the flash erase, but anyway.
And at last, to be exhaustive, I made a read function

void flash_load()
{
  nrf_fstorage_read(&fstorage,fstorage.start_addr, flash_data, FLASH_DATA_LENGHT*sizeof(uint32_t));
}

Ok, so I guess, it's everything for now. My problem, is nrf_fstorage_erase seems to not erase the flash page. I still only can read the very first value I wrote on the board (and it's working very well).  nrf_fstorage_erase returns a great NRF_SUCCESS. But When I read the flash memroy after a write operation, it's still the very first value I wrote. So no error, just not working.
By the way, I'm using softdevice, but I really don't think it interferes, and my test are with no connected device (it still very normally advertising).

  • Hi,

    From what you write, I do not see any references to the NRF_FSTORAGE_EVT_ERASE_RESULT event. The fstorage API is asynchronous, so the flash is not erased immediately. You have to wait for the event before you can assume that the flash is erased. You can refer to the Flash Storage Example to see how it is done there.

  • Thank you for your answer. I was creating my really simple" exemple (I'd love to see suche simple example on your sdk), based on this very complicated (but very acomplished) exemple.
    In it, I don't see anywhere "NRF_FSTORAGE_EVT_ERASE_RESULT ", nor in cli.c, neither in main.c, in this project.

    Also, async, doesn't mean out of any order. So it should erase first, and write then, even if the flash is not erased yet while asking itto write something. And It shouldn't take minutesto be done, does it? Also I thought async meaned buffered (keep a virtual copy in ram, while not written in flash). Sad it's not.
    At last, In your great example, I found "wait_for_flash_ready(&fstorage);", which I guess was waiting for ram to not be busy anymore. So after my erase, and this function, flash should have been erased, doesn't it?
    So, my project should work, doesn't it?

    void wait_for_flash_ready(nrf_fstorage_t const * p_fstorage)
    {
        /* While fstorage is busy, sleep and wait for an event. */
        while (nrf_fstorage_is_busy(p_fstorage))
        {
            power_manage();
        }
    }

  • Hi,

    It should not take minutes, no. And queued operations are handled in order. I would expect your calls to wait_for_flash_ready() to be enough, but it is difficult to say more without seeing you complete code. In any case waiting for NRF_FSTORAGE_EVT_ERASE_RESULT should solve it. You can see it used in line 185 of <SDK 15.2>\examples\peripheral\flash_fstorage\main.c.

    Regarding writes note being buffered that is correct, and described in the API documentation. From my perspective that makes sense in this basic flash write functionality, as that gives you better performance. You can always implement buffering yourself if you need it.

  • I dont think we have the same <nRF5_SDK_15.2.0_9412b96>, as on mine, in  the main.c file, this full word :NRF_FSTORAGE_EVT_ERASE_RESULT  doesn't appear. Neither "write" in a useful contexte, nor "erase". These are called in cli.c, youpidou
    Cli define "erase" word as thing to do, by calling erase_cmd()
    erase_cmd() in short is "fstorage_erase(p_cli, addr, pages_cnt);"
    fstorage_erase() in short is  nrf_fstorage_erase(&fstorage, addr, pages_cnt, NULL);
    No wait, no care.

    Please, I'm sure I'm wrong, but I do my best, so please tell me which line to check Slight smile

    About the buffering thing, I understand, and I don't really care for this project (I must write few octet every few bytes, every few days). I was just misunderstanding it.

    About how I call it, this is my very boring main file function: https://pastebin.com/cqbidUq5 You can see at it's end me trying to write memory, load memory and checking what value I can get next. Result: any of this values, but the one I flashed long time ago.
     
    About my  sdk_config, you can check it here: https://pastebin.com/8yNtJyxQ
    I tryed to copy is as well as I could from the example you told me.

    If you need any more information to help me, I'll be glad to tell you. I'm also happy to see my function in your opinion should work.



  • Hi,

    It is there in the unmodified SDK, so I expect you will see NRF_FSTORAGE_EVT_ERASE_RESULT in \examples\peripheral\flash_fstorage\main.c if you extract a fresh copy SDK 15.2 (it is only used to log that the erase has completed, though). But in any case your call to wait_for_flash_ready() should be enough as well, so I am still missing the complete picture. Can you explain exactly at what point you erase the code and expect it to be erased when you read it? Perhaps you can upload all your code in a coherent package so that we can see if there is some other issue that could explain this behaviour? (note that you can upload files and code snippets here, you do not need to use an external site for hosting it).

Related