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. 

[Einar Thorsrud]

Hi,

Which (if any) modifications have you made to the bootloader? Which method to you use to enter DFU mode? What debugging have you done so far and what results do you have?

[Rafig]

There is no modifications on bootloader. 

My application is based on ble_peripheral / ble_uart example (SDK v16.0.0) 

To enter DFU mode nus_data_handler gets a symbol from phone app (for example 'B') and calls following code:

sd_power_grepgret_set(0, 0xB1);
NVIC_SystemReset();

As for the debugging, we know following: After receiving DFU command, device restarts (so there is no problem in this part). But after the restart it doesn't enter DFU mode, it just starts our application. If you have any specific recommendations on how to debug it, we could follow them and report. 

[Einar Thorsrud]

Hi,

I notice a typo in sd_power_gpregret_set() there so I assume this is not the actual code you use. Do you also call sd_power_gpregret_clr() first? If not you should, in case some bits happen to have another value for some reason - either because they are set explicitly in some cases, or because there has been a pin reset or other where the retention register along with other RAM could have been corrupted (the GPREGRET register is retained during soft reset as in this case, but not in other types of reset).

In addition to ensuring that you call sd_power_gpregret_clr(0, 0xffffffff); before setting you could read and log the value of the GPREGRET in the bootloader to see if that is the problem, or if there is something else we need to look at.

[Rafig]

Thank you very much for your assistance. I will follow the instructions and update you as soon as possible. As for the typo, it is normal in the actual code, just missed letters when was typing here. 

[Rafig]

Hi Einar,

We have conducted several tests in different scenarios:

1) Hardware Setup: Custom PCB

1.1) Custom software: Issue persists

1.2) DFU example: Issue persists, but less frequently.

2) Hardware Setup: Development Kit

Issue didn't happen

We added 

sd_power_gpregret_clr(0, 0xffffffff) 

 in our custom code before testing, as per your recommendations. It didn't help. 

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

Also, I wanted to ask something regarding your previous comments. You wrote following: "before setting you could read and log the value of the GPREGRET in the bootloader to see if that is the problem, or if there is something else we need to look at."  Why do we need check value before setting? Shouldn't we check it after setting?