RE: Overwriting UICR (NFCPINS) on nRF52833 (BC833M) – how to enable readback protection without losing configuration?

hmolesworth — Thu, 16 Apr 2026 22:57:24 GMT

You may be observing correct behaviour; once APPROTECT has been set at the noted address it will take effect following the next reset. Once APPROTECT is in force - following that first reset - all UICR registers are unreadable (all FF) and debug is disabled. Forcing the debugger to connect will erase the UICR to clear APPROTECT to allow debugging, which clobbers NFC io setting.

Bottom line is to test the NFC in the debugger APPROTECT must not be enabled. (unofficial response; hope it helps)

RE: Overwriting UICR (NFCPINS) on nRF52833 (BC833M) – how to enable readback protection without losing configuration?

EJViaTech — Thu, 16 Apr 2026 20:52:57 GMT

I wanted to provide an update on my previous issue regarding configuring UICR and enabling protection on a BC833M (nRF52833).

I am now generating a separate UICR HEX file and merging it with my application using mergehex:

:020000041000EA
:04120C00FEFFFFFFE3   ; NFCPINS = GPIO
:0412080000000000E2   ; APPROTECT enabled
:00000001FF

Merge command:

mergehex.exe -m application.hex uicr_config.hex -o combined.hex

After programming:

nrfjprog.exe -f NRF52 --program combined.hex --verify

I then read back the registers:

nrfjprog.exe -f NRF52 --memrd 0x1000120C
nrfjprog.exe -f NRF52 --memrd 0x10001208

Both return the expected values:

NFCPINS = 0xFFFFFFFE
APPROTECT = 0x00000000

However, when I subsequently connect a debugger, I observe that the NFC pins are no longer configured as GPIO (i.e., behavior suggests NFCPINS has reverted). I assume that the read is reading a non-latched value and once I connect a debugger to confirm the state, I am resetting and the register NFCPINS is as well.

Are there methods to have this written value persist through a reset?

Is there a known interaction between APPROTECT and UICR configuration that could cause this?