Unable to find or open the JLinkArm dll; can not connect to the device; code lenght of region 0 could not be retrieved from device; can not connect to the device

[plamenbalk]

Hi,

I've been using nRFgo studio to program hex files to the board.

Most of the time it has been working trouble free.

However, a while ago we got one, and than one more damaged boards.

If I connect the failing to communicate wiht board after a properly working one the message is: "code lenght of region 0 could not be retrieved from device; can not connect to the device"

If I start nRFgo and try to connect with the faulty board the messages are: "Unable to find or open the JLinkArm dll" or "can not connect to the devic" if I try to read.

NB! this is valid only for the failing boards. They stopped working while my colleague was debugging the code.

Please advice

[Kenneth]

Hi,

I suggest to use our command line tool for programming:
https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF5-Command-Line-Tools/Download#infotabs 

Then you can type for instance 'nrfjprog --recover' to erase the chip, and 'nrfjprog --progam filename.hex' to program:

If you have issues programming I suggest that you make sure to pull reset pin to VDD and call 'nrfjprog --recover'. It is a common problem that during development sometimes you enable pin reset and set the pin as low output, then it will go into a reset state until pulled high externally.

nRFgo Studio isn't really maintained anymore.

Best regards,
Kenneth

[plamenbalk]

Hi Kenneth,

Thanks a lot for your tips.

It helped to recover one board. Let's call it board 1.

Still - two that I could not fix this way.

1. Board 2. Worked ok, could be programmed etc. as long as the reset pin was powered. As soon as I remove the supply to it, the failure behaviour was back. Any further idea what to do?

2. Board 3. The reset pin is high. Still the same error messages. More ideas?

Thanks / Plamen

[Kenneth]

Hi,

It may related to your firmware enable pin reset in some way? Can you check if you may have defined CONFIG_GPIO_AS_PINRESET in preprocessor symbols?

Or in system_nrf52.c make sure to comment out the following, this will for sure avoid pin reset may be accident enabled in firmware:

    /* 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,
Kennethy