This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

unstable DFU problem nRF52832_XAA

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. 

Parents
  • 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?

  • 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? 

Reply
  • 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? 

Children
No Data
Related