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

DFU compatibility for a mesh example

Hi,

I am interested to know how to make a mesh node (for example, a light server) compatible to perform a DFU.

I have gone through the DFU page and I noticed that the DFU is done over the Serial port. I understand that the dfu firmware is being replaced with blinky firmware. Correct me if I am wrong.

Now, what changes should I make to the commands inorder to make the light_server example node to be DFU compatible/capable over the air?

Would replacing the application hex file on step 8 to light_server instead of dfu solve it? or should I add any other commands to have light_server firmware first?

Thank you.

  • Ok. I see.

    You need to tell the bootloader that you are using some of the flash area for application data, so that the bootloader or flash manager doesn't try to use this for something else.

    Please take a look at what my collague, Hung writes in this post.

    Basically, this define, FLASH_MANAGER_RECOVERY_PAGE_OFFSET_PAGES, will determine the flash that is reserved in between your bootloader and the flash_manager_recovery_page. Make sure that you store all your application data in this space.

    Best regards,

    Edvin

  • Basically, this define, FLASH_MANAGER_RECOVERY_PAGE_OFFSET_PAGES, will determine the flash that is reserved in between your bootloader and the flash_manager_recovery_page.

    I see that this particular define is initialized as 0. I changed it to 1.

    The Enocean entry handle is specified as 00001. So, I had two variables that I am storing in flash. I assigned entry handles as 00002 and 00003. 

    The DFU fails again. Should I also increase the APP_FLASH_PAGE_COUNT value which is set to 1 initially?

    If I increase the count, how can the chip understand which flash page should it save my variables into?

    I can't see anything in the app_flash_data_store, load and clear functions which specifies the flash page.

    I am unable to figure out the changes needed to make the DFU work when I am storing data in the flash using app_flash_data_store, load and clear functions. If I can get the exact info on all the changes needed, that would be a great help.

    Thank you.

  • Just to verify that this is actually the issue. Can you try to perform the DFU without storing the custom data. Does the DFU pass through then?

    It is not easy to tell "the exact info on all the changes needed" when I don't know your project. 

    The assert you get, that is in the application after you performed the DFU, right? Does it happen if you just flash that image as well? Remember to erase the flash completely before you program your application if you have modified the flash setup, using e.g. "nrfjprog -e".

  • Can you try to perform the DFU without storing the custom data.

    When I don't store the data in the flash, DFU process is successful.

    The assert you get, that is in the application after you performed the DFU, right? Does it happen if you just flash that image as well?

    When I flash the example with data stored in flash after erasing the board, it doesn't give back any assert. 

    Now, I am pretty sure that the assert is occurring while initializing the flash (app_flash_init() function) while loading the new firmware.

    Please take a look at what my collague, Hung writes in this post.

    I did go through the post and it says that the address for storing MBR and Softdevice starts at 0x00000 and is of size 0x26000. If you can see the enocean example, in enocean_switch_example.h file, the Entry handle for storing the enocean commissioning data is 0x00001.

    You need to tell the bootloader that you are using some of the flash area for application data, so that the bootloader or flash manager doesn't try to use this for something else.

    I don't know how the boot loader understands that that particular location stores enocean data and can't be used for anything else. Where does the application specify it? Because I tried storing them in 0x00002 and 0x00003 locations and it fails.

    I am trying to find other ways to store the custom data into the flash by either using ads or fstorage but it would be great if I get it working with this app_flash_init().

    I can send you a simple example(zip file) which is similar to what I am trying and I would be glad if you can find some time to check what's going wrong and suggest the changes needed. :)

  • If you store data in a new area in the flash, the flash manager needs to be aware. Changing this with a FW update, either a DFU or by manually programming the device will not erase the flash part that is used for application data storage, and hence the flash manager is still initialized with the old settings. So it is not trivial to change the size that the flash manager will use after it has been initialized.

    I don't think this is actually DFU related at all. You need your initial FW to use the same flash manager settings as the one you intend to use in the end.

Related