I was trying to program my sample to nRF5340's flash using nRF connect v4.0.0 and when i click flash i got this problem:

[Wiem]

[error] [ Client] - stderr: [*** LOG ERROR #0001 ***] [2023-03-22 10:37:45] [nRF53] {argument not found}

Failed to enable coprocessor with unknown error.
ERROR: Access to the selected address is blocked by the SPU.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 37: nrfjprog --recover -f NRF53 --coprocessor CP_NETWORK --snr 1050024693

[John Borsting]

Hi

I get exact the same error messages when I try to flash a nRF5340DK with an example of matter SmartPlug or light_switch.

When compiling for the nRF52840DK the flash programming works fine.

[Joe Kane]

Nordic Team,

I was also able to get an NRF5340DK board in this same state with these exact errors, shortly after upgrading to nrfconnect for vscode extension version: Version 2023.4.148. After debugging for a while, programming failed once and then wouldn't recover.

 No amount of restarts/reboots/reset or 'recover board' worked using the Nordic VSCode add on from with VS Code.

Release notes had a lot of discussion regarding nrfprog changes, so maybe there is a script issue here.

For those still having the issue, I was able to bring the board back.

 Using NRF Connect for Desktop 4.0, install the standalone Nordic Programmer app, and do an "Erase" on the device.  This successfully recovered and erased the NRF5340, and then I was able to re-flash and debug etc within VSCode.

[John Borsting]

Hi Joe

Thanks for the input. It did erase the device but I still get the programming error when trying to flash using vscode:

"
* Executing task: nRF Connect: Flash: light_switch2/build (active)

Flashing build to 1050008458
C:\WINDOWS\system32\cmd.exe /d /s /c "west flash -d c:\Proj\LiqhtSwitch\light_switch2\build --skip-rebuild --dev-id 1050008458 --erase"

-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
-- runners.nrfjprog: Flashing file: C:\Proj\LiqhtSwitch\light_switch2\build\zephyr\merged_domains.hex
-- runners.nrfjprog: C:\Proj\LiqhtSwitch\light_switch2\build\zephyr\merged_domains.hex targets both nRF53 coprocessors; splitting it into: C:\Proj\LiqhtSwitch\light_switch2\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex and C:\Proj\LiqhtSwitch\light_switch2\build\zephyr\GENERATED_CP_APPLICATION_merged_domains.hex
[error] [ Client] - stderr: [*** LOG ERROR #0001 ***] [2023-05-23 13:46:44] [nRF53] {argument not found}

Failed to enable coprocessor with unknown error.
ERROR: Access to the selected address is blocked by the SPU.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 37: nrfjprog --program 'C:\Proj\LiqhtSwitch\light_switch2\build\zephyr\GENERATED_CP_NETWORK_merged_domains.hex' --chiperase --verify -f NRF53 --snr 1050008458 --coprocessor CP_NETWORK

* The terminal process terminated with exit code: 37.
* Terminal will be reused by tasks, press any key to close it.
"

It seems as there is missing an argument:
[error] [ Client] - stderr: [*** LOG ERROR #0001 ***] [2023-05-23 13:46:44] [nRF53] {argument not found}
The two hex files are present in the location, so it must be something else.

Are there some special settings of switches on the nRF5340-DK? I use:
Power source: VDD
Flow control: Both ON
nRF Only: Default

[Joe Kane]

John,

Regarding this:

[error] [ Client] - stderr: [*** LOG ERROR #0001 ***] [2023-05-23 13:46:44] [nRF53] {argument not found}
The two hex files are present in the location, so it must be something else.

I assume that the part may be stuck in some state, maybe some part of  boot or other flash persistence gets corrupted/doesn't program, and the script side of nrfprog may not have the logic to detect.

I was experiencing the exact same error, after thinking about it I may have done one additional step.

Are you able to flash with device while using the standalone programmer?

(after erasing with the standalone programmer)  I think I did program the part, using one of my previous (known good) hex files (still while using  with the standalone programmer program), once I was convinced it was back, I probably tried in VSCode.

You might also try compiling a different  example program for the board (just to get to a build a simple known good hex) and program that.

Does seem to me like this came on with the latest nrf update, which had lots of changes to nrfprog according to release notes.

[John Borsting]

Hello Joe

The programming was succesfull using the standalone programmer. And after tihs VSCode is programming too.

Thank you for your suggestions :-)

[Joe Kane]

John,

Glad I could help. I hope someone from Nordic is watching. There are some nrfprog issue(s) here. At the very least, nrfprog cannot repair/recover from certain programming errors but the standalone programmer exe can.

[Simonr]

Hi!

I just wanted to let you all know that we have reported this behavior internally. It would be helpful if someone had a way to recreate this behavior or know how we can put an nRF53 DK into this state so we can recreate it on our end as well.

Best regards,

Simon