Custom nRF5340 board application core access protection

[Ethan Peck]

I am working with a custom PCB using an nRF5340 (integrated in the Fanstel BT40F module) and both a J-Link base device and the nRF5340DK as a debugger/programmer (i.e. I have attempted using both devices). I am able to flash firmware to a new device successfully the first time after running the 

nrfjprog --recover

 command, but any attempts beyond this yield a variety of access protection errors that can't be undone by either a rerun of the recover command or attempting to erase all memory. I have outlined my programming process for both the J-Link and DK below:

J-Link Debugger:

The device is connected using serial wire debug through a tag connect header to my debugger. Upon initial setup I first open jlink commander and connect the device using the connect command and the built in nRF5340 application core option. This runs successfully initially. I then go into VS Code with the nRF connect extension (as well as the toolchain and all other requirements installed). I can build and flash the code from our companies firmware team once successfully after running the first erase all/recover command, but any subsequent attempts result in the following error when flashing:

and the following error when attempting to manually run the --recover command:

DK Programming:

I first connect the tag connect header to the 10pin header P19 on my V2 development kit. The device is recognized successfully and I can attempt to flash. I then receive these same errors when attempting to program through the development kit as well. Any guidance on how to bypass the access protection beyond the steps I have already tried would be much appreciated.

[Vidar Berg]

Hello,

When working on the nRF53, it is important to 'recover' the network core first, as explained here: 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.6.0/nrf/device_guides/working_with_nrf/nrf53/nrf5340.html#readback-protection 

Please try this to see if it works. If it doesn't, then the issue could be that the FW programmed you are programming after the recovery is not unlocking the approtect mechanism in the software.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/security/ap_protect.html#enabling-access-port-protection-mechanism 

Best regards,

Vidar

[Ethan Peck]

I forgot to mention in my original post that I have also attempted to run recover with the appropriate coprocessor flag. This is the error I get when recovering the network core with the development kit:

And this is the error I get when I specify the correct family:

I have also attempted the same command with the J-Link debugger connected to my custom board and get this error:

I have checked the firmware and there is no mention of UICR.APPROTECT, but I also see no mention of it in some of the nRF same programs such as BLE Central UART. Is this a requirement specifically for the nRF53 series that isn't implemented in these examples? And if so is there an example that I could provide to our firmware developers to update? Thank you!

[Vidar Berg]

Hi,

Thanks for confirming. The SDK disables APPROTECT by default. Even if it were enabled, this would not explain why the nrfjprog recover command is failing.

Please try the following:

1. Ensure your nrfjprog install is up to date (nRF Command Line Tools). You can check which version you have installed with 'nrfjprog -v'. 

2. Run the recover at a lower SWD clock speed to see if it becomes more reliable.

$ nrfjprog --coprocessor CP_NETWORK --recover -c 4 && nrfjprog --recover -c 4

3. Measure the I/O voltage on the target after you've programmed your FW and see if it matches the VTref voltage displayed in Jlink commander (jlink.exe on Windows, or JLinkExe on Linux/MacOS).

Thanks,

Vidar

[Ethan Peck]

Hello Vidar,

I have checked my nrfjprog version and it is up to date according to the page for nRF command line tools:

I also ran recover at a lower SWD clock speed as suggested and got the following similar errors as before:

I also tested the VTref voltage and got the following which matches the voltage read when using a multimeter on the board.

[Ethan Peck]

The low VTref ended up being the cause! The chip was getting 2.0V due to an issue with the power/charge circuitry on the board which was causing me to be able to detect the chip but not actually program or recover it. Didn't realize 3.3V was needed until a discussion with our firmware developer earlier today. Thank you for your assistance!