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

[Richard R]

Thanks for the pointers Terje,

I am looking at the proprietary nRF mesh DFU solution and trying to understand it and have some questions. My codebase is SDK 4.2.0

1. in nrf_mesh_dfu_state_t - I don't see some states being used (NRF_MESH_DFU_STATE_READY or NRF_MESH_DFU_STATE_STABILIZE)  - It is mentioned in the message state diagram in documentation. Am I missing something?

2. Why can't DFU messages be processed by nrf_mesh_dfu_rx() while mesh_flash_in_progress() is true? my understanding is that mesh_flash eventually calls bearer_handler_action_enqueue() - which schedules the job. is there a resource conflict I am missing?

3. NRF_MESH_DFU_TX_SLOTS - If I understand this correctly, because the solution is implemented at the bearer layer, there is no concept of TimeToLive and the Tx slots also determine the number of Tx packets each node can `cache` and relay? I am a bit concerned about message flooding to the network with this approach.

4. Similarly, due to the implementation at the bearer layer, I am having a hard time understanding how a target node can report its status to the originator device. At the access layer, this can be done using a unicast message, but at the bearer layer, any message would have to be broadcasted and relayed back to the originator, correct?. Any insight on this?

[tesc]

Hi,

1. There are several values in nrf_mesh_dfu_state_t that I cannot find to be set anywhere in the nRF5 SDK for Mesh codebase:

• NRF_MESH_DFU_STATE_UNINITIALIZED
• NRF_MESH_DFU_STATE_FIND_FWID
• NRF_MESH_DFU_STATE_READY
• NRF_MESH_DFU_STATE_VALIDATE
• NRF_MESH_DFU_STATE_STABILIZE

Of those, NRF_MESH_DFU_STATE_UNINITIALIZED is checked a few places, and might appear if the state is memset to 0. I only find the enum definition when grepping for the others. They may have been used previously and disappeared in refactoring, but I have not looked further back than to nRF5 SDK for Mesh v3.0.0.

Where do I find the message state diagram that you refer to?

3. The solution is running in parallel to the Bluetooth mesh network, and as such forms a separate network. The "time to live" mechanism in Bluetooth mesh is that of the maximum number of "hops" that a message can take through the network. I can see a few potential congestion issues, but that would be mitigated as long as the source sends the upgrade at a maintainable speed.

I share your understanding that NRF_MESH_DFU_TX_SLOTS defines the max number of DFU packets that the node can hold at any instant in time. When it receives a new DFU packet, it puts it in an empty slot and retransmits it a number of times before the slot becomes empty again.

4. There is no confirmation of reception. The proprietary mesh DFU solution relies solely on the capabilities of a "flooding mesh" to propagate the upgrade to all nodes, given the parameters of the network (mainly topology and number of retransmits).

I will get back to you regarding your question 2.

Regards,
Terje

[Richard R]

The message diagrams (that still have the missing states are here): infocenter.nordicsemi.com/.../md_doc_user_guide_modules_dfu_integrating_into_app.html

[tesc]

Hi,

Thanks. I see. I need to consult our mesh team regarding that. (The unused states and their appearance in the MSCs.)

Richard R said:

2. Why can't DFU messages be processed by nrf_mesh_dfu_rx() while mesh_flash_in_progress() is true? my understanding is that mesh_flash eventually calls bearer_handler_action_enqueue() - which schedules the job. is there a resource conflict I am missing?

The mesh stack and the bootloader have separate low-level flash drivers. If the stack provides context to the bootloader without finishing the ongoing flash related activity it will cause conflicted access to the non-volatile memory controller. The separation is for the bootloader to be able to operate without an applicaiton (i.e. in bootloader only mode.)

In order to coexist with the SoftDevice, the mesh stack only operates within the timeslots provided by the SoftDevice through the timeslot API. mesh_flash is a component responsible for managing flash related operation with regards to timeslots. The actual access to the non-volatile memory controller happens through nrf_flash.

Regards,
Terje

[tesc]

Hi,

Regarding the "missing" states in the state diagram: The bootloader uses a different enum, dfu_state_t, which is defined at <mesh sdk root>/mesh/bootloader/include/dfu_types_mesh.h line 225. The two enums do not match entirely, but it matches to the extent required for the communication between bootloader and application.

Regards,
Terje