DFU MESH on nRF52832

[Shahin97]

There is a tutorial that shows the user how to create a DFU update on mesh by sending a binky sketch over 

Link:  https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v5.0.0/md_doc_user_guide_modules_dfu_configuring_performing.html

nrfutil dfu genpkg --application bin/blinky/blinky_nrf52832_xxAA_s132_7.2.0.hex --company-id 0x00000059 --application-id 1 --application-version 2 --key-file private_key.txt --sd-req 0x00CB --mesh dfu_test.zip

Above code is from the tutorial, -sd-req is 0x00CB which is wrong, should be 0x0101 , known issue in the tutorial as 0x00CB is 7.0.1 and 0x0101 is 7.2.0. The Blinky sketch doesn't use soft devices and so the above code will work regardless of the soft device. 

Lets say you want to change Blinky to a different program, what considerations do I need to be aware off? 

1 - the soft devices have to match in this case, all other parameters can match the code above

2 - the size of the new application, how big can the update be?

3 - has anyone tried with other examples? as I am only able to flash Blinky using this tutorial.
           - for example, could I replace the blinky binary with lets say a mesh light switch binary and redo the steps

4 - Location of the update? Do we need to know? or will the DFU example sort that out for us using optimal_bank_address routine

5 - Anything else?

[Edvin]

Hello,

Sorry for the late reply. I wrote an answer earlier, and hit reply, but apparently it wasn't posted before I closed the window. I am sorry for the inconvenience. 

Above code is from the tutorial, -sd-req is 0x00CB which is wrong, should be 0x0101

Thank you for that note. I have forwarded this to our technical documentation team. That is a typo, and it should say 0x0101, as this is the softdevice ID for the S132_v7.2.0. 

First, let me explain briefly how the DFU works, and I will get back to your questions. When you do a DFU, the image, which consists of the application and some headers and signatures are transferred via Bluetooth Mesh into an emptu slot in the nRF's flash. When the transfer is complete, it will validate the new image, and if everything looks ok, it will delete the old application, and replace it with the new one. The bootloader and Softdevice is unchanged. This means that the application needs to work with the softdevice that is already present. If you were to test the blinky application that you refer to without the softdevice, you would see that it wouldn't work,  even though it doesn't directly use the SoftDevice, it is compiled to run from the flash address after the softdevice. So without a softdevice, the application starting from that address would not boot up.

1: The application needs to be able to run with the softdevice that is programmed. That means that at least, the application needs to be compiled with the start address starting after the softdevice. Therefore, you would see that it wouldn't work to DFU to the standard blinky example (which is not compiled to run with a softdevice).

2: The flash needs to be able to fit the bootloader, softdevice, old application and new application at the same time. This is because the old application is used to transfer the new application. I have seen cases where the new application is too big to fit together with the old application. In those cases, the customer would typically do a DFU to a temporary application that is smaller than the original application, so that they have more flash for the final application. Note that the application needs to be capable of DFU, for future firmware upgrades. If you e.g. test with the blinky example mentioned in the guide, you will see that this blinky application is no longer capable of receiving DFUs.

3: Yes. That is possible. You need to copy all DFU related API from the dfu application into your own application, as well as adding the nrf_mesh_dfu.c, so that it's nrf_mesh_dfu_init() is used instead of the weak implementation in nrf_mesh_weak.c. When this is included, it will be called during nrf_mesh_init() in nrf_mesh.c. Make sure it returns NRF_SUCCESS. Then you need to look at the event handlers in main.c from the dfu example. All mesh related events needs to be added to your application as well.

4: I don't think this is something you need to worry about. The bootloader will sort this out for you. Let me know if you encounter any issues with this.

5: Give it a go. Make a run through the guide that you linked, and then try to add this to your own application. Also make sure that you are able to do multiple DFUs in a row, with minimal changes (turn on and off LEDs between application versions, or add logging that changes, to verify that they have successfully updated their application). Best of luck!

Best regards,

Edvin

[Shahin97]

I am concerned about the application size. As I am using the nRF52832 instead of the nRF52840, and so I have half the flash size,512KB. 

s132_nrf52_7.2.0_softdevice.hex is 420KB, importing this into Connect Programmer is 149KB, 
mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex is 59KB, in Programmer is 21KB,

lets use the smaller values, this leaves me with (512 - 149 - 21) 342KB, not to mention device page/settings etc still need to be added. As DFU is running in dual bank mode, the application has to be halve that size. Let's say I have 160KB left, The DFU example is larger than 160KB. Am I correct in saying I would need SPI flash or the upgraded MCU 52840 for DFU applications?

[Shahin97]

Is there a tutorial to integrate SPI FLASH to the DFU MESH example? 

[Edvin]

We don't have that, but it would probably be possible to change the bootloader and the DFU part of your application to use it. We will have it in NCS (when Bluetooth SIG releases their DFU specification). But I think the nRF52832 is not supported in BLE Mesh in NCS, because of its' small size.

BR,
Edvin

[Shahin97]

I am confused, DFU mesh using external flash won't be supported because of the low flash size. Surely adding the external flash size would be the answer? have I misunderstood something?