DFU MESH on nRF52832

RE: DFU MESH on nRF52832

Edvin — Thu, 23 Feb 2023 14:59:35 GMT

Mesh is not supported on the smaller chips because of the Bluetooth Low Energy stack size in combination with the Mesh stack size. It has nothing to do with DFU. Pretend I didn't mention the NCS and external flash in the other reply.

You can look into adding the SPI flash to the bootloader in the nRF5 SDK for Mesh if you need it. Alternatively, you can DFU to a smaller application in between your main applications. Those are your two options in the nRF5 SDK, as I see it.

BR,

Edvin

RE: DFU MESH on nRF52832

Shahin97 — Wed, 22 Feb 2023 13:59:12 GMT

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?

RE: DFU MESH on nRF52832

Edvin — Wed, 22 Feb 2023 13:15:22 GMT

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

RE: DFU MESH on nRF52832

Shahin97 — Wed, 22 Feb 2023 10:34:58 GMT

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

RE: DFU MESH on nRF52832

Shahin97 — Tue, 21 Feb 2023 16:26:07 GMT

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?

RE: DFU MESH on nRF52832

Edvin — Tue, 21 Feb 2023 14:34:18 GMT

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.

[quote user=""]Above code is from the tutorial, -sd-req is 0x00CB which is wrong, should be 0x0101[/quote]

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