APPROTECT is not enabled with CONFIG_NRF_APPROTECT_LOCK on nRF52832, only nRF52840.

[FARLY7]

I have two devices:

• NRF52832_xxAA_REV2
• NRF52840_xxAA_REV3

Running the Zephyr blinky sample application with the following KConfig option added:  

CONFIG_NRF_APPROTECT_LOCK=y

 

On the nRF52840 device, debugger access is correctly disabled.

On the nRF52832 device, debugger access is incorrectly still enabled.

 

I need to add the following code to my project to disable debugger access on the nRF52832.

if (NRF_UICR->APPROTECT == 0xFFFFFFFF)
{    
    uint32_t value = 0xFFFFFF00;

    LOG_INF("* Disabling access port *");

    err = flash_write(flash_device, (uint32_t)&(NRF_UICR->APPROTECT), &value, 4);
    __ASSERT_NO_MSG(err == 0);
    
} else {
    LOG_INF("Access port already disabled");
}

Why is this? There are similar questions already posted on the DevZone but unfortunately no answer other than use nrfjprog to disable debugger protection.

Thanks,

Sean

[Einar Thorsrud]

Hi Sean,

This is intended behavior, though it may look a bit odd. The explanation is that revision 2 of the nRF52832 has the old APPROTECT mechanism, which is only HW based. Revision 3 of both nRF52832 and nRF52840 has a newer APPROTECT mechanism which is based on both HW and SW. You can read more about the two mechanisms under Access port protection in the product specification.

In short, CONFIG_NRF_APPROTECT_LOCK=y will make the firmware write to a non-perstistent register (APPROTECT.FORCEPROTECT) during startup, which locks the debugger access regardless of what is configured in the UICR for the latest revision devices with improved access port protection. It does not make any difference on older devices. This option does not write anything to the UICR.

To prevent debugger access on older devices, you need to write 0x00 to the APPROTECT register in UICR. On those devices this is the only thing that affect debugger access. The SDK does not include code for setting this, but you can do it runtime as is done with the snippet you included in your original post, or for instance by writing specifically to the UICR.APPROTEC register via a debugger.

Einar

[FARLY7]

Hi Einar,

Very clear answer, thank you! I fully understand now.

One small correction, I think you meant to say "revision 2 of the nRF52832 has the old APPROTECT mechanism"?

Thanks,

Sean

[Einar Thorsrud]

Hi Sean,

That is good to hear. You are right, it is revision 2 that (and older) that has the old APPROTECT mechanism. I have updated my original reply. Thanks for letting me know!

Einar