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

[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

[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

[Jørgen Holmefjord]

As far as I know, nrfjprog should not use the RST pin unless you perform a pin-reset using the --pinreset argument.