APPROTECT unclarities for NRF9151

[Sebastiaan Merckx]

Hello,

I have some unclarities for the APPROTECT mechanism on NRF9151.

Basically, I had a misunderstanding of the involved CONFIG features, and as a result I used CONFIG_NRF_APPROTECT_LOCK. However, the idea was that we could still unlock app protection via an OTA firmware update. This seems not possible now (since ERASEPROTECT is also enabled).

- Apparently, enabling CONFIG_NRF_APPROTECT_LOCK also implies that the UICR.APPROTECT is written to 0. I could not find where this is documented or explained. I was under the assumption that the UICR was not changed, so it would be possible to unlock the protection via FW update that sets NRF_APPROTECT_S->APPROTECT.DISABLE. properly. But apparently that's not the case. I could also not find in the code where this is executed. It's not applied in "system_nrf91_approtect.h".

- The reset value of UICR.APPROTECT is not 0xffffffff, but 0x50FA50FA. This is confusing (https://docs.nordicsemi.com/bundle/ps_nrf9151/page/uicr.html#ariaid-title3). It also means that the "hardware and software" AP-Protect implementation type of the table on https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/ap_protect.html is not enabled by default on NRF9151, on the contrary.

- To me, the table at https://docs.nordicsemi.com/bundle/ps_nrf9151/page/dif.html#d425e281 is not clear. I assume now that it means for the "debugging possible" rows, all conditions must be true whereas for the "No debugging possible" rows, debugging is not possible as soon as 1 of the conditions is true. Is this correct?

- Also on https://docs.nordicsemi.com/bundle/ps_nrf9151/page/dif.html, APPROTECT.DISABLE and APPROTECT.FORCEPROTECT eventually are the same register, but that's pretty hard to understand from the text until you look either to the code or the effective address. What's the reason for this split?

I suppose that there's no way for me to recover the devices (i.e. enable debug access) that were flashed with CONFIG_NRF_APPROTECT_LOCK? That's not a disaster, since they will later be used in the field, but it would be nice to know.

S.

[Maxime_ADS]

I also have some unclarities for the APPROTECT mechanism on NRF9151.

 

There is this statement in the Nordic documentation:
On the nRF91x1 Series devices, the register setting related to the CONFIG_NRF_APPROTECT_LOCK Kconfig option does not persist in System ON IDLE mode. You must lock the UICR.APPROTECT register to enable the hardware AP-Protect mechanism as instructed in Enabling hardware AP-Protect by locking the UICR.APPROTECT register.

 

As instructed in the "Enabling hardware AP-Protect by locking the UICR.APPROTECT register.",
we must use nrfutil with this command "nrfutil device protection-set All"

 

We tried this method, but it proved unusable because the nRF9151 automatically locks the device shortly after startup.
We attempted to disable the automatic locking by setting CONFIG_NRF_APPROTECT_USER_HANDLING=y, but without success.
It seems that the nRF9151 enables AP protection when we disable our UART with this line of code:
pm_device_action_run(uart_dev, PM_DEVICE_ACTION_SUSPEND);
After this line, the debugger is disabled, and we can no longer enable hardware AP protection with "nrfutil device protection-set All".

 

My question is:
How can we disable the automatic activation of the lock when the serial port is suspended (so that we can enable hardware AP protection with nrfutil)?

[Vidar Berg]

Hello,

Steps to ensure APPROTECT remains disabled across reboots:

1. Use nrfutil device recover before programming the FW. In addition to disabling the approtect mechanism it will write the 0x5a to UICR.APPROTECT in order to disable the hw protect mechanism

2. Ensure CONFIG_NRF_APPROTECT_USE_UICR is selected (is by default). With this configuration the startup code will load the whatever is stored in UICR.APPROTECT into the APPROTECT.DISABLE in RAM on boot.

The reason approtect becomes enabled again after suspending the UART is that the APPROTECT.DISABLE register loses its retention, see errata #36 Access port gets locked in WFI and WFE.