**Setup**
- nRF54LM20 DK, board `PCA10184`, J-Link serial `1051845089`
- SoC target `nrf54lm20dk/nrf54lm20b/cpuapp` (EngB)
- nRF Connect SDK v3.4.0
- `nrfutil 8.1.1`, `nrfutil-device 2.19.0`
**What we are trying to do**
Production provisioning: write three `BL_PUBKEY` generations to the KMU over SWD,
then permanently disable debug access so the shipped unit cannot be read back,
while keeping `nrfutil device recover` available for RMA.
**What we observe**
`nrfutil device protection-set All` writes the UICR registers, but debug access
stays open:
```
$ nrfutil device protection-set All --serial-number 1051845089
$ nrfutil device read --address 0x00FFD000 --bytes 4 # UICR.APPROTECT.PROTECT0
0x00FFD000: 50FA50FA
$ nrfutil device read --address 0x00FFD01C --bytes 4 # UICR.APPROTECT.PROTECT1
0x00FFD01C: 50FA50FA
$ nrfutil device protection-get --serial-number 1051845089
core: Application
access status: Debug access is enabled (status value: None)
erase protection: false
$ nrfutil device read --address 0x0 --bytes 16 # still succeeds
0x00000000: 20007128 0000246D 0000885D 00002459
```
**What we ruled out**
1. *The UICR write did not land* — no, both `PROTECT0` and `PROTECT1` read back
as `0x50FA50FA`.
2. *Our firmware re-opens the port.* Our images are built with the Zephyr default
for this SoC, `CONFIG_NRF_APPROTECT_DISABLE=y`, so this was our first
suspicion. We erased the first RRAM page so nothing executes
(`nrfutil device erase --pages 0x0`, `0x0` reads `FFFFFFFF`). The port is
**still open**.
3. *Wrong reset type* — tried `RESET_SYSTEM`, `RESET_HARD`, `RESET_PIN`, and a
**physical power cycle** (both USB cables unplugged for ~10 s). No change.
4. *Silicon variant* — `nrf54lm20a_global.h` and `nrf54lm20b_global.h` both place
UICR at `0x00FFD000`.
Reading TAMPC directly, with no firmware present and after a power cycle:
```
TAMPC.PROTECT.DOMAIN[0].DBGEN.CTRL (0x500EF500) = 0x00000011 VALUE=1, LOCK=0
TAMPC.PROTECT.DOMAIN[0].NIDEN.CTRL (0x500EF508) = 0x00000011
TAMPC.PROTECT.AP[0].DBGEN.CTRL (0x500EF700) = 0x00000011
TAMPC.PROTECT.ERASEPROTECT (0x500EF980) = 0x00000010
```
The debug signal is high and unlocked, i.e. the boot sequence does not appear to
apply `UICR.APPROTECT` at all. `ERASEPROTECT` is off, as intended.
We found what looks like the same report in
**What does work**
Building with `CONFIG_NRF_APPROTECT_LOCK=y` (so `SystemInit()` writes
`TAMPC_SIGNAL_LOCK`) closes the port reliably:
```
access status: Debug access is currently disabled (status value: All)
```
memory reads fail, the device still advertises over BLE, and
`nrfutil device recover` brings it back — the full cycle works.
**Questions**
1. Is `UICR.APPROTECT` expected to be functional on nRF54LM20B EngB? Is
`0x50FA50FA` the value the hardware expects, or does APPROTECT use a different
encoding than `UICR.ERASEPROTECT`? The MDK header enumerates only
`Unprotected (0xFFFFFFFF)` for APPROTECT, while ERASEPROTECT explicitly
enumerates `Protected (0x50FA50FA)`.
2. If this is an EngB limitation, is it fixed in production silicon? We would
rather not redesign our provisioning flow around a temporary behaviour.
3. Is the firmware branch (`CONFIG_NRF_APPROTECT_LOCK`) the intended production
mechanism for this SoC, or only a development aid? It leaves a window between
reset and `SystemInit()` in which the AP is open, which is exactly what the
UICR branch is meant to eliminate.
4. Our DFU updates the application only, so the MCUboot that ships on the unit is
the one flashed at the factory station — and that one must keep the port open,
because the KMU keys are provisioned over SWD after it first boots. That means
MCUboot re-opens the AP on every boot before the application closes it again;
during a swap this window is ~40 s. Is re-flashing a second MCUboot built with
`CONFIG_NRF_APPROTECT_LOCK=y` as the last factory step the recommended
approach, or is there a supported way to have the UICR close it instead?
5. Is there a documented recommended ordering for KMU provisioning plus
AP-Protect on nRF54L in production?
Thanks.
