OTA Thread DFU: Merge SDK example with custom application

[AS_Kalpa]

Hi all!

I'm able to fully test the SDK example https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v3.2.0%2Fthread_example_dfu.html and it works pretty well.

Now, the next step is the integration of this OTA DFU over Thread example in my custom application (that already exploits Thread and MQTT-SN protocol).

I haven't found a tutorial that explains step-by-step this kind of operation. 

Basically I need some help to integrate the DFU client with the user application. I think the key point is the IoT SDK CoAP library that implement a DFU algorithm that should run concurrently to the user application, but I'm a bit confused about merging process.

Thanks in advance,

Alessio

[AS_Kalpa]

I think I need some clarifications about flashing different FW components.

In order to have the OTA DFU example working, I have to flash:

• mbr_nrf52_2.4.1_mbr.hex (MBR)

• nrf52840_xxaa_mbr.hex (BOOTLOADER)

• dfu_client.hex (EXAMPLE HEX)

In order to have my application working, I have to flash:

• s140_nrf52_7.0.1_softdevice.hex (SOFTDEVICE)

• my_app.hex (APPLICATION HEX)

At the moment, I have merged the two application codes and, let's say, I have the  

my_app_DFU.hex

I have tried to flash all the components:

1. mbr_nrf52_2.4.1_mbr.hex (MBR)

2. nrf52840_xxaa_mbr (BOOTLOADER)

3. s140_nrf52_7.0.1_softdevice.hex (SOFTDEVICE)

4. my_app_DFU.hex (APPLICATION+DFU HEX)

I received back this when I flash the SD

and this when I flash the application

Moreover, the dongle is stucked with the green led lit up.

Maybe I am supposed to do some mergehex operations?

Thanks,

Alessio 

 

[Jørgen Holmefjord]

Hi,

You do not need to flash both the MBR and Softdevice HEX-files. The MBR is merged into the softdevice, and you will find that if you do a compare, the first page (0x0 - 0x1000) will be identical.

The Bootloader needs information about the application in order to verify that it is a valid application. This means that you either needs to generate the settings using nrfutil, or create a DFU packet of the application and "flash" it using the DFU process. 

I recommend that you follow the instructions in the Testing section of the Thread Secure OTA DFU Example, especially steps 3.c-d.

Best regards,
Jørgen 

[AS_Kalpa]

Yes, I got it right 10min ago, I had a try flashing SD + BL + APP (app + settings) as you linked in the guide.

The setup doesn't work, so I thought it was a code problem and I tried to enter in debug mode.

To avoid problems, since I am newbie in these aspects, I started the debug on SES so I think the right components are flashed directly by SES via Jlink.

I found my code stucked here:

that is part of this function in my main:

If I comment that line the application FW works as usual, without the DFU part.

Seems like there are some problems with openthread lib, since the FW stucks here:

I tried to understand more debugging DFU example and there the code run smoothly.

The only difference I found between the two cases is this one:

DFU example (from which I copy-paste the code) uses blue-marked files, while my application uses red-marked files (obviously because DFU example doesn't exploit SD and my application does).

I can't keep them together otherwise I get "multiple definitions" build error.

Could this be the problem?

[AS_Kalpa]

EDIT: Problem solved calling

thread_instance_init();

before

coap_dfu_init(thread_ot_instance_get());

Now the application starts without stucking.

The problem is that only my original application starts normally, but there isn't the DFU feature.

I can attach a Teraterm log:

The blue-marked line indicates that my application has started normally.

COAP debug messages seem to indicate that there are no particular problems with DFU, but the FW doesn't send any COAP messages (I can't sniff anything with an external sniffer).

Thanks in advance,

Alessio

[Jørgen Holmefjord]

Are you triggering the DFU when the node have attached to a network? In the DFU client example this happens in state_changed_callback() in main:

if (aFlags & OT_CHANGED_THREAD_ROLE)
{
    switch(role)
    {
        case OT_DEVICE_ROLE_CHILD:
        case OT_DEVICE_ROLE_ROUTER:
        case OT_DEVICE_ROLE_LEADER:
            coap_dfu_trigger(NULL);
            break;

        case OT_DEVICE_ROLE_DISABLED:
        case OT_DEVICE_ROLE_DETACHED:
        default:
            break;
    }
}

Also make sure that you have initialized app_timer in your application.

[AS_Kalpa]

Hi Jorgen,

yes I noticed that my application had the ".autocommissioning = false" option, so it creates a thread network only with the border router active. I set it to true and now it sends the GET messages correctly.

But after 3 times, I receive this kind of error log:

Is it normal?

Moreover, when I tried to do the DFU process with a server, It has failed. I got the invalid init error.

The DFU process doesn't start at all, I can't get if this is a problem of the flashed FW or of the DFU procedure (the package or the settings). In my command prompt I can see this kind of error from the server side when I run

nrfutil dfu thread -f -pkg app_dfu_package.zip -p COM13 --channel 11 --panid 43981 --address fdde:ad00:beef:0:45de:6d18:9ea6:219b

Thanks in advance,

Alessio

[AS_Kalpa]

After some researches, I think that is a problems of keys as "prevalidation failed" probably depends on that. 

I'm not sure about using keys. 

What should I do with my custom app during these steps?

In my project I just generated the public key and copy-paste it in my project explorer

[Jørgen Holmefjord]

You should include the generated public key from step 1b in your custom app (replace it with the default file containing the debug-key). When you generate the DFU-package in nrfutil, you need to provide the private key generated in step 1a. This will allow the application (DFU client) to verify the package (signed by private key) using the public key that it have available.

[AS_Kalpa]

Sorry but I didn't get your point.

I generate the priv_key as 1.a and I use it when I generate the DFU package 

nrfutil pkg generate --hw-version 52 --sd-req 0xCA --application-version 2 --application SAMBA_Node_DFU.hex --key-file priv.pem app_dfu_package.zip

I generate also the public_key and I drag it into my project explorer.

I totally miss point 1.c as I don't have that path in my custom project

[Jørgen Holmefjord]

By default, the DFU client example uses our public debug-key, found in examples\dfu\dfu_public_key.c. This key only works with the test-images for BLE/serial DFU, found in examples\dfu\secure_dfu_test_images. If you did not include the file containing the debug-key in your project, it should work fine to drag in the generated public key like you describe. Including both or none of the files should give compile errors, so I guess that should not be the issue here.

[AS_Kalpa]

Ah ok, I thought that the public key was used also to generate the bootloader hex file.

I had a try generating a new  nrf52840_xxaa_mbr.hex (bootloader) file copying my new public key in examples\dfu\dfu_public_key.c but I keep having the "prevalidation failed" error.

I'm pretty sure this error has something to do with keys.

EDIT: I put a debug message to get which is the error cause

From nrf_dfu_req_handler.h I can see:

NRF_DFU_RES_CODE_INVALID_OBJECT          = 0x05,    //!< Data object does not match the firmware and hardware requirements, the signature is wrong, or parsing the command failed.

So I think that:

• Or it is a problem of keys and so I need some help to understand what is wrong in my approach
• Or it is a problem of --sd-req 0xCA (I put 0xCA cause my app exploits s140_nrf52_7.0.1_softdevice.hex but I don't know if it is the right approach since DFU example used --sd-req 0x00)

Thanks in advance,

AS