DFU compatibility for a mesh example

[DeveloperZ]

Hi,

I am interested to know how to make a mesh node (for example, a light server) compatible to perform a DFU.

I have gone through the DFU page and I noticed that the DFU is done over the Serial port. I understand that the dfu firmware is being replaced with blinky firmware. Correct me if I am wrong.

Now, what changes should I make to the commands inorder to make the light_server example node to be DFU compatible/capable over the air?

Would replacing the application hex file on step 8 to light_server instead of dfu solve it? or should I add any other commands to have light_server firmware first?

Thank you.

[Edvin]

Hello,

well. The short answer is that you need the mesh_evt_handler() to handle DFU packets, like it does in the DFU example. In addition, if you want the device to handle Serial DFU (the one who receives the packets from nrfutil), you need it to support serial DFU as well. 

This is done in nrf_mesh_serial_init(NULL); in mesh_init(void).

Inside this call, serial_handler_dfu_init() is called, which handles the DFU serial messages.

When you try to include the DFU packets (over Mesh) you will probably have to include everything you need around as well. Give it a go, and let me know if you get stuck.

BR,

Edvin

[DeveloperZ]

Hi,

Edvin said:

The short answer is that you need the mesh_evt_handler() to handle DFU packets, like it does in the DFU example.

I notice that nrf_mesh_evt_handler_t is used in only few examples like EnOcean, light switch provisioner, Lpn examples. 

So, in order to make other examples DFU capable, I need to add the nrf_mesh_evt_handler while mesh initilization.

Edvin said:

Give it a go, and let me know if you get stuck.

If I am trying to push the dfu packets over the air but not serial, I should push it from the nrf connect app right? or can we do it from the mesh app? Sorry but I have no idea about how to push it OTA!!

Thank you.

[Edvin]

No. nRF Connect doesn't work with Mesh. You need to push it via Serial to one device, and then it will transmit it via Mesh to the others. Can you try to follow the getting started with Mesh DFU guide? You need to follow every step. Seeing what you write from the other DevZone ticket (the other one that I handle) and this one, I am not sure what you are doing anymore. Can you try to follow the guide exactly once first, just to see that you get this up and running first, before you try to change anything.

BR,

Edvin

[DeveloperZ]

Edvin said:

Seeing what you write from the other DevZone ticket (the other one that I handle) and this one, I am not sure what you are doing anymore.

Hi!

Sorry if this is confusing, we opened another ticket because its a different question, even if they are related, its good practice to keep different questions separated on different tickets.

Our current endeavors are heading on 3 directions:

1: Understand DFU as a whole, get to know what it is, how its implemented, how is supposed to work etc.

2: Run the "standard" DFU as its on the SDK, the documentation is not that clear and we haven't manage to run it successfully...

Those 2 first points are the ones related to the other ticket we have open, and they are basically related to the DFU example documentation

Then we have this ticket:

3: To know what we need to add to our current custom firmware to make it OTA / DFU capable? how to have the DFU functionality on our current firmware.

This question is more related to the "DFU library" if there is such thing...? Basically general documentation on how to add DFU capabilities to a custom BLE Mesh firmware? or is the DFU functionality included by default on the Mesh SDK?

[Edvin]

DeveloperZ said:

Sorry if this is confusing, we opened another ticket because its a different question, even if they are related, its good practice to keep different questions separated on different tickets.

 I absolutely agree Not saying that it shouldn't be two posts. But seeing the two posts, my concern was that you tried to change too many things at once. One thing that is tricky with DFU is that everything has to be just right, or else the DFU update will not succeed. 

The DFU example in the mesh SDK does virtually nothing other than wait for a serial DFU or a DFU over Mesh, so just add all the functions that are there to your project, and it should work. As mentioned, if you don't need the serial part in all nodes, just remove nrf_mesh_serial_init() from the initialize() function.

But I am more curious why the DFU guide doesn't work for you. Have you defined NRF_MESH_SERIAL_ENABLE to 1?

As mentioned, the nRF Connect will not work for DFU updates in a mesh network. Only serial to one device, and this device will transmit the packet to the other nodes in the network (that uses the same application ID). 

BR,

Edvin

[DeveloperZ]

Hi,

Now that I have the DFU running,

Edvin said:

The short answer is that you need the mesh_evt_handler() to handle DFU packets,

I will try to add this functionality into other examples which don't have DFU capability and will be back with the update on that.

Thank you.

[DeveloperZ]

Hi,

I was able to successfully add the DFU capabilities into the Enocean_switch node, I was able to push the Blinky dfu to it and it was done successfully. Then, I tried to push a DFU packet with a customized mesh example hex file which understandably takes around 90mins.

Next, I am thinking about differentiating the DFU packets as my network might have multiple firmwares. 
My best idea is differentiating the application id in the bootloader.json file. Is there any other way(can be easy or not) to differentiate the firmware updates.

Feel free to criticize my ideas and point out the best way.

Thank you. 

[Edvin]

Hello,

You are correct. The application ID is intended for exactly this. If you have several types of nodes in your network, you can differentiate them using the application ID. Note that all the nodes in your network will still retransmit the DFU packets (like it would with any other Mesh packet), in case there are some other nodes that are not in range of the original publisher that needs this update. 

Just be aware that when you are testing the DFU from the getting started guide, and you have more nodes, you may notice that these nodes are not actually in a network. They are not provisioned at any point. The DFU runs outside the encryption of the network, but your nodes will only accept packets that are using the same keyset and manufacturer ID as your nodes use in your device page.

Best regards,

Edvin

[DeveloperZ]

Edvin said:

If you have several types of nodes in your network, you can differentiate them using the application ID

So, If I were to have only one node as the gateway to push all the DFU updates into the mesh, I need to have a different device page on the gateway node every time I push a different firmware?

in other words, does the gateway node check the application id after the update is successfully loaded onto mesh or initially when we try to push the update?

Because the device page that is flashed on the gateway node might have a different application id and that varies with every new firmware that is being updated.