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]

Yes, Readback protection is enabled. :(

[vishnu3391_uh]

Hi Vidar,

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

Thanks,

Vishnu

[Vidar Berg]

Hi Vishnu,

Perhaps you can probe the XTAL pins to see if there is any clock signal (this must be done when the chip is supposed to be in bootloader dfu mode). With readback protection enabled, there isn’t much debugging you can do. The only option is to try reprogramming the same firmware and hope that it does not recover the chip.

Best regards,

Vidar

[vishnu3391_uh]

The device recovered after we tried to solder the SWD pins and device powered on. 

What could be the reason. There are many devices showing this issue on field. 

[Vidar Berg]

I wanted you to read out the CPU registers without power-cycling the device. Please see if you can reproduce the problem again on this device, or try on another device with this problem.

[vishnu3391_uh]

We are getting another device. I will update. But with read back protection we would need to erase and the chip to read the CPU register, right? That is fine?