RE: ERASEPROTECT Write and rewrite

Håkon Alseth — Tue, 26 Jan 2021 12:59:02 GMT

Hi,

[quote user=""]

And I would like to add:

NRF_UICR->ERASEPROTECT = 0x00000000;

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

NRF_UICR->ERASEPROTECT = 0x00000000;

However, I want to be sure that I can recover my device in this case. I was planning to add a function that reset the ERASEPROTECT register to 0xffffffff and that can be set through an UART command.

- Would that work?

[/quote]

Enabling the protection through uart (or any other trigger) can work, but note that UICR is a special region.

ERASEPROTECT is a part of UICR, and cannot be erased from the CPU, as per the PS:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/nvmc.html?cp=2_0_0_3_3_1#concept_erase_page_code_memory

You can read here on how to disable ERASEPROTECT (and perform an unlocking operation):

https://infocenter.nordicsemi.com/topic/ps_nrf9160/chapters/dif/ctrl-ap.html?cp=2_0_0_8_1_3#ctrlap_unlocking

[quote user=""]The second question I have is on the CTRL_AP_PERI_S.LOCK register. If I write it in the firmware, the only way to recover the device is by doing an erase ALL. But in this case the debugger and the firmware must have the same key in the ERASEALL.DISABLE.KEY field. I was planning to use the JLink commander and use the following:[/quote]

If you lock down the device using ERASEPROTECT, the way to recover is that the debugger and CPU writes the same key into the ERASEPROTECT.DISABLE register.

There is also a added security seen from the CPU side wrt. this locking:

The CPU can only write into the ERASEPROTECT.DISABLE register if register ERASEPROTECT.LOCK is in a writeable state.

The locking mechanism is to avoid brute-force attack from the debugger.

[quote user=""]

Assuming that 0xDEADBEEF is also in the CTRL_AP_PERI_S.DISABLE (NRF_CTRL_AP_PERI_S->ERASEPROTECT.DISABLE in the code) register of the device.

With that procedure, will the device be erased? I want to be sure that the SWD command will still work as APPROTECT is on..

[/quote]

Yes, if the CPU and the debugger has both written the same key, in this case 0xDEADBEEF, to its respective register; then it shall unlock and erase the nRF9160.

Process will look similar to this:

* Your fw writes non-zero key to ERASEPROTECT.DISABLE

* Your debugger writes the same non-zero key using SWDWriteDP to the similar exposted register over the debug interface

* Wait for the ERASEALL operation to finish (see t_ERASEALL)

* Do a pin-reset (or power cycle)

Note that ERASEPROTECT and APPROTECT are two different locking mechanisms. You can enable ERASEPROTECT without setting APPROTECT, thus the debugger can write into the CPU mapped register for debugging/testing purposes:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/chapters/dif/ctrl-ap.html?cp=2_0_0_8_1_1#ctrlap_erase

Kind regards,

Håkon