nRF52832 locks after programming

RE: nRF52832 locks after programming

Einar Thorsrud — Fri, 12 Jun 2020 12:32:27 GMT

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

RE: nRF52832 locks after programming

Caelus — Fri, 12 Jun 2020 07:51:11 GMT

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

RE: nRF52832 locks after programming

Caelus — Thu, 11 Jun 2020 16:17:16 GMT

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.

RE: nRF52832 locks after programming

Einar Thorsrud — Thu, 11 Jun 2020 12:21:24 GMT

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?

[quote user=""]Do you know any way to unlock the microcontroller? Am I missing something?[/quote]

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.