nRF52832 locks after programming

[Caelus]

Dear Nordic Team,

I have developed a custom board using a nRF52832 QFAAB0 chip.

I am using SDK 15.3 and the ble_template example as starting point of developing  my code and the Segger Embedded Studio as IDE.

Once my code is compiled (no errors and warning, and compiled with level0), I flash the FW to the microcontroller and start a debug session. I can flash the microcontroller but once the debug session starts, the field value field of the variables shows "memory not readable"

Then If I try to erase or re-flash again the chip, I get the error "unable to connect". So I can't erase / flash the chip anymore.

Reading in the forum, I followed the steps to try to recover the chip, by using the Jlink tool or th nRFGo Studio. However, both tools are not able to connect to the microcontroller.

After this, I  decided to check the HW, and I noticied that the powe supply is OK (3,3V) and there is not any shorts.

As a final test, I decided to run the same code on a Thingy or a PCA10040 (both with nrf52832) and I am able to erase / flash and debug the code.

Do you know any way to unlock the microcontroller? Am I missing something?

Thanks a lot for your support. Kind Regards, 

               Caelus

[Einar Thorsrud]

Hi,

You write that the same code only has this effect on the custom board. Does that mean that the very same .hex file is tested on the Thingy or DK, or are there small variations? I ask because it could be that a hex file includes the APPROTECT register, and if so, the debug interface would be disabled after programming and resetting. But then this would be the same for all boards.

Alternatively, could it be that the SWD pins or reset pin is connected to a GPIO in your custom HW, and that your firmware configures the GPIO and that causes problems?

Do you know any way to unlock the microcontroller? Am I missing something?

In most cases you can use "nrfjprog.exe --recover", but if the SWD lines are "tampered with", as suggested above, then you will need to modify the HW in order to recover.

[Caelus]

Hello Einar,

Thank you very much for your quick response.

The hex file is the same for my custom HW and for the Thingy and NRF2DK. In fact, I am able to debug with the Thingy and NRF52DK without any problem. So, I think that we would be agree that the root cause is not the APPROTECT. (but thanks for the suggestion)

In my custom board, the  SWD pins are just for programming and are not share. However, the reset pin is connected to a LED. On the other hand, I have not modifed the contents of the registers PSELRESET[x], so as they contains the default configuration (0xFFFFFFFF)

According to the NRF52832 PS document, that means that the content of field A is 21 and field B is "disconnected". I understand from this that the reset is disabled in the GPIO21 and then, this pin acts as GPIO. Is it right?

I will try later the nrjprog.exe --recover to recover the chip. I will keep you posted with the results.

[Caelus]

Hello Einar,

Yes, indeed. The problem is solved.

I modified the custom board by placing a pull-up resistor of 4K7 in the reset line and it works.

Now I can debug my code and work on my HW.

Now you may close this ticket. Thanks a lot for you support.

Kind Regards,

           Caelus

[Einar Thorsrud]

Hi Caelus,

Thanks for lettings us know.

By the way, if you want the reset pin to act as a GPIO only that should not be a problem, but then you must not configure it as a reset pin in the UICR (it is a normal GPIO by default). If that is not something you did deliberately, then perhaps you have CONFIG_GPIO_AS_PINRESET defines for your project, which will make the hex file include data in the UICR region for PSELRESET. This is the default for most SDK examples and will enable pin reset on the first reset after programming.

Einar