nRF Connect for VS Code does't flash a nRF52840 board

[zpm1066]

Hello,

I'm trying to flash a nRF52840 board (Particle Xenon) with nRF Connect for VSC on macOS.

macOS Big Sur 10.16 

Here is my nRF Connect - VS Code environment:

Version: 1.60.2 (Universal)
Commit: 7f6ab5485bbc008386c4386d08766667e155244e
Date: 2021-09-22T11:59:27.195Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0

I'm using all the latest nRF Connect extensions and nRF Connect v1.70.

nRF52840 with Segger version: J-Link EDU Mini V1 (7.54)

With nRF Connect for VS Code, I'm able to compile and build a simple Blinky application. Also, my connected J-Link EDU Mini and the nRF52840 board attached to the J-Link does appear under the NRF CONNECT | CONNECTED DEVICES tab. However, when I attempt to flash the program, I get the following error message.

Here are the "tools" entries when the "nRF Connect: Generate Support Information" command is run.

"tools": {
"jlink": "7.54c",
"nrfjprog": null,
"cmake": "3.20.3",
"west": null,
"python": "3.9.4",
"ninja": "1.10.2",
"gperf": "3.1",
"dtc": "1.6.0",
"gnuarmemb": "9-2019-q4-major",
"gn": null
},

In the above entries, I don't know why the "nrfjprog" or "west" doesn't show their versions like the other tools. However, I can view their versions from the macOS terminal.

I can use exactly the same connections (i.e J-Link EDU MINI V1 + nRF52840) and flash the same program using PlatformIO from VS Code without any issues, but switching to nRF Connect within VS Code & attempting to flash gives the "FATAL ERROR: runner pyocd received unknown arguments".

I have repeated another installation of nRF Connect v1.70 on macOS 10.13.6. After verifying the nRF Connect v1.70 installation, tools, nRF Connect for VS Code and the blinky example, I get the same the "FATAL ERROR: runner pyocd received unknown arguments" (as in macOS Big Sur 10.16).

Am I missing some configuration setting for nRF Connect for VS Code or is this a bug in the nRF Connect extension?

Please review and let me know what additional information you would like to assist with the issue. I would be glad to assist.

The nRF Connect for VSC looks very promising and I certainly would like to use it. Thank you.

Best Regards,

Ravi Pharma

[Vidar Berg]

Hello,

It seems like our extension should specify what "runner"  west flash should use. It doesn't make sense to select PyOCD when it sees that a J-link is connected. As a workaround, can you try to add nrfjprog to the board configuration as I suggested in my reply here: https://devzone.nordicsemi.com/f/nordic-q-a/79771/mcuboot-configuration-for-the-custom-adafruit-feather-nrf52840/330279#330279 ? I will report the issue to our VS code team in the meantime.

Best regards,

Vidar

Edit: I see now that the xeon board already includes nrfjprog as a runner. Please try to move it to the top in order to make it the default.

[zpm1066]

Hi Vidar,

Thank you for the very quick response. It's much appreciated.

Yes,  it doesn't make sense that the nRF Connect extension tries to select PyOCD when it sees that a J-link is already connected. We should not have to modify the board.cmake in the Zephyr directory in order for the nRF Connect to flash.

I made the suggested workaround for both macOS 10.6 & macOS 10.13.6, updated the particle_xenon board.cmake to

I was able to successfully flash the particle_xenon board both on macOS 10.16 and macOS 10.13.6. Thank you!

I also tried to build and flash the same Blinky application under macOS 10.14.6. The workaround also works with macOS 10.14.6.

I noticed that "nRF Connect:Generate Support Information" for the three different macOS versions have different entries that are reflected as "null" but those tools are accessible from the terminal.

Here are the different "tools" sections. 

macOS 10.16: nrfjprog shows up as "null" but is accessible from terminal

"tools": {
"jlink": "7.54c",
"nrfjprog": null,
"cmake": "3.20.3",
"west": "0.11.1",
"python": "3.9.4",
"ninja": "1.10.2",
"gperf": "3.1",
"dtc": "1.6.0",
"gnuarmemb": "9-2019-q4-major",
"gn": null
},

macOS 10.14.6: Entries are as expected

"tools": {
"jlink": "7.54c",
"nrfjprog": "10.12.2",
"cmake": "3.21.3",
"west": "0.11.1",
"python": "3.9.6",
"ninja": "1.10.2",
"gperf": "3.1",
"dtc": "1.6.1",
"gnuarmemb": "9-2020-q2-update",
"gn": null
},

macOS 10.13.6: "dtc" & gnuarmemb" show up as "null" but are accessible from terminal

"tools": {
"jlink": "7.54c",
"nrfjprog": "10.12.2",
"cmake": "3.21.3",
"west": "0.11.1",
"python": "3.9.7",
"ninja": "1.10.2",
"gperf": "3.1",
"dtc": null,
"gnuarmemb": null,
"gn": null
},

Ignoring "gn":null, Is there any particular reason why nRF Connect doesn't pickup the version numbers of the other entries that have "null"? 

What can I modify to correct the above entries? Is it possible to do so through the nRF Connect settings in VS Code?

Thank you for looking at my issue. 

Best Regards,
Ravi Pharma

[Vidar Berg]

Hi Ravi,

Yes, I agree. The team also said they would try to address this issue in the next release. With regards to the nrfjprog entry being set to null, I wonder if it may be related your path variable. I don't have a mac here to test with right now, but can you please check if PATH in environment": {} include /usr/local/bin where nrfjprog usually is installed?

Here's the from my windows system for comparison:

Best regards,

Vidar

[zpm1066]

Hello Vidar,

I think I've found out what's going on with the nrfjprog entry being set to null when  "nRF Connect: Generate Support Information" is under macOS 11.6 with the latest nrfjprog. Something may have changed in the latest nrfjprog 10.14.0.

I installed the nRF-Command-Line-Tools_10_13_0_OSX, and got the expected "tools" entries.

When the latest nrf-command-line-tools-10.14.0-Darwin.dmg is re-installed, I get the following.

Again, the nrfjprog entry in /usr/local/bin is a symlink to the binary in the /Applications/Nordic Semiconductor/bin/nrfjprog but note the "external" when issuing a "nrfjproj --version".

The nrfjprog null entry in "tools" is somewhat odd but the important thing is that nrfjprog works fine. Your nRF Connect team may want to review what's going on as Support would most likely ask customers to retrieve "nRF Connect: Generate Support Information" to aid troubleshooting.

Currently, when debugging with nRF Connect for VS Code, the "Enable debug options" needs to be unchecked for code that doesn't use threads, as there may be a potential bug that causes issues when no threads are used.

Is this issue being tracked by the nRF Connect team?

Thank you for assisting with my nRF Connect issues. The nRF Connect for VS Code is coming along very well. Please pass on the excellent work done on it by the nRF Connect Teams. It's much appreciated.

Best Regards,

Ravi 

[Vidar Berg]

Hi Ravi,

Thanks for the detailed report! I will add the details to our internal bug tracker.

zpm1066 said:

Currently, when debugging with nRF Connect for VS Code, the "Enable debug options" needs to be unchecked for code that doesn't use threads, as there may be a potential bug that causes issues when no threads are used.

I have not encountered it myself, but I see you are not the only one who has reported it. Team will look into this as well.

zpm1066 said:

Thank you for assisting with my nRF Connect issues. The nRF Connect for VS Code is coming along very well. Please pass on the excellent work done on it by the nRF Connect Teams. It's much appreciated.

Will do, thanks. There are still some bugs to iron out, but I think it's coming along quite well.

Best regards,

Vidar