Custom nRF52832 module can't connect J-Link anymore after flashing Zephyr program

[nerdybee]

I have a custom PCB with the Fanstel BC832 module. I don't have the inductors for DCDC converter added to my board. I had my entire project written and working with PlatformIO, and everything had been working perfectly, except for the power consumption -- working with PlatformIO had my power consumption plateau at about 8 mA which was unacceptable for my application. So then, we adapted our code using Zephyr and the nRF Connect SDK (v17.1.0) using Visual Studio Code. We got the code working perfectly on both the nRF52DK and the Fanstel nRF52832 EB, with no issues ever, and our current was down to about 2 mA. However, when flashing the code onto our custom PCB's, we've had a few random modules become absolutely bricked, to the point where they're not detected with the J-Link interface anymore (pinout of my connector, which matches that of the DK, is shown in the attached picture -- all the yellow highlighted, plus VTref and GND are included. Module is powered independently during flashing). The device is not recognized as a Nordic device anymore using nRF Desktop either. The only workaround we've had is to unsolder the BC832 module and start over with a fresh one. 

Yesterday, after losing two modules in a row, we checked our prjoject configuration file, and noticed that the DCDC converters had been turned on for some reason. We didn't do this ourselves, but suspect they got turned on when we changed the device name and the whole project got rebuilt. This is our biggest suspect for the failure, but we're very unsure if this would cause the modules to be bricked. My questions are:

1. Is this (having had DCDC converter on) a likely explanation for what happened?

2. Is there a way to recover the bricked modules?

Thanks in advance for all your help! The modules I lost were in PCB's that were already potted, and the assembly was a very time-consuming process. I'm hoping I can fix them, or at least make sure it never happens again.

PS. I've seen other reports of similar behaviors happening, but I haven't been able to find a resolution. One such example is this case.

[PaKa]

1: this is a very likely cause of the problem. If you enable the DCDC and don't have the inductor mounted then the devices should be bricked.

2: If the reset line has been activated as a reset (and not as an GPIO) then keeping the device in reset when applying power will stop the device from enabling the DCDC. You can then perform a chip erase and device is back to normal. If reset is set up as GPIO then your best bet is to try to run the recover function multiple times while preferably cycling the power supply. If you are very lucky you may get the parts erased and then you are good.

Make sure the target voltage on VTref is the same as on the DK, 3.0V, as any other voltage will fail.

[nerdybee]

Thank you so much for confirming my suspicions - this is very helpful! Can you explain in a bit more detail what you mean about the RESET being activated as RESET vs GPIO? Our code doesn't address P21 (the reset pin in the Fanstel BC832) at all, but it is routed in the PCB to the reset line from the DK. Putting a scope probe to it shows the RESET line being HIGH all the time, except for then the RESET button on the DK is pressed while the module is connected to the DK, in which case it transiently goes low and then back up high.

[nerdybee]

Also, just to confirm, for the second option, you mean running nrfjprog --recover in the terminal over and over while turning the module on and off repeatedly? Would this not be damaging since the JLINK connector would remain connected to the DK, while the module would be powered off for some fraction of time?

[PaKa]

Default function for the reset pin is a a GPIO. This will be the case unless you have specifically set it up to be the reset pin, https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/uicr.html?cp=5_2_0_13_0_59#register.PSELRESET-0

You can try to run the recover feature without cycling the power then. If you have a SEGGER jlink and not the DK then the power supplies are independent and you can change the VDD level on the fly, this as the SEGGER devices have level shifters (our DKs do not have these).

[nerdybee]

Thanks for your answer. Checking our project configuration, it seems like there's a variable CONFIG_GPIO_AS_PINRESET set to 'y' by default. Wouldn't this effectively make my P21 act as the RESET pin, rather than GPIO?

[PaKa]

Did you try to run recover with the reset line pulled low? It needs to be kept low from before applying VDD until the recover command has been executed. Letting it go high before that will allow the regulator to change to DCDC mode and this will disable the programming interface.