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]

Hello,

What compiler do you use? Segger Embedded Studio? Armgcc (what version)?

I have seen this error before, and it was caused by an "untested" compilator. 

Just to clarify the UART situation. You can have the bootloader over Mesh on a node without using the UART (so you can use the UART for a sensor), but it is a bit more challenging to use UART for sensor + DFU. I suggest that you have one node that only uses UART for DFU, and the rest can use it for the sensors. Is that a viable solution?

If not, you would have to somehow decide to disconnect the UART from the sensor, and initialize the UART for the DFU.

BR,

Edvin

[DeveloperZ]

Edvin said:

What compiler do you use? Segger Embedded Studio? Armgcc (what version)?

I use Segger Embedded Studio v4.12.

Edvin said:

I suggest that you have one node that only uses UART for DFU, and the rest can use it for the sensors. Is that a viable solution?

Yes, I can do that. I can use a gateway node which can use the serial Bootloader to push the application onto the network and all the nodes that have UART application can use a Mesh Bootloader(not serial).

Edvin said:

You can have the bootloader over Mesh on a node without using the UART

Do you mean the "mesh_bootloader_gccarmemb_nrf52832_xxAA.hex" file in the bin/bootloader folder?

Thank you.

[Edvin]

DeveloperZ said:

Do you mean the "mesh_bootloader_gccarmemb_nrf52832_xxAA.hex" file in the bin/bootloader folder?

 Yes. That is correct. Also, in mesh_init() (in main.c), make sure nrf_mesh_serial_init() is not called for the nodes that intend to use the UART for sensors, only the gateway node that sends the update from serial to the network. This is skipped by defining NRF_MESH_SERIAL_ENABLE to 0. 

In your SES, can you click "Help" -> About Segger Embedded Studio, and take a screenshot of the window that pops up:

BR,

Edvin

[DeveloperZ]

Hi,

Please find the picture below!!

[Edvin]

Can you please try to downgrade to Segger Embedded Studio version 3.40?

This is the version that is tested with the SDK. As mentioned, I have seen a similar error with another customer using a later version of the compiler. Please try to downgrade SES to version 3.40. It is also mentioned in the release notes for SDK15.2.0 what versions that are officially supported.

[DeveloperZ]

Hi,

I was able to successfully push the update yesterday using the same files but today, it failed!!

There is a new issue today which is 

I can't push the update as it gets stuck at this point before starting to send the firmware update. It says INVALID DATA on the DFU packet but I was trying to push the Blinky example. What could be an invalid data on a Blinky DFU packet?

I was using the same keys, device pages that I used a day before but today, it doesn't perform the update.

[Edvin]

Edvin said:

Can you please try to downgrade to Segger Embedded Studio version 3.40?

 Did you try this?

How did you create your packet using nrfutil? What was your command?

[DeveloperZ]

Yes, I did try with downgraded Segger version v3.40.

The command was 

nrfutil dfu genpkg --application bin/blinky/blinky_nrf52832_xxAA_s132_6.1.0.hex     --company-id 0x00000059     --application-id 1     --application-version 37      --key-file private_key.txt     --sd-req 0x00AF   --mesh dfu_test2.zip

I was able to push a packet generated using the same command with a different application version the day before but it failed on Friday.!!

[Edvin]

Hello,

And you haven't changed the application-version by now? Is it >=37 when you try to send this packet?

I suggest that you try to write a .bat script that flashes the softdevice, bootloader device_page and your application, creates the packet, and then initiate the DFU procedure. 

[DeveloperZ]

Hello,

I have been using scripts and was able to push the dfu packets successfully. But, this what has happened recently:

I added DFU functionality to the experimental dimming. I flashed them onto dev boards. I was able to push Blinky to it and it works perfectly fine. 

Now, I had the dimming example with DFU and I pushed the same example by changing its name. The update was completely pushed but at the end, all the LED's turned ON indicating some error upon loading the new firmware.Now, I can't see the node on the Mesh App.

Does this indicate any error in the firmware? If so, why doesn't it show up when I initially flash the board with same firmware?

Any idea on what might be wrong?

Thank you.