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

why flash memory pstorage_module pages are not contiguous

I have two p_storage_param modules param and param2. param would store 3 blocks of 16 bytes and param2 would store 10240 bytes (10 pages). I called pstorage_register (param2 first then pstorage_register (param in order to put param data next to bootlader (to preserve data after DFU) according to this answer. after reading flash memory content I found that param2 pages are not contigneous (param data page is located between two param2 pages). what should I do to to set all param2 pages on contigous way and especilaly to put param next to bootlader (after swap page) in order to keep those data after DFU. I configured #define DFU_APP_DATA_RESERVED 0xC00 which woould save 3 pages after DFU. please check the flash memory dump file (param2 data are 0xXX 0XXX 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF )

what I found bad is that modules pages locations are unpredictable (sometimes it stores on second page, sometimes one third) how can fix modules pages location to know the amount of data to keep after DFU

pstorage_module_param_t param; pstorage_module_param_t param2;

param.block_size    = 16;
param.block_count   = 3;
param.cb            = flash_callback_handler;

param2.block_size    = 256; // data are in uint16_t (step and slope)
param2.block_count   = (10240/ 256); // max data to save is 10KB
param2.cb            = flash_callback_handler;

err_code = pstorage_init();
APP_ERROR_CHECK(err_code);

err_code = pstorage_register(&param2, &steps_store_flash_handler);
APP_ERROR_CHECK(err_code);

err_code = pstorage_register(&param, flash_handler);
APP_ERROR_CHECK(err_code);
Parents
  • What RK is saying here is correct. The first registered pstorage instance will be allocated to the lowest allocated page address. The next registered instance will then be placed on top of the first block(s), and so on. The handles won't change unless you change the order you register them or if change the PSTORAGE_NUM_OF_PAGES in pstorage config.

    With that said, it is important to note that the pstorage data is not being erased when you re-program the application FW (default setting). This may cause confusion while debugging if one is not aware of it.

  • you should entirely ignore whatever is written to the swap page, it's a swap page, used for storing temporary data while the original page is being cleared.

    The param data page is not located between two param2 pages. It cannot be, it's not set up that way, the pages are not allocated that way, so unless you

    a) are using pstorage incorrectly, mixing up handles and writing to the wrong piece of memory b) are seeing old data from previous runs sitting in memory after you've increased the number of pages used by pstorage, leaving the old pages with random garbage in them c) are confusing yourself looking at the swap page

    the hypothesis in your original question is wrong.

Reply
  • you should entirely ignore whatever is written to the swap page, it's a swap page, used for storing temporary data while the original page is being cleared.

    The param data page is not located between two param2 pages. It cannot be, it's not set up that way, the pages are not allocated that way, so unless you

    a) are using pstorage incorrectly, mixing up handles and writing to the wrong piece of memory b) are seeing old data from previous runs sitting in memory after you've increased the number of pages used by pstorage, leaving the old pages with random garbage in them c) are confusing yourself looking at the swap page

    the hypothesis in your original question is wrong.

Children
No Data
Related