nrf mesh dfu all in application code

[Richard R]

Hello, I am looking at the mesh dfu example code on nRF mesh SDK-4.2.0 on an dk_nrf52840 and I have some questions.

Rather than having both a bootloader and main application that supports both mesh dfu, what if I want just the application to do so.
The bootloader can for example only handle BLE communications.

I am aware that this means connecting bl_cmd_handler() directly from bootloader_app_bridge... is there other considerations or gotchas I need to be aware of?

What is a good way to get started on this (maybe modifying the /example/dfu application to be standalone?)

[Mttrinh]

Hi,

Rather than having both a bootloader and main application that supports both mesh dfu, what if I want just the application to do so.
The bootloader can for example only handle BLE communications.

I'm not completely sure what you mean, can you elaborate/give more details?

[Richard R]

In the current DFU-Mesh solution that nRF offers (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v5.0.0%2Fmd_doc_user_guide_modules_dfu_protocol.html)

The implementation requires both the mesh-bootloader and the sample-application to be loaded in flash.

The sample-application receives mesh messages and if it receives mesh-DFU messages, it then calls the bootloader via the shared RAM function to process it. I am looking for a simpler solution where everything can be done on the application side.

In such a system, the application will handle all mesh-DFU functions (and it can be loaded and tested separately). The bootloader in this case will only support BLE-DFU and not be mesh-capable at all.

If there are other useful references outside of nrf-dfu-protocol to do application-only mesh-DFU I am also interested.

[tesc]

Hi,

Our proprietary mesh DFU solution is based on having a bootloader separate from the application, partly because it allows it to operate even if the application is not present, e.g. if the update is too large to fit in flash without erasing the current application first. In order to "port" it over to run fully on the mesh application, the most important patch would be to not accept such "application deleting" updates.

We have done some preliminary studies in the past to add BLE DFU to mesh projects, and from what I understand some customers have successfully implemented that in the past, but I do not remember to have seen any combined project using both DFU methods concurrently.

BLE DFU is significantly faster than mesh DFU, for updating a single device, due to the large difference in point-to-point throughput. Mesh DFU on the other hand can update the whole network in parallel, which also means less manual work for performing the update.

In the case where some nodes for some reason are left on a previous version of the firmware: Note that as long as the updated nodes still support relaying the messages (and you have at least one node that supports being source for the update), the remaining nodes can still be updated. The nodes will relay DFU updates regardless of whether they themselves are a target for the update or has already been updated to the current update.

Regards,
Terje

[tesc]

Hi,

Actually, we do have an example of using BLE DFU (from nRF5 SDK) with an nRF5 SDK for Mesh example (but without the mesh DFU solution): Configuring DFU over BLE using the LPN example

Regards,
Terje