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.