Pstorage Allocating More Flash Pages Moves Existing Pages

RE: Pstorage Allocating More Flash Pages Moves Existing Pages

Lucas — Thu, 12 Nov 2015 16:40:51 GMT

In dfu_types.h I have defined

#define DFU_APP_DATA_RESERVED 0x0800

The bond_table and persistent_settings are meant to be preserved and this currently works. Declaring them last will this method of preserving the pages still work. I guess the DFU preserves the tables in the reverse order that they are allocated.

RE: Pstorage Allocating More Flash Pages Moves Existing Pages

John — Thu, 12 Nov 2015 16:05:20 GMT

No problem, yours filled in more of the details than mine so no harm no foul.

RE: Pstorage Allocating More Flash Pages Moves Existing Pages

Vidar Berg — Thu, 12 Nov 2015 15:30:52 GMT

Didn't see your answer before after I posted mine. Had left this thread open in a different tab and didn't refresh it before I posted:)

RE: Pstorage Allocating More Flash Pages Moves Existing Pages

Vidar Berg — Thu, 12 Nov 2015 15:17:12 GMT

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.

RE: Pstorage Allocating More Flash Pages Moves Existing Pages

John — Thu, 12 Nov 2015 13:34:49 GMT

Yes, changing the number of pstorage pages will change the start address of your allocated pstorage memory. If you look in pstorage_platform.h you can see how the start address of the pstorage memory is allocated base on the number of pages. So, when you do your pstorage_register during initialization you will end up with a different pstorage location. You could probably get back to your data location if you allocate the additional 8 pages before registering for your previous pstorage data. I have never tried that, so it is just a guess.