unstable DFU problem nRF52832_XAA

[Rafig]

Dear Nordic Team, 

We have a problem in our project with custom PCB regarding DFU. It happens in most of our prototypes, but on some devices it doesn't happen. 

Below is the description of the problem:

We update firmware with DFU once. Everything  goes well. Then we try to update firmware again with DFU. Device restarts, but doesn't go into DFU mode. It just restarts the normal program. After this point, this issue persists forever. We suspect it is a hardware related problem, because it started to happen with the latest design. But we are not sure where to look for the problem. 

Could you please provide some guidance for us. 

Please don't hesitate to ask if you need more information. 

Edit: Some corrections - after programming the device, when we test DFU, it works several times in a row. The issue occurs after some period of time (e.g. 1-2 days). We are using SDK16, softdevice 132. 

[Rafig]

We are using SDK16. In the SDK17 release notes I saw following notes (from http://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v17.x.x/doc/17.0.0/release_notes.txt)

- SES will now return a linker error if the bootloader is too large.
- Fixed a bug that caused SD+BL updates to fail if the SD had signature boot validation.
- Fixed an error in the code that booted the app, which could happen
with certain optimization settings.
- Fixed a false positive assert that could sometimes happen after a reset
during an upgrade.
- Fixed a bug that caused compilation errors when building with a board with no buttons.

May it be relevant? 

[Einar Thorsrud]

Hi,

Do you use the same build when testing on the DK and on your custom board, or are there differences needed to adapt to board differences? If any of these changes causes the bootloader size to increase on your custom board, then "- SES will now return a linker error if the bootloader is too large."  could be relevant. To check, you can compare the end address of the bootloaders you build for your custom board and DK. In both cases there should be (at least) two full pages available in the end of the flash.

The other changes between SDK 16 and 17 should not be relevant, assuming you use the same toolchain etc. to build for your custom board and DK.

Rafig said:

We believe it is a hardware issue. Where would you recommend to look for it? 

It is a good question. It would be good if you could add logging or toggle a GPIO or similar in the bootloader when reading the retention register to see if that has been corrupted or not. The GPREGRET is cleared on for instance brown out reset and watchdog reset (See reset behavior table). Could there be an issue with your HW leading to a brownout reset sometimes during a normal startup? Or somthing related to that?

There could also be other HW related issues but I am not able to think of what that could be at the moment. I think it would make sense to debug/log more in the bootloader in that case to see which decisions cause the bootloader to start the app instead of enter DFU mode, and then look specifically at that.