• State Not Answered
  • Replies 9 replies
  • Subscribers 88 subscribers
  • Views 2839 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 260515
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents Reply Children
  • 0 in reply to Richard R

    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

  • 0 in reply to 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

  • 0 in reply to tesc

    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?

  • 0 in reply to Richard R

    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

Related
Terms of service