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]

I believe that the enocean FW is a bit different than other examples. Can you try with one of the others, if you do not intend to use enocean in the end?

The Enocean switches are energy harvesting devices. I don't think they are listening at all times, as other mesh nodes. They only wake up and send a message when a button is pushed. This is probably why you don't see that they get the DFU packets over Mesh.

Best regards,

Edvin

[DeveloperZ]

Edvin said:

Can you try with one of the others, if you do not intend to use enocean in the end?

I did add the DFU example to the experimental_dimming example and it works fine.

Can I have an explanation about pushing the DFU to a gateway node and device page that I asked in my previous comment on this thread?

Thank you.

[Edvin]

Oh, sorry.

Yes. You can push a FW with another application ID through a node.

E.g. A network with 3 nodes, one with application ID 1, one with application ID 2, and one with application ID 3. Only the node with application ID 1 is connected via serial, and does all the pushing of the data.

Generate 3 DFU images. Each with their own application ID, (1, 2 and 3):

nrfutil dfu genpkg --application ..\..\bin\blinky\blinky_nrf52832_xxAA_s132_6.1.0.hex --company-id 0x00000059 --application-id 1 --application-version 2 --key-file data\private_key.txt --sd-req 0x00AF --mesh data\dfu_test1.zip
nrfutil dfu genpkg --application ..\..\bin\blinky\blinky_nrf52832_xxAA_s132_6.1.0.hex --company-id 0x00000059 --application-id 2 --application-version 2 --key-file data\private_key.txt --sd-req 0x00AF --mesh data\dfu_test2.zip
nrfutil dfu genpkg --application ..\..\bin\blinky\blinky_nrf52832_xxAA_s132_6.1.0.hex --company-id 0x00000059 --application-id 3 --application-version 2 --key-file data\private_key.txt --sd-req 0x00AF --mesh data\dfu_test3.zip

Now, to test this, I used the dfu example, and the blinky example as the DFU image, as you can see above. To speed things up a bit, I changed one thing in the DFU example. in nrf_mesh_dfu.c, line 75, I changed:

#define TIMER_DATA_TIMEOUT_US               (600000000)  /**< Time to wait for next data during a transfer. */
to
#define TIMER_DATA_TIMEOUT_US               (10000000)   /**< Time to wait for next data during a transfer. */

Resulting in a 10 second timeout instead of 10 minutes.

This is just because the devices that the packet isn't intended for doesn't by default discover when the DFU transfer is complete, but stays in DFU mode for another 10 minutes.

Reducing this to 10 seconds, I then used the bat script:

REM nrfutil keys --gen-key data\private_key.txt
nrfutil keys --show-vk hex data\private_key.txt

nrfutil dfu genpkg --application ..\..\bin\blinky\blinky_nrf52832_xxAA_s132_6.1.0.hex --company-id 0x00000059 --application-id 1 --application-version 2 --key-file data\private_key.txt --sd-req 0x00AF --mesh data\dfu_test1.zip
nrfutil dfu genpkg --application ..\..\bin\blinky\blinky_nrf52832_xxAA_s132_6.1.0.hex --company-id 0x00000059 --application-id 2 --application-version 2 --key-file data\private_key.txt --sd-req 0x00AF --mesh data\dfu_test2.zip
nrfutil dfu genpkg --application ..\..\bin\blinky\blinky_nrf52832_xxAA_s132_6.1.0.hex --company-id 0x00000059 --application-id 3 --application-version 2 --key-file data\private_key.txt --sd-req 0x00AF --mesh data\dfu_test3.zip

cd tools\dfu
REM python device_page_generator.py -d nrf52832_xxAA -sd "s132_6.1.0"
cd ..\..

nrfjprog -e --snr 111111111
nrfjprog -e --snr 222222222
nrfjprog -e --snr 333333333

nrfjprog --program ..\..\bin\softdevice\s132_nrf52_6.1.0_softdevice.hex --verify --snr 111111111
nrfjprog --program ..\..\bin\softdevice\s132_nrf52_6.1.0_softdevice.hex --verify --snr 222222222
nrfjprog --program ..\..\bin\softdevice\s132_nrf52_6.1.0_softdevice.hex --verify --snr 333333333

nrfjprog --program ..\..\bin\bootloader\gccarmemb\mesh_bootloader_gccarmemb_nrf52832_xxAA.hex --verify --snr 111111111
nrfjprog --program ..\..\bin\bootloader\gccarmemb\mesh_bootloader_gccarmemb_nrf52832_xxAA.hex --verify --snr 222222222
nrfjprog --program ..\..\bin\bootloader\gccarmemb\mesh_bootloader_gccarmemb_nrf52832_xxAA.hex --verify --snr 333333333

nrfjprog --program build\dfu_nrf52832_xxAA_s132_6.1.0_Debug\dfu_nrf52832_xxAA_s132_6.1.0.hex --verify --snr 111111111
nrfjprog --program build\dfu_nrf52832_xxAA_s132_6.1.0_Debug\dfu_nrf52832_xxAA_s132_6.1.0.hex --verify --snr 222222222
nrfjprog --program build\dfu_nrf52832_xxAA_s132_6.1.0_Debug\dfu_nrf52832_xxAA_s132_6.1.0.hex --verify --snr 333333333

nrfjprog --program tools\dfu\bin\device_page_id_1.hex --verify --snr 111111111
nrfjprog --program tools\dfu\bin\device_page_id_2.hex --verify --snr 222222222
nrfjprog --program tools\dfu\bin\device_page_id_3.hex --verify --snr 333333333

nrfjprog --reset --snr 111111111
nrfjprog --reset --snr 222222222
nrfjprog --reset --snr 333333333

TIMEOUT 10

nrfutil --verbose dfu serial -pkg data\dfu_test2.zip -p COM7 -b 115200 -fc --mesh

TIMEOUT 15

nrfutil --verbose dfu serial -pkg data\dfu_test3.zip -p COM7 -b 115200 -fc --mesh

TIMEOUT 15

nrfutil --verbose dfu serial -pkg data\dfu_test1.zip -p COM7 -b 115200 -fc --mesh

As you can see, it waits 15 seconds between each transfer, allowing the nodes to go back to default mode (not DFU mode), so that it is ready to receive a new packet.

As you also can see, I transfer the image with application ID 2, 3 and then 1. All is sent through the COM port belonging to the device with application ID 1.

When it is done, all 3 devices is updated. Now it uses the same application, but with different application IDs. The same method can be used to update with different applications to the devices with different application IDs.

Best regards,

Edvin

[DeveloperZ]

Thanks for a detailed reply.

Next question would be, Does the keys affect the DFU? 

To elaborate my question, does the device page generation has dependency on the keys(private, public)? 

If yes, can I have a device page generated with a set of keys and successfully perform firmware update with the DFU.zip created with a different set of keys? 

Thank you.

[Edvin]

You can test these things. Just flash two devices with device pages with different keys and different application IDs. Then you will see the behavior.

[DeveloperZ]

I did run the test with just one board which has the device page with a set of keys and pushed an update to it with different set of keys and it failed.

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

[Edvin]

Just use the dfu example from an unmodified SDK_for_mesh_3.1.0 and SDK15.2.0. Remember that some files are common for the different projects, so changing them from one project may affect other projects.

Go back to where you have a working dfu procedure, so that you know everything is working, and try to generate two different device pages with different keys. Then push the DFU image to a device with key1, and you will see that the device with key2 is updated.

Spoiler:

I tested it. It works.

[DeveloperZ]

I tried it the same way. My setup was something like this:

board 1 -- device page 1(key1)

board 2 -- device page 2(key2)

boards 3,4,5 -- device page 3(key3)

created the DFU packet with key1 and pushed it to board 1.

The result is board 1 gets updated with Blinky. 

boards 2, 3, 4 and 5 indicate that the DFU event ended (LED's 1 and 2 are on)

Please find the picture below (boards 1 and 2) showing the result:

Edvin said:

I tested it. It works

When you say it works, did you mean that the board two was also updated with Blinky or just that the packets were pushed successfully but board 2 wasn't updated because of different device page?

Thank you.

[Edvin]

DeveloperZ said:

When you say it works, did you mean that the board two was also updated with Blinky or just that the packets were pushed successfully but board 2 wasn't updated because of different device page?

 Only the boards with the correct key and application ID is updated. However you will see that the rest of the boards are also receiving the DFU image, but that is just for retransmission/relaying. They will not update to the new application unless both application ID and keys are correct.

[Edvin]

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