M1 Mac fixes for nRF Connect, VS Code, and nrfjprog

[je90]

Background

M1 Mac support for nRF Connect SDK tooling is currently lacking, with the nRF Connect app, VS Code plugins and command line tools not working with the default setup and installation instructions.

There have been many threads from different Nordic customers confirming these issues. I would implore Nordic to fix these issues as soon as possible as it is unprofessional that these issues persist 18 months after public availability of M1 machines, particularly with no solution or public timeline for a fixoffered by Nordic. I chose Nordic for my first commercial hardware projects in part due to the tooling available, so I'm pretty disappointed.

After days of debugging, I have managed to get the nRF Connect app, VS Code plugins, and nrfjprog working, and working concurrently. To give Nordic credit, this is in part due to updates made that appear to have fixed some of the issues related to M1 support.

Problem

All of the tools use nrfjprog to interact with hardware using SEGGER JLink libraries. Some of these tools run natively in an native arm context, and some use Rosetta to emulate Intel architecture. The tools need to use nrfjprog with the version of the JLink librarary appropriate to the current architecture.

	M1 JLink	Intel JLink
nRF Command Line Tools (inc. nrfjprog)	Yes	No
nRF Connect for Desktop	No	Yes
nRF for VS Code extensions	Partial (GUI elements)	Partial (tasks run in terminals)

If the wrong library is used, a error is produced stating that nrfjprog can't load the library:

Solution

Install JLink for both ARM and Intel processors in seperate folders. Use a wrapper script for nrfjprog to specify the correct JLink library for the current architecture.

Detailed instructions

1. Install nRF Connect for Desktop, nRF Command Line Tools and nRF for VS Code as normal
2. Download and install SEGGER JLink ARM Version from www.segger.com/.../
3. Move /Applications/SEGGER to /Applications/SEGGER_ARM
4. Download and install SEGGER JLink Intel Version ("64-bit Installer") also from https://www.segger.com/downloads/jlink/
5. Move /Applications/SEGGER to /Applications/SEGGER_x86_64
6. Create a bin folder in your home directory
7. Add /Users/USER/bin to your path, where USER is your username, by adding export "PATH=/Users/USER/bin:$PATH" to your shell profile/ rc file
8. Create a wrapper script called nrfjprog in /Users/USER/bin with the following contents:
   
   #!/usr/bin/env bash
arch=`arch`
if [ "$arch" == "arm64" ]
then
  SEGGER_ARCH=ARM
else
  SEGGER_ARCH=x86_64
fi

exec /usr/local/bin/nrfjprog --jdll /Applications/SEGGER_${SEGGER_ARCH}/JLink_V764d/libjlinkarm.7.64.4.dylib $@
9. Run chmod +x /Users/USER/bin/nrfjprog at a terminal to make the wrapper script executable

Post

Hopefully this works for others experiencing problems. It's unclear if I have missed anything as I don't have a fresh machine to try this on. Please let me know if this works for you.

Nordic may be able to temporarily fix these issues by applying the same approach of manually specifying the JLink library on any calls to nrfjprog. It is worth noting that if they do this, it will break the above fix, as the --jdll paramter will be specificied twice which nrfjprog does not accept.

[Einar Thorsrud]

Hi,

Thank you for sharing!

I want to mention that you can also use the Universal installer of J-Link, which will should solve much of this. There are some problems with nRF51 though, which is why the universal installer is currently not bundled with nRF Command Line Tools (this should be solved in an upcoming version, though).

[Scott]

I appreciate all of this and found the same but it took a long time to figure all of this stuff out and worse it also doesn't get all the way there

For me the damage is done. I wasted a week that I could have spent porting code from our old nRF5 SDK implementation trying to get this stuff to barely work and then I hit one road block too many and decided not to fall for the fallacy of sunk costs and to cut my losses

The fact that you or I could (mostly) get there in time says that it's totally possible and I just increasingly have no tolerance for companies that make the better part of a billion dollars a year in revenue who can't drop less than a hundred grand to get a M1 based MacBook Pro and an intern or two to spend a few weeks sorting out and deploying a good solution to save all of their customers from having to fight with their tools

I'm so tired of wanting to spend my time on interesting and genuinely hard problems and having to waste most of my time and effort overcoming little piddly roadblocks like this that shouldn't exist in the first place.