How to unlock a locked nRF54L10

[Август]

Hello,

   Our product has reached the final mass production stage, but we need to add a lock function to prevent erasure and access to the programming/debug port.
    
   nRF54L10  ncs3.2.3
   
   I have performed the following operations:

    @Echo Off

nrfutil.exe device recover --traits jlink --x-family nrf54l

nrfutil device x-write --address 0x00FFD060 --value 0x50fa50fa  --x-family nrf54l

nrfutil device x-write --address 0x00FFD07c --value 0x50fa50fa --x-family nrf54l

nrfutil.exe device x-provision-keys --key-file keyfile.json --traits jlink --x-family nrf54l

nrfutil.exe device program --options chip_erase_mode=ERASE_RANGES_TOUCHED_BY_FIRMWARE --traits jlink --x-family nrf54l  --firmware merge.hex

nrfutil.exe device fw-verify --firmware merge.hex

nrfutil.exe device protection-set ALL

nrfutil.exe device reset --reset-kind RESET_PIN

So how can I unlock it through my code? My code has an upgrade function.

[Menon]

Hello,

I understand your confusion, and what you said is correct, debug access is denied when APPROTECT is enabled. However, you can still access the device via CTRL-AP. Please refer to the script I shared in my first response. It is a J-Link script, so you need to use J-Link Commander here, not nrfutil.

Kind Regards,

Abhijith

[Август]

Hello Abhijith,

Thank you so much for your help! This information is really helpful and solved my problem perfectly.

I have another question: since ERASEPROTECT is enabled, I cannot write to UICR_ERASEPROTECT_PROTECT0 and UICR_ERASEPROTECT_PROTECT1. If we want to write these registers in code, we need to erase the UICR first.

Do you have any other solutions or methods to write these UICR registers?

Thank you very much for your support!

Kind Regards,

Abryct

[Menon]

Hello,

Август said:

Do you have any other solutions or methods to write these UICR registers?

Once the value is written, you need to perform an eraseall to overwrite the UICR. However, with ERASEPROTECT enabled, eraseall cannot be performed

See the section UICR. I don’t think there is an alternative for this. This behavior is likely intentional, as it is designed as a security measure for final production.

Kind Regards,

Abhijith

[Август]

Hi Abhijith,

Thank you for the clarification.

This requirement comes directly from our customer, and we’re just trying to verify the production flow. To test the behavior, we took one board and enabled ERASEPROTECT and APPROTECT as per the specification.

The result confirms what you mentioned: once these protections are set, we can no longer perform eraseall to modify the UICR registers. Therefore, firmware updates will only be possible via application-level updates (OTA/DFU) after this step.

This is a good confirmation for our production process.

Kind regards,

Abryct