segmentation fault / bricked nrf52832

[Rasmus]

Hi there,

Until todayI had no problem programming/controlling my nrf52832 on my custom board. Suddenly Im getting segmentation fault whenever I try to communicate with the chip.
Im using my nrf52 DK as my programmer via 10-pin debug out-connector. 

Segger alerts when trying to "build and run":
"Failed to connect to target. 
 no idcode detected.
 Please check connection and Target Interface Type"

Nrf connect just gives me a blank white screen when I try to connect to chip.

nrfjprog returns: segmentation fault

nrfjprog version: 10.6.0
JLinkARM.dll version: 6.60e
SDK 16

Im doubt it has something to do with my problem but the last thing I change before this happend was changing NRF_SPI_DRV_MISO_PULLUP_CFG 0 to 1. I also made sure that RESET PIN was activated by manipulation PSELRES register and the rebuild. That worked out as expected. I am having no problem programming my NRF52 or my Sparkfun via the same 10 pin debug out-connector.
Im on a rather expensive prototype board so It would be really nice to  solve this wierd behaviour.

Running: "nrfjprog --log --family NRF52 --recover" gives me:

"Recovering device. This operation might take 30s.
ERROR: Recover failed. Please make sure that the correct device family is given
ERROR: and try again."

Running: "nrfjprog --recover" gives me:

"zsh: segmentation fault  nrfjprog --recover"

Please advice
Regards /Rasmus

[Rasmus]

Edit: I´ve tried the following solution for about 45 min:
https://devzone.nordicsemi.com/f/nordic-q-a/47308/nrf52832-bricked-nrfjprog-segmentation-fault

I can send you the log.log -fil from when failing on "nrfjprog --recover" command. Would that be helpful? Regards /Rasmus

[Jørgen Holmefjord]

Hi,

Is the board working fine apart from programming, i.e. does the last application that you programmed to the board run when you power it?

Is the board powered through the 10-pin debug cable, or is it powered externally? Have you checked that there are connections between the debug connector and the chip on the board (for instance that there are no soldering issues, etc. that have broken the connections or created shorts)? Some people have solved similar issues by heating the device to fix lost connections.

Best regards,
Jørgen

[Rasmus]

Hi,

Its kinda of hard to tell if the board is working fine apart from the programming part, that is because Im not 100% sure if the last command was --program or --recover. My guess would be that it is not running as it should. 

The board is powered externally.
Its hard to measure the connections between the debug connector and the chip due to lack of space. Its pretty crowded with components and its a 4 layer pcb. The board is manufactured and assembled by an experienced company, so soldering issues is not very likely, but of course not impossible.. also if I recall correct, I didnt touch any of the boards nor the connections when the problem occured.
We have more prototype boards but I feel nervous when this seemed to occur without any particular reason.

I´ve also tried with an other NRF52 DK just to be sure. 

I´m attaching the log.log file from running 

nrfjprog --recover --log

0654.log.log

What does "segmention fault" mean btw? 

Best regards, Rasmus

[Jørgen Holmefjord]

Just to be sure, the board is powered at the same voltage level as the nRF52 DK? The J-Link OB debugger on the DK does not support level shifting.

I'm not sure about the segfault, from the release notes of nRF5 Command Line Tools v10.6.0, it seems like this issue should have been fixed: "Fixed issue where nrfjprog exe caused segmentation faults if an unsupported JLink Dll was loaded." Are you sure that you are using this version (can be checked with 'nrfjprog --version'). Could you also try installing the latest version (10.7.0) of the Command Line Tools?

[Rasmus]

Yes, the voltage is okay. 
Strange that Im getting segfult then.. but I will try with the latest version 10.7.0.

We have an other CPU that is controlling the BLEchip by its RST-pin, to make som testes I deactivate pin 24 (port 21) as RST pin. My 10-pin debug connector is using the RST-pin. Could that be the cause to segfault? I did this by commenting out lines 199-212 in system_nrf52.c

    /* Configure GPIO pads as pPin Reset pin if Pin Reset capabilities desired. If CONFIG_GPIO_AS_PINRESET is not
      defined, pin reset will not be available. One GPIO (see Product Specification to see which one) will then be
      reserved for PinReset and not available as normal GPIO. */
    #if defined (CONFIG_GPIO_AS_PINRESET)
        if (((NRF_UICR->PSELRESET[0] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos)) ||
            ((NRF_UICR->PSELRESET[1] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos))){
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[0] = 21;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[1] = 21;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NVIC_SystemReset();
        }
    #endif

Best regards /Rasmus