nRF5 SDK for Thread: Secure DFU OTA stopped working all of sudden .

[Brian (Geek)]

Hello, 

I am using nrf5 SDK for thread SDK for development of my thread based product. Product is already developed just have to integrate dfu in it. Few months back when I tried dfu integrating it with my mqttsn example it worked everything was working smoothly. I was able to update mqttsn firmware both in unicast and multicast mode. 

But now all of sudden when I try to perform same steps for dfu, it doesn't work. I have tried again with dfu client example as given in docs there too I am only able to perform dfu once.

Problem faced till now:

- After one time dfu of dfu client example, I have to manually reset the board otherwise it is not downloading the firmware packet.

In the client example logs, I can see that after one dfu process when I try to update the firmware with another package generated by nrfutil with incremented application version I see dfu application showing error of invalid init packet although the packet is generated by nrfutil. If I reset the board, and try again it accepts the same dfu init packet without any error.

- I have again started from the scratch with simple led dfu client example on 2 dk boards but dfu completion successfully occurs only once. I have performed all the steps given in docs from generating new keys to generating public keys. Some times I get error of some parsing issue. Some times I see the error of too big gap between firmware packets and much more. I have also tried decreasing the rate of packets per second to 3 as well but still no help. 

- Only difference with my current dfu implementation and the previously running dfu implementation is that at that time only 2_3 nodes were there in network. But now I have 4_5 nodes in network. 

So please someone help me in the correct implementation of the DFU as it is currently failing 99 percent of times in firmware update.  Or please point out the possible issues and solutions.

[Jørgen Holmefjord]

Hi,

Can you post the logs from the device being updated, and the commands you use for generating the firmware packets and start the DFU from nrfutil?

If you can also post a sniffer trace from the on-air traffic when the DFU process completes and fails, that may help determine the issue.

Best regards,
Jørgen

[Brian (Geek)]

Hello any update ?

Update:

I am able to perform DFU OTA easily in FTD device. But when i do the same for SED, i am able to perform the following DFU:

1 FTD firmware -----> SED Firmware (DFU successfull)

2 FTD firmware -----> FTD Firmware (DFU successfull)

3  SED Firmware----> SED Firmware (Not successfull).

in 3rd, if o perform a manual reset than i am able to perform SED DFU for one time, after that i am unable to perform DFU process as my thread device isn't asking for the COAP firmware packets. If i do a manual reset now than again i am able to do dfu for one time.

[Jørgen Holmefjord]

Hi,

A sniffer trace would be very useful to determine what is failing in the DFU process. Did the nrfutil application crash with the error you posted above when the DFU started failing?

If you can also increase the log level in the application, but setting the following configs to "Debug", this may also provide some more details:

// <o> NRF_LOG_DEFAULT_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef NRF_LOG_DEFAULT_LEVEL
#define NRF_LOG_DEFAULT_LEVEL 4
#endif

// <o> BACKGROUND_DFU_CONFIG_LOG_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef BACKGROUND_DFU_CONFIG_LOG_LEVEL
#define BACKGROUND_DFU_CONFIG_LOG_LEVEL 4
#endif

// <e> IOT_COAP_CONFIG_LOG_ENABLED - Enables logging in the module.
//==========================================================
#ifndef IOT_COAP_CONFIG_LOG_ENABLED
#define IOT_COAP_CONFIG_LOG_ENABLED 1
#endif
// <o> IOT_COAP_CONFIG_LOG_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef IOT_COAP_CONFIG_LOG_LEVEL
#define IOT_COAP_CONFIG_LOG_LEVEL 4
#endif

Enabling higher Log levels in OpenThread would also be useful, but this requires you to rebuild the OpenThread libraries.

Best regards,
Jørgen

[Brian (Geek)]

Jørgen Holmefjord said:

Did the nrfutil application crash with the error you posted above when the DFU started failing?

No instead it's opposite, the DFU client try to receive the successive blocks but it cant as server side shows some serial problem.  So eventually DFU fails.

I think after one time DFU, the client example only send COAP DFU trigger packet once at start so if i start my DFU after 2-3 minutes my client is unable to respond. I think this was the issue, because if i send repeated dfu trigger packets (once every 30 sec), i am able to complete DFU multiple number of times without any issues. 

Also the DFU process is slow due to my parent polling period.