Why does setting APPROTECT in the program require a reset before taking effect?

[Elias]

I am developing on the nRF52832. I just discovered that if my program enables Access Port protection by writing the UICR at runtime, then the program can still be read out of the chip until the next restart. It's fine that my system has this behavior, but I would like to know the reason for this.

The "Debug and trace" section of the Product Spec don't seem to mention this. Is this behavior specific to the Nordic design? or a part of the ARM CoreSight specification?

[wpaul]

The APPROTECT register in the UICR is really a non-volatile storage location. It doesn't control the behavior of the device's internal logic. During power on or reset, the CPU will sample the value stored there, and that's when it will decide whether the debug access port should be enabled or not.

As to whether this behavior is specific to Nordic or not, it's something that you do sometimes see in other devices. For example, some NXP Kinetis Cortex-M processors use specific flash locations to store the default security register values. The actual registers with directly control security behavior are located elsewhere, but at start-up the CPU will use the values in those special flash locations as the initial values. (And much like the nRF52 chips, if you enable security, you have to use a mass-erase command to reset the flash in order to recover.)

Similarly, some ST Micro devices have external pins that let you force the CPU to boot from internal DFU ROM instead of from flash. The CPU also only samples the state of these pins at power on or reset.

-Bill