nRF52832 DevKit sometimes fails to connect to program target

We have a board in early production, with boards assembled on a professional pick-and-place line. Most of the time everything is fine, but around 10% to 20% of the boards will not program. So of those programmed once but now will not program with revised firmware. We are programming thru the Debug Out connector on the devkit board, with a matching 10-pin header on the target. SWDIO and SWDCLK look just fine on a scope, nice square edges and full swing to the supply rails (3.33V). On the particular troublesome target at hand, RESET stays low at all times. We have tried multiple devkits, multiple ribbon cables, multiple PCs, etc. If we move to program a similar target (different form factor but very similar circuitry), RESET stays high at all times, and it programs just fine.

On the troublesome target board, RESET is routed directly from pin 10 of the header to the RESET pin on the nRF52832, not passing by any place it might be shorted to ground. And this exact board previously programmed. I am trying to program via the simulated "disk drive", via Jlink, via nRF Connect, and via Segger. None of them will now work on this particular board, and I have a set of half dozen or so returned from the client with similar problems.

Where to look?

Parents
  • Hi,

     

    So of those programmed once but now will not program with revised firmware. We are programming thru the Debug Out connector on the devkit board, with a matching 10-pin header on the target. SWDIO and SWDCLK look just fine on a scope, nice square edges and full swing to the supply rails (3.33V). On the particular troublesome target at hand, RESET stays low at all times.

    Have you checked the VDD_NRF voltage of these boards, or specifically the clocks (LFCLK, HFCLK) and/or the DCDC-components?

     

    If you can program it only once, it indicates that there's a problem in the firmware. Default behavior on assertion in both nRF5 SDK and NCS is to do a soft-reset.

     

    Kind regards,

    Håkon

  • Yes, voltages and clocks are fine. These were working boards, and we have had this problem randomly for some time. I read thru the info provided by Wes Cherry in a direct email, and attempted the stated fix for the new APProtect feature, even though we have never used it. On the particular board at hand the datecode on the nRF52832 appears to be 210270.We have programmed these boards repeatedly with different firmware versions, probably about a dozen times each (nowhere near flash wearout).

    I cannot even get Jlink nor nRFConnect Programmer to the point where I can issue an EraseAll command, which would seem to solve anything remotely related to the suggested protection mechanism. We have been using this setup for several years, usually working fine, occasionally seeing errors like this, but of late they have become much more frequent, to the point that we are at a standstill.

Reply
  • Yes, voltages and clocks are fine. These were working boards, and we have had this problem randomly for some time. I read thru the info provided by Wes Cherry in a direct email, and attempted the stated fix for the new APProtect feature, even though we have never used it. On the particular board at hand the datecode on the nRF52832 appears to be 210270.We have programmed these boards repeatedly with different firmware versions, probably about a dozen times each (nowhere near flash wearout).

    I cannot even get Jlink nor nRFConnect Programmer to the point where I can issue an EraseAll command, which would seem to solve anything remotely related to the suggested protection mechanism. We have been using this setup for several years, usually working fine, occasionally seeing errors like this, but of late they have become much more frequent, to the point that we are at a standstill.

Children
Related