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

Pstorage Allocating More Flash Pages Moves Existing Pages

Hello,

Setup: SDK 9.0 SD 8.0.0

I have an application where we are using Pstorage to store persistent system settings.

When I flashed the device we were using this setting in pstorage_platform.h #define PSTORAGE_NUM_OF_PAGES (2) Everything worked great. I was able to perform DFU update of the same firmware version and settings were preserved.

However, in a later version of firmware I performed a DFU update and changed the number of pstorage pages to this: #define PSTORAGE_NUM_OF_PAGES (10)

It seems that the original location of the orininal settings changes because all of them were lost. Did the change the PSTORAGE_NUM_OF_PAGES somehow change where the pages are stored in memory. I did not add any additional storage. Just changed the number of pages and this was result.

Lucas

Parents
  • Hi, the pstorage instance registered first will be placed at the bottom of the allocated flash area. That is, bootloader address - swap page - (PSTORAGE_NUM_OF_PAGES*1024 bytes). This is also illustrated here pstorage -> memory layout. So assuming the default bootloader address the new bond table will be placed at 0x39400 after doing DFU, instead of 0x3B400 where it was initially located. As a result the old bond information will no longer be visible for the device manager in the new application.

    The bond table takes typically one page with the default settings (max 8 bonds, etc.)If you need these additional pages for the application data, you can solve this by registering these instances before initializing the device manager.

Reply
  • Hi, the pstorage instance registered first will be placed at the bottom of the allocated flash area. That is, bootloader address - swap page - (PSTORAGE_NUM_OF_PAGES*1024 bytes). This is also illustrated here pstorage -> memory layout. So assuming the default bootloader address the new bond table will be placed at 0x39400 after doing DFU, instead of 0x3B400 where it was initially located. As a result the old bond information will no longer be visible for the device manager in the new application.

    The bond table takes typically one page with the default settings (max 8 bonds, etc.)If you need these additional pages for the application data, you can solve this by registering these instances before initializing the device manager.

Children
No Data
Related