ERASE_ALL protection disable nrf54

[vladL]

Hello,

I've been working on a feature lately that involves writing the OTP registers in UICR on nrf54L15; after writing the registers I also wrote the protected value (0x50FA50FA) to the ERASEPROTECT registers and this locked the OTP values in place.

Now I want to revert the development kit the previous state to perform some more testing and I saw that the erase protection can be disabled through the handshake mechanism where both the firmware and the debugger write the same key to the respective ERASEPROTECT.DISABLE register in the CTRL-AP.

I added the following piece of code to my application and reflashed it on the board:

NRF_CTRLAP_S->ERASEPROTECT.DISABLE = 0x12345678;

And tried the following sequence of commands on the JLink CLI:

SWDSelect

SWDWriteDP 1 0x50000000 // power up

SWDWriteDP 2 0x02000000 // select AP2 (CTRL-AP)

SWDWriteAP 4 0x12345678 // write erase prot. disable key (register index 4 in AP

I was expecting the ERASE_ALL procedure to be completed automatically as per the data sheet, but nothing happened to the UICR registers. I also tried to manually trigger the ERASE_ALL procedure by writing the debug-side registers through SWD, then reset the board and still no change.

 

There is obviously something I'm missing here, but I couldn't figure out what else needs to be done from the documentation. Could someone please confirm if my understanding of this feature is wrong and how should the code actually look like?

Thank you!

Vlad

[Elfving]

Have you written to the ERASEPROTECT.LOCK register? Have you reset it after trying to this handshake? And how are you reflashing the application here if eraseprotect is enabled?

Regards,

Elfving

[vladL]

I never touched the LOCK register; it reads zero always. I guess the debugger is able to overwrite the binary without a prior successful ERASE_ALL - hence the unchanged UICR values. Do you have some scripts that work with an NRF54? It would be really useful to compare my stuff with a proven configuration. Thanks! 

[Elfving]

Sorry about the wait, you can have a look at the script provided by my coworker here. Since it deals with the exact same issue there is some other resources there that might be interesting to you, like this that goes a bit further into checking whether eraseprotect is enabled. 

If this doesn't get you further, though, how are you resetting the device? 

Regards,

Elfving

[vladL]

Hello,

I did check the script in the other ticket, it can be used to successfully erase a chip that does not have erase protection enabled. For my scenario, I have a board that has erase protection enabled (UICR.ERASEPROTECT.PROTECT_0/1 both read 0x50FA50FA and CTRL_AP_ERASEPROTECT.STATUS on debugger side is 1, which means erase protection is enabled). At this point, I tried the following sequence:

- first invoke a shell command to the firmware running on the board, which writes a key value to NRF_CTRLAP_S->ERASEPROTECT.DISABLE (checked the address with a debugger read command afterwards and the key seems to be successfully written)

- then use the SWD commands I posted in the initial thread to write the same key to the debugger side register

- at this point I was expecting the erase_all to happen automatically; nevertheless, I also tried to manually invoke the erase all by writing to the debugger registers, also tried to reset, nothing seems to work.

After reset, all the OTP registers in UICR maintain the same values (so the erase_all does not happen). Am I misinterpreting the functionality of the ERASEPROTECT->DISABLE mechanism?

Thank you,

Vlad