Device not going to DFU mode on some devices

[vishnu3391_uh]

Hi,

We are currently stuck with a big issue on as we are not able to update the devices(nRF52840) on field. We have changed the clock source to internal in the last released build. But we changed the settings only in the application and released only an application update. Now when we tried to release a new application many users are not able to update to the new version and we found that they are getting DFU error. Upon searching the devzone we found we should've updated the bootloader also with the same clock settings change as in application. More than 10k devices were able to update to the new version. 
Does this says that those devices which were failing has external clock accuracy issue? Why is it failing on certain devices and not on other devices? How to fix this issue? 

Also we changed the softdevice version to v7.3 and same like above we didn't change this in bootloader. What is the proper and best way to update SD and bootloader update in this scenarios. Considering the devices on field has bootloader with external clock and application with internal clock and the SD version 7.2. What is the proper DFU package file making process here to update Bootloader+SD+application?

Thanks,

Vishnu

[Vidar Berg]

Hi Vishnu,

I don't think the different clock source configuration explains the DFU failure.The new clock configuration will not take effect until after the update is complete. Are you able to provide more information about when and where the DFU process is failing? Is the failure happening when attempting to enter DFU mode, or does it happen at some point during the firmware transfer? Also, do you have any data to check if the failure might be specific to certain phone models?

What is the proper and best way to update SD and bootloader update in this scenarios.

You can make a distribution packet that contains the SD+BL and application.

Best regards,

Vidar

[vishnu3391_uh]

Hi Vidar,

No no. The current version on the field is have application with internal clock and bootloader with default settings. Now on top of this build some users are not able to update. Yes we got one device back for troubleshooting and it is failing when attempting to enter DFU mode. It is coming on many phone models. 

Vidar Berg said:

You can make a distribution packet that contains the SD+BL and application.

For this do we need to update the bootloader first to take new SD? If yes what is the change?

Thanks,

Vishnu

[vishnu3391_uh]

Vidar Berg said:

So, is the firmware application in the field running off the internal RC oscillator, while the bootloader uses the LF crystal? Have you tried to debug the bootloader when it's failing to enter DFU mode

Yes. The application is with internal RC and bootloader uses default external crystal settings. The device is fully enclosed and no debug pins available to debug. Anyway to recover this? 

It is trying to connect for few times and then disconnecting. After that it take 15-20 minutes to start advertising again with old application

Thanks,

Vishnu

[Vidar Berg]

Hi Vishnu,

vishnu3391_uh said:

Yes. The application is with internal RC and bootloader uses default external crystal settings. The device is fully enclosed and no debug pins available to debug. Anyway to recover this? 

Thanks for confirming.

vishnu3391_uh said:

It is trying to connect for few times and then disconnecting. After that it take 15-20 minutes to start advertising again with old application

Is this behavior consistent on the failing devices? That is, do they always go "offline" for 15-20 minutes after a failed DFU attempt?

Best regards,

Vidar 

 

[vishnu3391_uh]

Hi Vidar,

Vidar Berg said:

Is this behavior consistent on the failing devices? That is, do they always go "offline" for 15-20 minutes after a failed DFU attempt?

We got only device back here and it was going offline for 15-20 minutes always on DFU attempt. Most devices would be facing the same. 

Thanks,

Vishnu

[Vidar Berg]

Hi Vishnu,

This is interesting, the bootloader should time out and reset after 2 minutes of inactivity and fall back to the old application with the default configuration. The fact that it takes more than 15 minutes to recover suggests that there may be an issue with the clock source. Maybe the BLE transport is waiting for the crystal to start up, or do you have a WD enabled on DFU entry? 

I tried to replicate this scenario on my desk by using the buttonless application with the RC oscillator, and the bootloader with the default configuration, but did not experience any problems with DFU. 

Best regards,

Vidar

[vishnu3391_uh]

Hi Vidar,

Vidar Berg said:

Maybe the BLE transport is waiting for the crystal to start up, or do you have a WD enabled on DFU entry? 

WDT is enabled in the application and and WD settings is same as default settings in bootloader. Unchanged. 

Vidar Berg said:

I tried to replicate this scenario on my desk by using the buttonless application with the RC oscillator, and the bootloader with the default configuration, but did not experience any problems with DFU

Even we are not able to replicating the issue on PCB here. But atleast 200-500 users faced this issue on field and we had to pull back the release. 

Thanks,

Vishnu

[Vidar Berg]

Hi Vishnu,

I would have expected the WDT to trigger a reset and caused the bootloader to exit DFU mode and revert to the old application. Is it impossible to open the enclosure and access the SWD lines?

Best regards,

Vidar

[vishnu3391_uh]

That is possible. What should we check?

[Vidar Berg]

Is readback protection enabled? If not, you can start by running 'nrfjprog --readregs' to read out the CPU registers. This may help reveal what state the device is in. 

[vishnu3391_uh]

Yes, Readback protection is enabled. :(

[vishnu3391_uh]

Hi Vidar,

We have managed to expose the SWD pins. Anything we can check?

Thanks,

Vishnu