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.

[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. 

[Sebastiaan Merckx]

Hi Vidar Berg 

I have a follow-up question. After activating the erase protection (via "nrfutil device write --address 0x00FF8030 --value 0x0"), I am still able to flash the firmware via nRF Connect in vsCode, which uses "nrfjprog".

However, when using the nrfutil for flashing instead of nrfjprog, this does not work. I have also tried other chip_erase_mode. It seems to me that nrfutil is doing a too explicit check.

Version: nrfutil 8.0.0 (54d8087 2025-01-07)

PS C:\Users\sebas\Downloads> ./nrfutil device write --address 0x00FF8030 --value 0x0
✔️ Data written to 50111305
PS C:\Users\sebas\Downloads> ./nrfutil device program --firmware merged.hex --options chip_erase_mode=ERASE_RANGES_TOUCHED_BY_FIRMWARE
[00:00:00] ------   0% [1/2 50111305] Failed, Device error: Cannot erase flash pages, device is erase protected                                                    Error: One or more program tasks failed:
 * 50111305: Device error: Cannot erase flash pages, device is erase protected (Generic)

[Vidar Berg]

Hi, 

To enable the Erase all protection you need to perform a reset after setting the UICR.ERASEPROTECT register. But I agree, nrfutil device should not have aborted the erase just because the register was set. I will relay this feedback to the developers.

[Sebastiaan Merckx]

This does not work:

PS C:\Users\sebas\Downloads> ./nrfutil device write --address 0x00FF8030 --value 0x0
✔️ Data written to 50111305
PS C:\Users\sebas\Downloads> ./nrfutil device reset
✔️ Reset was applied to 50111305
PS C:\Users\sebas\Downloads> ./nrfutil device program --firmware C:\Users\sebas\WaldenBox\git\wb-nrf9151\nrf9151\build\merged.hex --options chip_erase_mode=ERASE_RANGES_TOUCHED_BY_FIRMWARE
[00:00:00] ------   0% [1/2 50111305] Failed, Device error: Cannot erase flash pages, device is erase protected
Error: One or more program tasks failed:
 * 50111305: Device error: Cannot erase flash pages, device is erase protected (Generic)

[Vidar Berg]

Yes, so this is as expected since you have enabled the erase all protection. I assume you’re also unable to reprogram the chip with nrfjprog now as well?