nrfutil [jlink] INTERNAL_ERROR, code: Nrfjlink

[Raffael]

Hi,

I am unable to use the new nrfutil to do even a device reset of my devkit. I have installed the recommended segger version and the apple-silicon version of nrfutil on my Macbook M3 machine (tested on my colleague's M2 as well with the same result).

The output of --version is normal:

>> nrfutil device --version      
nrfutil-device 2.7.5 (6460d8f 2024-11-07)
commit-hash: 6460d8f68cc20bfb87b93a5311d4afe388a7a44f
commit-date: 2024-11-07
host: aarch64-apple-darwin
build-timestamp: 2024-11-07T10:21:59.397001000Z
classification: nrf-external

Detected SEGGER J-Link version: JLink_V7.94i

It can also detect the connected nrf52840-DK without problems:

>> nrfutil device list     
1050321577
product         J-Link
board version   PCA10040
ports           /dev/tty.usbmodem0010503215771, vcom: 0
                /dev/tty.usbmodem0010503215773, vcom: 1
traits          devkit, jlink, seggerUsb, serialPorts, usb

Found 1 supported device(s)

However, when attempting to reset, erase or flash code to my target, I consistently get the following error message (here copied from an NRF5340 DK, all my devkits show the same behaviour):

nrfutil device reset    
❌ Failed to reset 960140919, [jlink] INTERNAL_ERROR
Error: One or more reset tasks failed:
 * 960140919: [jlink] INTERNAL_ERROR, code: Nrfjlink

I have updated the j-link firmware using JLinkConfig. I also managed to directly use the JLinkExe tool to connect, reset, erase and flash to that same target successfully.

One thing that strikes me there in the console ouptut is the following (again from the NRF5340 DK, but equivalent result on the other DKs I have):

Found Cortex-M33 r0p4, Little endian.
Cortex-M: The connected J-Link (S/N 960140919) uses an old firmware module: V1 (current is 2)
Cortex-M (ARMv8-M and later): The connected J-Link (S/N 960140919) uses an old firmware module that does not handle I/D-cache correctly. Proper debugging functionality cannot be guaranteed if cache is enabled

Is this the thing nrfutil cannot handle? Are really all my devkits too old already?

Thanks for any help in advance!

[Charlie]

Thanks for the update.

I will try to get help from colleague with M2 MacBook to see if we can repeate this issue.

[Raffael]

anther clue: I've had the same issue like  Flashing issues after updating Command Line Tools on macOS

sudo also allowed me to run the latest verstion (10.24.2) of nrfjprog, without sudo it would fail.

Reverting to 10.24.0 allowed me to run nrfjprog without sudo.

Is there any previous version of nrfutil available to download?

[Charlie]

Disabling "sudo" on MacOS is out of support scope, you need to become an admin user for you system. See How to disable sudo command in Terminal - Apple Community.

nRF Command Line Tools - Downloads - nordicsemi.com all pervious versions are avaliable in download page.

[Raffael]

Hi Charlie, I was actually inquiring about previous versions of the nrfutil tool, they are not on available on the site of the cmd line tools.

Like mentioned, sudo is not required for a previous verison of the command line tool. So my hope is that a previous version of nrfutil would also resolve this issue.

In any case, it seems that something in the background of the newest tools for Mac require sudo (at least on all our machines), something that was not required previously. If its an easy fix we would be glad to see this resolved in future updates of both tools.

[Charlie]

Hi,

I discussed your issue with our development team today, and here’s a deeper explanation regarding nrfutil rolling back and some troubleshooting steps for your original problem.

Regarding rolling back nrfutil:
The current version of nrfutil you download is a "thin" binary that bootstraps the core functionality as a package. Once initialized (this happens automatically on the first run), you can install and use additional commands. It is possible to use the self-upgrade command to roll back to previous versions of the core, but its effectiveness depends on how far back you want to go. However, rolling back may not directly resolve the issue.

For the original problem:
Please check the ownership of the directory /tmp/boost_interprocess. If it is owned by root, the user may encounter the error:
[jlink] INTERNAL_ERROR, code: Nrfjlink.

As a quick test, you can try removing the directory entirely—it will be recreated on the next CLI invocation by the user.

Let me know how it goes, or if you need further assistance with these steps!

Best regards,

Charlie