No response from nRF52820 when DFU is attempted again

[Louis_263]

Hello everyone,

I have successfully managed to perform a DFU with a DFU package consisting of an app and a softdevice. I wanted to test what happens when I manually cancel the DFU and then try to start a new DFU.
After I cancelled the DFU of the app and restarted the DFU, the DFU works without any problems and the app starts as expected.
However, after I cancel the DFU of the softdevice and restart the DFU, there is no response from the nRF in the DFU after a certain point.

This is the log where the DFU of SD + App worked:

log_ok.txt

This is the log where the DFU of SD + App did not work (after I cancelled the DFU of the softdevice manually):

log_fail.txt

In the log where the DFu didn't work, I see that flash memory is written to from address 0x27000. However, this is the area of the application. I would have expected that first in the area of the softdevices is written, because this was also so in the log where the DFU has worked.
Is this possibly a bug?

Best Regards

Louis

[Vidar Berg]

Louis_263 , this is a known limitation, unfortunately. From the SDK release notes:

** DFU **

- NRFFOETT-2579: If the transfer is aborted when transferring a SoftDevice to a device
  with no SoftDevice present (using sd-req = 0), the device can erroneously think that the SoftDevice
  was transferred correctly. On smaller devices there could be no room
  to transfer the SoftDevice again.
  Workaround: Transfer any application with sd-req set to 0.
  The application must be at least 3 pages (0x3000 bytes) long.
  The application will overwrite the SoftDevice, allowing it to be retransferred.

In other words, to allow the SD update to be attempted again, you have to prepare a dummy app update which can overwrite the Softdevice first.

[Louis_263]

Hi Vidar,

Thanks for your fast answer Currently there is probably no fix for this since no new SDK has come out yet, right?

[Vidar Berg]

Hi,

No problem. Yes, you are right, we currently do not have a fix for this available. It looks like it should be easy enough to fix, but I would be hesitant to make changes to critical changes to a critical part of the validation step without extensive testing and validation. I think it is safest to use the workaround for now. It should be possible to automate this recovery procedure without any user intervention.