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]

vishnu3391_uh said:

No no. The current version on the field is have application with internal clock and bootloader with default settings.

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.

vishnu3391_uh said:

Is this because of the clock settings mismatch between app and bootloader on the existing version?

It is possible, but it is not clear why only some devices are affected.

[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