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]

And have you tried to push a DFU image with application key 2 to board 1? Does board 2 update then?

[DeveloperZ]

Yes, 

The result was.... board 1 with LED's 1 and 2 ON indicating the DFU event ended and board 2 got updated with Blinky!!!

[DeveloperZ]

DeveloperZ said:

As we discussed in the previous thread about the changes made to the UART that caused failure in pushing the DFU, how to push the update for an application which uses UART(requires changes to few files)?

Any idea about this?

This is what I tried: In a different 3.1.0 Mesh SDK and 15.2.0 SDK, I made changes to few UART files and implemented a mesh example with UART. I copied that hex file into a folder containing the stock SDK's, created a zip file in that folder and tried to push it onto the boards with Mesh dfu stock example. It failed to push the update.

Does the changes in the UART files of the receiving DFU packet also causes failure to push DFU?

I shall try once again and update if there is any change in the test that I made with this UART application.

[Edvin]

Yes. That is the intention? Now you have updated the device that matched the device page from another board with another application and device page.

[DeveloperZ]

Edvin said:

Yes. That is the intention? Now you have updated the device that matched the device page from another board with another application and device page.

Yep that cleared the question about the keys. 

Next one is about updating the application with UART. I will try this scenario and will update the result!!

DeveloperZ said:

This is what I tried: In a different 3.1.0 Mesh SDK and 15.2.0 SDK, I made changes to few UART files and implemented a mesh example with UART. I copied that hex file into a folder containing the stock SDK's, created a zip file in that folder and tried to push it onto the boards with Mesh dfu stock example. It failed to push the update.

Thank you.