nrf52832 debug mode

RE: nrf52832 debug mode

Hung Bui — Fri, 12 Jul 2019 12:15:39 GMT

You can use normal softdevice flash api (sd_flash_*) to access UICR

RE: nrf52832 debug mode

Sami — Sun, 07 Jul 2019 16:44:42 GMT

Hello, can you please specific which exact Soft Device API to use in order to write to the NVMC to disable debug mode.

I'm using nRF52832, SDK 11.0.0, and S132. Thank you!

RE: nrf52832 debug mode

endnode — Tue, 16 Jan 2018 08:10:40 GMT

Alternative to writing to UICR->APPROTECT? No. What is wrong with it?

RE: nrf52832 debug mode

sreehari410 — Tue, 16 Jan 2018 07:29:22 GMT

@endnode Is there any alternative method to disable the debug mode?

RE: nrf52832 debug mode

Hung Bui — Tue, 09 Jan 2018 10:21:19 GMT

Yes, if you have a glitch in your code that erases the whole UICR then you will unlocked the chip.

RE: nrf52832 debug mode

endnode — Mon, 08 Jan 2018 13:30:32 GMT

Oh my bad! So does it mean that read-back protection (and debugger "kill switch") can be re-enabled from FW and if you do some security hole in there then you can end-up with unlocked chip?

RE: nrf52832 debug mode

Hung Bui — Mon, 08 Jan 2018 13:20:24 GMT

Actually, on nRF52 series, it's possible to erase UICR without erasing the chip. Check ERASEUICR register in NVMC.

RE: nrf52832 debug mode

endnode — Fri, 05 Jan 2018 21:46:54 GMT

If you don't have Soft Device running then this is the way to write to NVMC (including UICR). If you have Soft Device running then you need to use SD API for flash access. It's not necessary to disable SD just because of this operation. The main problem is: the fact that APPROTECT blocks most of SWD debugging interface except "recovery" procedure is irreversible unless you wipe the whole chip. So there is actually no way you would revert this later from your FW. There would be wild scenario of trying to erase UICR from within the FW and do reset which would be basically "suicide" from the FWs point of view. However even if this is possible it is useless: you would need to attach SWD debugger to program the chip again so why erasing it from within when the debugger can do it any time...