RE: Debug port access port protection disabled after firmware wrote NRF_APPROTECT.DISABLE with 0

Anthony Ambuehl — Thu, 04 Sep 2025 16:10:49 GMT

Hi Einar, I found that the mcuboot bootloader had CONFIG_NRF_APPROTECT_USE_UICR=y. The nrfjprog tool was sending a reset and taking control while the mcuboot bootloader was initializing.

After fixing mcuboot, its no longer an issue.

RE: Debug port access port protection disabled after firmware wrote NRF_APPROTECT.DISABLE with 0

Einar Thorsrud — Thu, 04 Sep 2025 14:48:05 GMT

Hi,

I do not see how AP Protect could be disabled with the sequence you copy-pasted from the command line. nrfjprog can disable AP protect by performing a recover operation (erase all), but that is intentional and is not shown here. Do you do something else to the device int he meantime that is not shown there?

I suspect that a bootlaoder may be part of this. As you write, you write the magic number 0x5A to diable AP protect to UICR->APPROTECT. So if any fortware component at any later time also writes to NRF_APPROTECT->DISABLE and there are no writes to NRF_APPROTECT->FORCEPROTECT, AP protect will be disabled.

I would start by testing with the application and bootlaoder separately to see if only one is needed to open the debug interface, and then look closer there to see if you can find where NRF_APPROTECT->DISABLE is written to (if you for instance build the bootlaoder before and did not configure it to lock the debug interface, it will be opened by this line in system_nrf52_approcet.h as UICR->APPROTECT has the magic number even if you have modified it when you subsequently built the application.