• Support

  • All AT Commands time out in LTE link monitor

kava60 hmmm. Haven’t seen this one before. Are you doing this from a CLI that you opened with nRF Connect? Alternatively you can also run this and it will do the same thing:

export PATH=/opt/nordic/ncs/v1.5.0/toolchain/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin ; export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb ; export GIT_EXEC_PATH=/opt/nordic/ncs/v1.5.0/toolchain/Cellar/git/2.26.2/libexec/git-core ; export GNUARMEMB_TOOLCHAIN_PATH=/opt/nordic/ncs/v1.5.0/toolchain ; clear⏎

I keep these commands in a file called setenv and then when I want to set my environment I simply run

source setenv

This will set the environment variables which may be causing this weirdness.

You may also have a malformed west.yml. Did you only make the necessary edits to add NFED? Did you have any issues when you ran west update?

      jaredwolff I am running this in the terminal/shell that opens from the nRF connect toolchain manager. I did make the edits to add NFED and didn’t see any errors when I ran west update after making the changes to west.yml.

      I think I’ll see if there is a way to blow away the SDK and reinstall it again to see if that clears up the problem.

      Kurt

        jaredwolff I removed the SDK, reinstalled, modified west.yml and west update. Then tried building the sample again. Same problem. It kind of looks like the failure is because there is a ‘_default_importer’ method that is the default callback invoked when “the source file requires importing manifest data that aren’t found locally”. The default one simply throws the exception. From looking at the API, it looks like the caller of the Manifest API is supposed to provide an ‘importer’ callback if they expect to handle this case (manifest data not found locally). Apparently there isn’t one provided in this case, so the exception is thrown. I’ll keep working my way back from this info to see if I can tell why this is happening. I’m guessing this must be some sort of environmental issue on my system… Sigh.

        Kurt

            kava60 yea it’s likely some type of environment issue. As long as you open a terminal from nRF Connect Desktop or overwrite your path with he commands I gave you earlier it should just work. I’m assuming you have Python installed elsewhere? Do you have any of the Zephyr SDK tools installed? west cmake ninja?

                kava60 also are you doing this within an editor like VSCode? The editor tends to muck with your environment variables as well.

                  jaredwolff I do have make installed on my Mac; I have a /usr/local/bin/cmake which reports version 3.19.1. Likely a requirement for something else I develop with. When I do a which cmake in the terminal window created from nRF connect desktop toolchain manager, it reports: /opt//nordic/ncs/v1.5.0/toolchain/bin/cmake so I don’t think it is getting the /usr/local/bin/cmake that is installed on my Mac. A which on west and ninja also reports the same path under /opt/nordic/ncs/v1.5.0/toolchain/bin.

                  As for your second question - no, I’m not running any of this in an IDE, just at the shell prompt in the terminal window that is opened (with the correct environment setup) from the nRF connect desktop…

                  Kurt

                    jaredwolff also, just in case I did a chmod -x on my /usr/local/bin/cmake and tried again - same failure so we can rule out the cmake I have installed on my Mac…
                    Kurt

                      jaredwolff in case it is useful, doing a west config -l reports the following:

                      manifest.path=nrf
                      manifest.file=west.yml
                      zephyr.base=zephyr

                        That looks ok.

                        Maybe it’s a weird permissions issue in your /opt/nordic folder? My folder is owned by my user in OS X.

                        /opt/nordic 
❯ ls -la
total 24
drwxrwsr-t  4 root        staff   128 Dec 18 22:53 ./
drwxr-xr-x  4 root        wheel   128 Jan 24 00:27 ../
-rw-r--r--@ 1 jaredwolff  staff  8196 May  3 10:25 .DS_Store
drwxr-xr-x  7 jaredwolff  staff   224 May  3 10:26 ncs/
                        /opt🔒 
❯ ls -la
total 0
drwxr-xr-x   4 root  wheel  128 Jan 24 00:27 ./
drwxr-xr-x  22 root  admin  704 May 13 23:41 ../
drwxrwsr-t   4 root  staff  128 Dec 18 22:53 nordic/
drwxr-xr-x   4 root  wheel  128 Jan 24 00:27 vagrant/

                        Is there anything in your opt folder that could have changed things up?

                        Also, are you using a newer M1 Mac or Intel based?

                          kava60 hmm the plot thickens then.

                          My best guess is that your nrf/west.yml is malformed. Can you cd to /opt/nordic/ncs/v1.5.0/nrf and run git diff >> nrf.diff and then send nrf.diff my way?

                              jaredwolff I tried the ‘git diff >> nrf.diff’ but that failed. I had saved the original west.yml before I modified as specified in the install instructions, so here is a diff west.yml old_west.yml:

                              38,39d37
<     - name: circuitdojo
<       url-base: https://github.com/circuitdojo
125,129d122
<     - name: nfed
<       repo-path: nrf9160-feather-examples-and-drivers
<       revision: v1.5.x
<       path: nfed
<       remote: circuitdojo

                                  kava60 hmm that look a-ok to me.

                                  Since this is clearly related to python/west in some way. You can try compiling “manually”

                                  # Use cmake to configure a Ninja-based buildsystem:
cmake -B build -GNinja -DBOARD=circuitdojo_feather_nrf9160ns samples/blinky

# Now run ninja on the generated build system:
ninja -C build

                                  Also if there are any examples you want me to pre-build for your evaluation please let me know and I’ll send em your way.

                                      jaredwolff The first cmake command failed the same way as the west build command (ManifestImportFailed). Perhaps this is a clue and we are narrowing down on where the problem is.

                                        jaredwolff Found the problem! I instrumented the is_cloned() call (which was the check that leads to the call to the default load that throws the exception). It calls a git() method that constructs a git command line that it uses to determine if the build is being run in a cloned repo. When I printed the return from the git command I saw it failed with the following:

                                        git res = CompletedProcess(args=[‘git’, ‘rev-parse’, ‘–show-cdup’], returncode=1, stdout=b’', stderr=b’xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun\n’)

                                        I’m running OS X Big Sur and apparently my command line tools license was not active (I know I activated it after I installed Big Sur). Ran the following:
                                        $ xcode-select --install
                                        After the install completed, I’m now able to successfully build the sample code!
                                        Thanks for your help and patience Jared. I’m hoping that with all of this up front hassle everything else is now going to be a breeze!

                                        Kurt

                                            kava60 wow I would have never thought to activate Xcode CLI tools! I’ll have to add that to the instructions. Thanks for sharing the process and sorry it was such a pain!

                                              Terms and Conditions | Privacy Policy