• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 973 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301332
Options

Peer Manager - FDS memory collapse

User1321

Good day Noric Team, 

I am using the SDK16 with softdevice 140. I use the fds library to save configuration information in the nrf52840 together with the peer_manager enabled. 

I have a strange behaciour that leads me to think that is a memory issue: when writing new config data into the flash, application get stucked and the last messagew shown in the debugger is :

<info> peer_manager_handler: Peer data updated in flash: peer_id: 8192, data_id: Invalid Role, action: Update

Even thought there is not action in the peer_manager. So really my question is, how can i guaranteed that the memories don'T get messed up?

In the app_config I have:

#define FDS_VIRTUAL_PAGES 13   // configuration required by application

#define FDS_VIRTUAL_PAGE_SIZE 1024

#define FDS_VIRTUAL_PAGES_RESERVED 3 // Since i believed this could be used by the peer_manager

Is there any obvious error that I'm making? 

How can i guaranteed that each module has it's proper space in the flash?

Thank you in advance! 

Parents
  • 0

    Hi,

    Let me first comment on this:

    #define FDS_VIRTUAL_PAGES_RESERVED 3 // Since i believed this could be used by the peer_manager

    This reserves 3 paged on top of your flash (or right below the bootloader if using that), which are not used by FDS. But this is not used by the peer manager either (which use FDS). It is simply reserved so that you can use it for something else. The peer manager also use FDS, and there is no separation between the different FDS "users". So your application data and the peer manager data will have to share in the 13 pages you have set aside. So based on wha tyou write here FDS use 13 pages (for everything), and you have 3 paged which is reserved but not used.

    Even thought there is not action in the peer_manager. So really my question is, how can i guaranteed that the memories don'T get messed up?

    The flash  memory should normally never get corrupted, and FDS is quite robust. The question is what happened here. Do you have any code in your application that writes to flash directly? Could that have corrupted some FDS data? Or could it be that you have performed a DFU update and have not reserved all of the FDS pages in the bootloader (by setting NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h correctly)? Or there could be something else. To find out, it would be interesting to know how/when this happened and how often it happened? If you do a full flash dump of the failing device (nrfjprog --memrd 0 --n 0x100000 > flash_dump.txt), what do you see? What is the address where this record is stored and what do we see in the flash dump around that address?

Reply
  • 0

    Hi,

    Let me first comment on this:

    #define FDS_VIRTUAL_PAGES_RESERVED 3 // Since i believed this could be used by the peer_manager

    This reserves 3 paged on top of your flash (or right below the bootloader if using that), which are not used by FDS. But this is not used by the peer manager either (which use FDS). It is simply reserved so that you can use it for something else. The peer manager also use FDS, and there is no separation between the different FDS "users". So your application data and the peer manager data will have to share in the 13 pages you have set aside. So based on wha tyou write here FDS use 13 pages (for everything), and you have 3 paged which is reserved but not used.

    Even thought there is not action in the peer_manager. So really my question is, how can i guaranteed that the memories don'T get messed up?

    The flash  memory should normally never get corrupted, and FDS is quite robust. The question is what happened here. Do you have any code in your application that writes to flash directly? Could that have corrupted some FDS data? Or could it be that you have performed a DFU update and have not reserved all of the FDS pages in the bootloader (by setting NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h correctly)? Or there could be something else. To find out, it would be interesting to know how/when this happened and how often it happened? If you do a full flash dump of the failing device (nrfjprog --memrd 0 --n 0x100000 > flash_dump.txt), what do you see? What is the address where this record is stored and what do we see in the flash dump around that address?

Children
Related
Terms of service