This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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

Reply
  • 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

Children
No Data
Related