• State Verified Answer
  • Replies 6 replies
  • Subscribers 90 subscribers
  • Views 2623 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 228657
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

FDS for Peer Manager and Thread Not Playing Nicely only when App is Loaded by DFU - Multiprotocol Thread/BLE with SDK Thread 3.0.0 (SDK 15.3)

Rob C

I recently updated my multi-protocol (Thread FTD + BLE Peripheral Connectable) to use 'nRF5_SDK_for_Thread_and_Zigbee_3.0.0_d310e71'.  I had been previously using 'nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac' based on SDK v15.2, so I'm not making a major leap here.  Devices are currently running S140 v6.1.0.

I am able to run it successfully when programmed using a JLINK, however, when I program a device with DFU over BLE pm_init() fails with NRF_ERROR_INTERNAL. Comparing the memories for each case using nRF Connect Programmer suggests the DFU package is not respecting the boundaries of FStorage in the same way the JLINK does.

Programming with JLINK is scripted as follows:

nrfutil settings generate --family NRF52840 --application Output/Debug/Exe/NameOfProduct_USB840F_s140.hex --application-version 1 --application-version-string "$VERSION" --bootloader-version 1 --bl-settings-version 1 flasher_out/settings.hex
mergehex -m softdevice_here/s140_nrf52_6.1.0_softdevice.hex bootloader_here/bootloader.hex flasher_out/settings.hex -o flasher_out/sbc.hex
mergehex -m flasher_out/sbc.hex Output/Debug/Exe/NameOfProduct_USB840F_s140.hex -o flasher_out/packet.hex
nrfjprog --family nrf52 --eraseall
nrfjprog --family nrf52 --program flasher_out/packet.hex
nrfjprog --family nrf52 --reset

Generation of Signed Application package continues with the following script:

nrfutil pkg generate --application Output/Debug/Exe/LinePost_USB840F_s140.hex --application-version 1 --application-version-string "$VERSION" --hw-version 52 --sd-req 0xAE --key-file key_here/KeyDescription_private.pem flasher_out/fj\_USB840F\_ses\_$NAME\_$VERSION\_dfu.zip

(This file is used with nRFConnect Android to perform DFU)

I plan to use peer manager for caching GATT characteristics soon, so its important to me, however when I disable peer manager, I am able to DFU the new application without issue.  Thread is also using FStorage for network parameter storage.  I have been using peer manager and Thread fstorage for quite some time and never had these issues with DFU'ing new applications to fielded devices.  Can you help me understand how use of FSTORAGE and/or Peer Manager's use of FSTORAGE may have changed in this release?

Thanks!  --Rob

  • 0

    In retrospect, I think my statement "...suggests the DFU package is not respecting the boundaries of FStorage in the same way the JLINK does" is backwards.  When using JLINK, I am erasing the entire flash whereas DFU clearly can't do this.

    I guess to re-frame the question, if I have a fielded device already using FStorage for one purpose, and I want to deploy a new application using DFU that has new use of FStorage, what steps to I need to follow to ensure compatibility?

    - Rob

  • +1

    Hi Rob,

    Sorry for the delayed response. Please verify that the NRF_DFU_APP_DATA_AREA_SIZE define in sdk_config.h for the bootloader corresponds with the number of pages allocated to FDS/Fstorage in your app. This will prevent the DFU process from overwriting FDS data. FDS will not free a flash page that has an invalid page tag. 

  • 0 in reply to Vidar Berg

    Thanks Vidar!  I did have a mismatch.  In the bootloader project, sdk_config.h had NRF_DFU_APP_DATA_AREA_SIZE=12288 (0x3000).  The application was using 0x4000 of flash.

    I still need to understand a bit more about how how PM and Thread use flash to be sure I'm allocating the right amount.  I noticed that my application sdk_config also has FDS_VIRTUAL_PAGES_RESERVED 4, but its not clear to me whether this is where FDS usage begins or ends.

  • 0 in reply to Rob C

    Is it fair to say that for the use case as indicated by the original poster,

    The FLASH that is used by the application must be carved out identically in both the boot loader and the application AND that the following conditions must be satisfied:

    The symbol NRF_DFU_APP_DATA_AREA_SIZE must be defined in the boot loader build.
    The symbol FDS_VIRTUAL_PAGES_RESERVED must be defined in the application build.
    The number of bytes defined by both the symbols MUST BE THE SAME

  • 0 in reply to RVM

    @RMV, I believe your statements are accurate.  I find it particularly helpful to maintain a graphical memory map like the one shown below to keep all these values aligned between the application and bootloader projects.  Required symbols for the Application and Bootloader projects respectively are in the right margin.  I obscured the sensitive information, but you should get the idea.  Notice the ...APP_DATA_AREA_SIZE in my case is the sum of flash used by Thread and FDS.

Related