This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Losing Bonding and FDS info on DFU

Running 52840 with SDK 15.3, SD140 on SES Ive got an application that has a bootloader on it running DFU.  Everything works during DFU correctly but when I get into the application (same SDK version), I've lost my bonding and other FDS information. 

Application is operating peripheral only, non-bonded DFU.  The application itself uses peer manager with whitelists and storing bonding information.

There are several tickets running around here from other SDK versions on the subject and I'm not finding anything that is helping here. 

In the nrf_dfu_types.h file I've got the DFU_APP_DATA_RESERVED set at default of 3 pages which is what the FDS is set at as well so this should match up.

Maybe there is some other setting to turn on saving the area at all that isn't?

Thanks

Parents
  • Hello,

    The bootloader should not be able to write into the application data as long as the NRF_DFU_APP_DATA_AREA_SIZE setting in your bootloader's sdk_config file corresponds to the size of your FDS area allocated by the app. So please double-check that  NRF_DFU_APP_DATA_AREA_SIZE  is indeed set to 12288 in your bootloader project. 

    I see you mentioned using the DFU_APP_DATA_RESERVED define, but please note that this symbol was renamed to NRF_DFU_APP_DATA_AREA_SIZE  in this SDK version.

    Best regards,

    Vidar

  • Theory: Because the bootloader isn't requiring bonding, the peer manager is deleting what bonding info it has here so when my application comes back online, there is no bonding info saved.  Is it possible that the bootloader isn't erasing the are but that other things are deleting what's there because it doesn't need it?

  • The peer manager should only delete bonding information when the application explitely requests it through pm_peer_data_delete()/pm_peers_delete(), or if you have run out of FDS space and call pm_handler_flash_clean()/pm_handler_flash_clean_on_return().

    I initally assumed that pm_init() failed after DFU because that's usally what happens if the bootloader has corrupted the filesystem. Is that not what happens in your case?

  • I don't think it's failing.... Looking at the code, it should hang if it does and I'm not seeing hangs.  I'll have to verify that when next I can run a debugger there but I'm pretty sure it isn't.

Reply Children
No Data
Related