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?)

[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