DFU Failure - seems to be a hardware issue

[mikefraguglia]

Hi, we use BMD-350 modules (nrf52832) in our product which has been in production for over a year. Our DFU service is very well tested.

a couple weeks ago, while performing automated DFU updated on our production line (using Nordic Tools), we found one unit which cannot probably receive DFU. It seems to crash out almost instantly. The main application appears to run normally, including BLE.

I have not tried to recover/re-flash the unit.

Are there any diagnostic tests I can perform?

Can Nordic perform any sort of failure analysis?

We were lucky to capture this failure in production, but in our normal process, it is not typical for us to perform DFU on the production line. If this unit had been shipped to a customer, they would have been unable to perform DFU.

Thank you

-Mike

[snoopy20]

Hi Mike,

I assume it's nrf5sdk based, you'll want to specify the config you use. I've used the DFU in production for years now and never seen a failure.

You don't say what it is you're updating; DFU, softdevice or application.

This matters because 832 has two versions; 256kb and 512kb. With 256kb you can't update softdevice. iirc DFU can't be updated either (but I may remember that incorrectly).

My pkg cmd is 

/opt/nrfutil pkg generate --hw-version 52 --app-boot-validation VALIDATE_GENERATED_CRC --application-version $VERSION --application ./app/Output/release/Exe/file.hex --sd-req 0x103 --key-file ./bootloader/private.key /tmp/dfu.zip

So as you can see there's dependencies on the softdevice version that's expected to be installed and the DFU public key it was built with. Perhaps it was flashed with different build/versions than the other units and is seeing a mismatch?

Post your pkg commands and it'll aid for further pointers.

[lennyfrank]

Hi Snoopy, if there’s a SoftDevice or key mismatch, would DFU fail instantly like that? And how do you check the installed SoftDevice version on a faulty unit? Trees Hate You

[Priyanka]

Hi Mike,

Could you provide some more details?

Do you work on nRF Connect SDK or is it the nRF5SDK?

Could you attach the logs that you see during the crash?

Have you confirmed that this does not happen to any other unit? Just the one?

-Priyanka

[mikefraguglia]

We use nRF5 SDK 15.3.0 for this device. When I say "DFU" above I mean an over-the-air update of the main application. We use nRF52 Connectivity for this.

The unit in question was powered by a coin cell battery while being tested on the production line. When I received the unit, I confirmed that I saw the same behavior that they had reported. 

I removed the battery and instead supplied power from a benchtop power supply. The DFU was successful. Subsequent DFUs are now successful even with the original battery installed. I cannot reproduce the issue.

It's possible that cycling the power on the unit is what made the difference, rather than the change of power supply.