Memory readback protection on the nrf5340

[kpreiss]

Hi,

What is the process for locking the app and network cores on the nrf5340 from allowing someone to read the internal flash memories using a debugger via SWD?  Then what would be the process for "unlocking" the part should we want to reprogram it.

Thanks.

[Raoul]

Hi,

This is controlled by the Control Access Port, please take a look at this documentation page: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fctrl-ap.html&cp=3_0_0_7_9

and this related question on DevZone:  nRF5340 NVS and readback_protection

Best regards,

Raoul

[kpreiss]

Does this mean that if the DEBUG port is locked, the micro flash can never be programmed again using the debugger?

[Raoul]

Not at all, you can always recover the device by performing an ERASEALL, after which the debug access port is opened. The only consequence is that you lose the firmware image on the device. The main purpose of this APProtect is to prevent unwanted firmware readout of devices in the field.

In practice, when you encounter a locked device in NCS (through for example the VS Code extension), you'll have to option to perform a "recover" operation, which erases all firmware ("ERASEALL") and opens the access port. Then, when you flash new firmware to the device, this firmware can be configured to keep the debug access port open (useful during development) or let it remain closed (which is strongly recommended for production).

This blog post has more information on the new "hardened" access port protection, which can also be found in the nRF5340:  Working with the nRF52 Series' improved APPROTECT

Best regards,

Raoul

[kpreiss]

Thank you.  Perfect.

[Raoul]

Glad to hear!

[kpreiss]

Is there a way to set the UICR->APPROTECT address to 0 using JLINK commander script?  We tried using the  following script "loadfile approtect.bin, 0x00FF8000" after writing all images into the flash.  The approtect.bin just contains the 32-bit value (0x00000000) to enable protection.  The entire flash memory appears to be erased by calling the above script.

We can write all the images using JLINK script, then use nrfjprog to write 0 to UICR->APPROTECT (nrfjprog -f NRF53 --memwr 0x00ff8000 --val 0 -- force) and it does work.  However, we would prefer to do everything through JLINK Commander if possible.

Thanks!

[Raoul]

Hi, could you try the following command with J-Link Commander?

W4 0x00FF8000 0x00000000

W4 is the command that writes 32 bit values to memory. I got this from the Segger Wiki: https://wiki.segger.com/J-Link_Commander#Write4

Let me know if that works for you!

Best regards,

Raoul

[kpreiss]

Hi Raoul,

After performing this step, the application no longer runs.  It appears that the app core flash memory somehow gets erased after this step.

Kurt

[Raoul]

Hi Kurt,

I'll see if I can find out how to do this via J-Link Commander.

I hope it's acceptable for you to use nrfjprog in the mean time. This post by my colleague is a nice reference on using readback protection through nrfjprog.

Best regards,

Raoul

[Raoul]

Hi again,

I've been informed that JLink Commander won't be able to set this correctly. Without going into all the details, nrfjprog and JLink Commander work slightly differently, and the APPROTECT register is not an ordinary register.

Using nrfjprog is an extra step, but I hope it's acceptable.

Best regards,

Raoul