Installing nRF Connect for Desktop on macOS with APFS file system,?

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Mon, 12 Oct 2020 21:25:18 GMT

Einar,

Have given up on getting NCS for Desktop on macOS for now. Seems prudent for the tool to mature a bit more before making another attempt. The imminent arrival of the Big Sur release of macOS also argues for a delay.

I have successfully installed NCS for Desktop on a Win10 VM on the same MacBook Pro. More cumbersome and less efficient, but sufficient for my needs for the moment.

So we might as well close out this case/thread and revisit the issue later.

Thanks for your efforts and followup on this issue.

Mike

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Einar Thorsrud — Fri, 09 Oct 2020 06:36:06 GMT

Hi Mike,

[quote user="mikew67"]I also used pip3 to list all of the packages in my configuration and noted that there is a package installed called pyelftools[/quote]

pyelftools is the package that gives you elftools. It is a pure python library, and all/any dependencies are installed by pip, so that should not be a problem.

[quote user="mikew67"]Does this provide the functionality expected for elftools? If so, how do we satisfy the requirement for elftools?[/quote]

If you still get the error that elfools is missing, I suspect a problem with the python and/or path configuration on your Mac. It is difficult to know exactly what causes it, though, and I have not seen this issue myself.

[quote user="mikew67"]Having taken care of this, do you suspect that this will solve the problem with opening an nRF Project in SES later? Be great if it does.[/quote]

I don't know, to be honest. I do not recall seeing the errors you get in SES before. But it is clear that there is a problem with your installation, as you get the issue with elftools. So I would suggest focusing on one issue at a time, fixing it, before moving on as they may have the same cause (so fixing one may fix others).

There is another possible approach if you don't make progress. We are aware that the process of getting the toolchain installed can be painful, and therefore we have added a Toolchain Manager app to nRF Connect for desktop. That will give you a complete toolchain package independence of the system. It is currently only has full support for Windows, but you can try it for macOS as well, though it is not fully supported yet.

Einar

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Thu, 08 Oct 2020 07:14:56 GMT

Einar,

As I noted, elftools is not installed in my current configuration. Furthermore, the three pip3 lines you quoted do not install elftools. I executed them again and verified that elftools wasn't present either before or after their execution. And all three commands reported "Requirement already satisfied:" for all invocations.

As an experiment, I tried "pip3 install elftools" as an experiment. It failed with:

% pip3 install elftools
ERROR: Could not find a version that satisfies the requirement elftools (from versions: none)
ERROR: No matching distribution found for elftools

I also used pip3 to list all of the packages in my configuration and noted that there is a package installed called pyelftools:

 % pip3 show pyelftools
Name: pyelftools
Version: 0.26
Summary: Library for analyzing ELF files and DWARF debugging information
Home-page: https://github.com/eliben/pyelftools
Author: Eli Bendersky
Author-email: eliben@gmail.com
License: Public domain
Location: /Users/mike/.pyenv/versions/3.8.5/lib/python3.8/site-packages
Requires: 
Required-by: pyocd

Does this provide the functionality expected for elftools? If so, how do we satisfy the requirement for elftools?

Having taken care of this, do you suspect that this will solve the problem with opening an nRF Project in SES later? Be great if it does.

Thanks,

Mike

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Einar Thorsrud — Wed, 07 Oct 2020 10:46:12 GMT

Hi Mike,

[quote user="mikew67"]The final linking failed because the module "elftools" was missing (but I presume that can be readily corrected.-- how?)[/quote]

This is part of a python package that should be installed when you follow the instructions like this (specifically it is part of the zephyr requirements):

pip3 install -r zephyr/scripts/requirements.txt
pip3 install -r nrf/scripts/requirements.txt
pip3 install -r bootloader/mcuboot/scripts/requirements.txt

Can you make sure you do that?

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Wed, 07 Oct 2020 01:24:44 GMT

My bad -- I see that I was interpreting "build" as a west command, rather than the directory containing the build instructions. Please forgive that newbie error.

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Wed, 07 Oct 2020 01:12:20 GMT

Einar,

Thanks. This is a very useful clarification. It's obvious that attempting to build a sample app for an incompatible board isn't going to work. But it certainly would be useful if the build process would fail in a way (especially for the new user) that isn't so obscure and provided more of a hint on how to rectify the problem. (Does this indicate a need for better documentation.)

Having said all of that, I'm not sure we've found the root of my problem yet. Here's what I tried:

I built a sample, Blinky_pwm (from the zephyr code repo) with the Nordic nRF52840 Dongle. Here are the nRF Connect Options I used:

The make process (i.e., "opening the nRF Connect project) worked fine and build proceeded fine. The final linking failed because the module "elftools" was missing (but I presume that can be readily corrected.-- how?)
I then attempted to build the asset tracker sample app (from the zephyr repo, not the ccs file tree), much as you suggested in one of your earlier replies, using the "ns" variant of the board name, as in:

This attempt, however, produced all of the kinds of make errors I've seen before and posted this dialog:
Then, just for fun, I attempted this same build process, but from the command line. This time the process worked! Here's the log:
devzone.nordicsemi.com/.../Asset-tracker-command-line-build.txt

So you figure out what's wrong with the GUI approach in SES??? One hint, it appears that "west" works differently when my current working directory changes. In response to "west build -b nrf9160dk_nrf9160ns", I've gotten three different responses:

 % west build -b nrf9160dk_nrf9160ns 
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'build' (choose from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall', 'help', 'config', 'topdir', 'selfupdate')

% cd ~/ncs
mike@Mikes-MacBook-Pro-10-1 ncs % west build -b nrf9160dk_nrf9160ns 
ERROR: source directory "." does not contain a CMakeLists.txt; is this really what you want to build? (Use -s SOURCE_DIR to specify the application source directory)
FATAL ERROR: refusing to proceed without --force due to above error

% cd nrf/applications/asset_tracker

mike@Mikes-MacBook-Pro-10-1 asset_tracker % west build -b nrf9160dk_nrf9160ns

-- west build: generating a build system

Including boilerplate (Zephyr base): /Users/mike/ncs/zephyr/cmake/app/boilerplate.cmake

-- Application: /Users/mike/ncs/nrf/applications/asset_tracker

-- Zephyr version: 2.3.99 (/Users/mike/ncs/zephyr)

-- Found Python3: /Users/mike/.pyenv/versions/3.8.5/bin/python3.8 (found suitable exact version "3.8.5") found components: Interpreter

-- Found west: /Users/mike/.pyenv/versions/3.8.5/bin/west (found suitable version "0.8.0", minimum required is "0.7.1")

-- Board: nrf9160dk_nrf9160ns

-- Found dtc: /usr/local/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")

-- Found toolchain: gnuarmemb (/Users/mike/gnuarmemb)

-- Found BOARD.dts: /Users/mike/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160ns.dts

nrf9160dk_nrf9160ns.dts.pre.tmp:358.32-362.5: Warning (simple_bus_reg): /soc/cryptocell-sw: missing or empty reg/ranges property

nrf9160dk_nrf9160ns.dts.pre.tmp:57.42-69.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@40000000/flash-controller@39000: duplicate unit-address (also used in node /soc/peripheral@40000000/kmu@39000)

nrf9160dk_nrf9160ns.dts.pre.tmp:306.19-312.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@40000000/clock@5000: duplicate unit-address (also used in node /soc/peripheral@40000000/power@5000)

-- Generated zephyr.dts: /Users/mike/ncs/nrf/applications/asset_tracker/build/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /Users/mike/ncs/nrf/applications/asset_tracker/build/zephyr/include/generated/devicetree_unfixed.h

Parsing /Users/mike/ncs/nrf/applications/asset_tracker/Kconfig

Loaded configuration '/Users/mike/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160ns_defconfig'

Merged configuration '/Users/mike/ncs/nrf/applications/asset_tracker/prj.conf'

Configuration saved to '/Users/mike/ncs/nrf/applications/asset_tracker/build/zephyr/.config'

Kconfig header saved to '/Users/mike/ncs/nrf/applications/asset_tracker/build/zephyr/include/generated/autoconf.h'

-- The C compiler identification is GNU 9.2.1

-- The CXX compiler identification is GNU 9.2.1

-- The ASM compiler identification is GNU

-- Found assembler: /Users/mike/gnuarmemb/bin/arm-none-eabi-gcc

-- Cache files will be written to: /Users/mike/Library/Caches/zephyr

Changed board to secure nrf9160dk_nrf9160 (NOT NS)

=== child image spm - begin ===

Including boilerplate (Zephyr base): /Users/mike/ncs/zephyr/cmake/app/boilerplate.cmake

-- Application: /Users/mike/ncs/nrf/samples/spm

-- Zephyr version: 2.3.99 (/Users/mike/ncs/zephyr)

-- Found Python3: /Users/mike/.pyenv/versions/3.8.5/bin/python3.8 (found suitable exact version "3.8.5") found components: Interpreter

-- Found west: /Users/mike/.pyenv/versions/3.8.5/bin/west (found suitable version "0.8.0", minimum required is "0.7.1")

-- Board: nrf9160dk_nrf9160

-- Found dtc: /usr/local/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")

-- Found toolchain: gnuarmemb (/Users/mike/gnuarmemb)

-- Found BOARD.dts: /Users/mike/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts

-- Found devicetree overlay: /Users/mike/ncs/nrf/samples/spm/nrf9160dk_nrf9160.overlay

nrf9160dk_nrf9160.dts.pre.tmp:57.42-69.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@50000000/flash-controller@39000: duplicate unit-address (also used in node /soc/peripheral@50000000/kmu@39000)

nrf9160dk_nrf9160.dts.pre.tmp:306.19-312.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@50000000/clock@5000: duplicate unit-address (also used in node /soc/peripheral@50000000/power@5000)

-- Generated zephyr.dts: /Users/mike/ncs/nrf/applications/asset_tracker/build/spm/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /Users/mike/ncs/nrf/applications/asset_tracker/build/spm/zephyr/include/generated/devicetree_unfixed.h

Parsing /Users/mike/ncs/zephyr/Kconfig

Loaded configuration '/Users/mike/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_defconfig'

Merged configuration '/Users/mike/ncs/nrf/applications/asset_tracker/spm.conf'

Configuration saved to '/Users/mike/ncs/nrf/applications/asset_tracker/build/spm/zephyr/.config'

Kconfig header saved to '/Users/mike/ncs/nrf/applications/asset_tracker/build/spm/zephyr/include/generated/autoconf.h'

-- The C compiler identification is GNU 9.2.1

-- The CXX compiler identification is GNU 9.2.1

-- The ASM compiler identification is GNU

-- Found assembler: /Users/mike/gnuarmemb/bin/arm-none-eabi-gcc

-- Cache files will be written to: /Users/mike/Library/Caches/zephyr

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/mike/ncs/nrf/applications/asset_tracker/build/spm

=== child image spm - end ===

Changed board to secure nrf9160dk_nrf9160 (NOT NS)

=== child image mcuboot - begin ===

Including boilerplate (Zephyr base): /Users/mike/ncs/zephyr/cmake/app/boilerplate.cmake

-- Application: /Users/mike/ncs/bootloader/mcuboot/boot/zephyr

-- Zephyr version: 2.3.99 (/Users/mike/ncs/zephyr)

-- Found Python3: /Users/mike/.pyenv/versions/3.8.5/bin/python3.8 (found suitable exact version "3.8.5") found components: Interpreter

-- Found west: /Users/mike/.pyenv/versions/3.8.5/bin/west (found suitable version "0.8.0", minimum required is "0.7.1")

-- Board: nrf9160dk_nrf9160

-- Found dtc: /usr/local/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")

-- Found toolchain: gnuarmemb (/Users/mike/gnuarmemb)

-- Found BOARD.dts: /Users/mike/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts

-- Found devicetree overlay: /Users/mike/ncs/bootloader/mcuboot/boot/zephyr/dts.overlay

nrf9160dk_nrf9160.dts.pre.tmp:57.42-69.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@50000000/flash-controller@39000: duplicate unit-address (also used in node /soc/peripheral@50000000/kmu@39000)

nrf9160dk_nrf9160.dts.pre.tmp:306.19-312.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@50000000/clock@5000: duplicate unit-address (also used in node /soc/peripheral@50000000/power@5000)

-- Generated zephyr.dts: /Users/mike/ncs/nrf/applications/asset_tracker/build/mcuboot/zephyr/zephyr.dts

-- Generated devicetree_unfixed.h: /Users/mike/ncs/nrf/applications/asset_tracker/build/mcuboot/zephyr/include/generated/devicetree_unfixed.h

Parsing /Users/mike/ncs/bootloader/mcuboot/boot/zephyr/Kconfig

Loaded configuration '/Users/mike/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_defconfig'

Merged configuration '/Users/mike/ncs/bootloader/mcuboot/boot/zephyr/prj.conf'

Configuration saved to '/Users/mike/ncs/nrf/applications/asset_tracker/build/mcuboot/zephyr/.config'

Kconfig header saved to '/Users/mike/ncs/nrf/applications/asset_tracker/build/mcuboot/zephyr/include/generated/autoconf.h'

-- The C compiler identification is GNU 9.2.1

-- The CXX compiler identification is GNU 9.2.1

-- The ASM compiler identification is GNU

-- Found assembler: /Users/mike/gnuarmemb/bin/arm-none-eabi-gcc

-- Cache files will be written to: /Users/mike/Library/Caches/zephyr

MCUBoot bootloader key file: /Users/mike/ncs/bootloader/mcuboot/root-rsa-2048.pem

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/mike/ncs/nrf/applications/asset_tracker/build/mcuboot

=== child image mcuboot - end ===

CMake Warning at /Users/mike/ncs/nrf/cmake/mcuboot.cmake:115 (message):



---------------------------------------------------------

--- WARNING: Using default MCUBoot key, it should not ---

--- be used for production. ---

---------------------------------------------------------



Call Stack (most recent call first):

/Users/mike/ncs/bootloader/mcuboot/zephyr/CMakeLists.txt:1 (include)

CMake Warning at /Users/mike/ncs/zephyr/CMakeLists.txt:1379 (message):

__ASSERT() statements are globally ENABLED

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/mike/ncs/nrf/applications/asset_tracker/build

-- west build: building application

[1/260] Preparing syscall dependency handling

[11/260] Performing build step for 'mcuboot_subimage'

[1/239] Preparing syscall dependency handling

[234/239] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region Used Size Region Size %age Used

   FLASH: 37624 B 48 KB 76.55%

SRAM: 22576 B 64 KB 34.45%

IDT_LIST: 88 B 2 KB 4.30%

[239/239] Linking C executable zephyr/zephyr.elf

[17/260] Performing build step for 'spm_subimage'

[1/193] Preparing syscall dependency handling

[188/193] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region Used Size Region Size %age Used

   FLASH: 32256 B 48 KB 65.62%

SRAM: 5520 B 64 KB 8.42%

IDT_LIST: 40 B 2 KB 1.95%

[193/193] Linking C executable zephyr/zephyr.elf

[250/260] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region Used Size Region Size %age Used

   FLASH: 210912 B 437760 B 48.18%

SRAM: 77848 B 128 KB 59.39%

IDT_LIST: 152 B 2 KB 7.42%

[260/260] Generating zephyr/merged.hex

mike@Mikes-MacBook-Pro-10-1 asset_tracker %

So in this case, you can see that the build worked fine.

FINAL NOTE: I'm suspicious that I may have multiple copies of "west" on my system, and the "wrong" one is being invoked from SES. Inside SES, in Tools | Options | nRF Connect, I currently have the following settings:

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Einar Thorsrud — Tue, 06 Oct 2020 07:53:29 GMT

Hi Mike,

You cannot build the nRF91 Asset Tracker project for the nrf52840 dongle, which you do here:

So that this fails is expected. If you want to build the asset tracker, then you must select the nRF91 (non-secure) board, as I showed in my previous post.

If you want to build a sample for the nRF52840 dongle, then you must build a sample that works for that. For instance, to build PWM Blinky sample for the nRF52840 dongle you do this:

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Tue, 06 Oct 2020 07:10:24 GMT

Einar, et al,

Took a little extra time before replying. Did a careful manual installation of nRF Connect for Desktop on my MacBook Pro (details at the very start of this thread). Here are the results:

Used the online instructions here
Which starts by referring to the Zephyr Getting Started instructions here.
Several errors and ambiguities exist in these instructions:
- How much of the Zephyr Getting Started steps need to be executed? Not clear. (In today's exercise, I completed all of the steps through the end, testing building and flashing a sample Zephyr app, Blinky.)
- In the initial "Installing NCS" page, the following caution is contained:
```
...you must install version 9-2019-q4-major of the GNU Arm Embedded Toolchain
```
- Unfortunately the link contained in this sentence (and another one nearby) point to the 9-2019-q2, not q4, version of the toolchain. Don't know if this is a critical factor, but corrected the toolchain release I installed in today's exercise.
As noted, I completed all the steps in the Zephyr Getting Started Guide. Did a test build of the Blinky sample app (as well as a couple others) without any serious issues, flashed an nRF52 DK and verified the operation of the code.
A complete console log for this first part of the NCS installation is attacheddevzone.nordicsemi.com/.../NCS-Installation-Log-201005.txt
Here's the build and flash of Blinky:devzone.nordicsemi.com/.../Build-the-Zephyr-Blinky-Sample.txt
So far, so good!
Went back to the NCS installation page
SES was already installed. No installation necessary. But note: I get this warning each time I start it up. Take the "No to all" branch
Went through the Environment Variable setting tab for Tools | Options | nRF Connect and verified all directory paths.
Invoked the menu command, File | Open nRF Connect Project and set the fields as follows:
Clicked the OK button, and got the following error dialog:

So it looks like the problem is on the NCS side and not the Zephyr side. Next step?

Thanks,

Mike

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Einar Thorsrud — Thu, 01 Oct 2020 07:20:30 GMT

Hi Mike,

[quote user="mikew67"]non-secure? I only see four sample applications: asset_tracker, connectivity_bridge, nrf_desktop, and serial_lte_modem, none with an ns suffix.[/quote]

The project does not specify non-secure, but you must select that for the board. Any project using the LTE modem must be none-secure, i.e. you must select the board ending with "ns" (nrf9160dk_nrf9160ns). From Segger Embedded Studio you do this when opening the project, as you can see here:

[quote user="mikew67"]NCS version? Keep downloading the latest. The verify step in the Getting Started Assistant reports "nrf_connect_sdk-0.1.5-1 verified successfully"[/quote]

The NCS version is not linked directly to the getting started assistent. That is controlled by thich nrf tag you check out like this (from the "Clone the nRF Connect SDK" section of the getting started assistant:

cd <sourcecode_root>/ncs/nrf
git checkout <ncs_tag>
west update

Which NCS tag did you use here?

[quote user="mikew67"]Building from the command line?[/quote]

I should have specified more clearly. To build from the command line you need to (from the same shell):

Run <ncs>/zephyr/zephyr-env.sh
Navigate to the folder of the project you want to build, e.g. "cd nrf/applications/asset_tracker"
call "west build -b nrf9160dk_nrf9160ns" to build the project (you can optionally add --pristine to clean before you build if there is any problems.

[quote user="mikew67"]Any hints? Diagnostics I can run?[/quote]

If everything was correctly configured the asset tracker should build correctly when you do the above and build form the command line. If not, we need to look at the output from the build process to try to understand what the problem is. In that case it is easier to stick with the command line to understand what happens. Please upload the full build log in that case.

Einar

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Wed, 30 Sep 2020 23:33:18 GMT

Thanks for the quick response, Einar. Responding to your comments:

non-secure? I only see four sample applications: asset_tracker, connectivity_bridge, nrf_desktop, and serial_lte_modem, none with an ns suffix.

NCS version? Keep downloading the latest. The verify step in the Getting Started Assistant reports "nrf_connect_sdk-0.1.5-1 verified successfully"

Building from the command line? Your suggestion, "west build -b nrf9160dk_nrf9160ns", fails immediately with:

mike@Mikes-MacBook-Pro-10-1 ~ % west build -b nrf9160dk_nrf9160ns
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'build' (choose from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall', 'help', 'config', 'topdir', 'selfupdate')
mike@Mikes-MacBook-Pro-10-1 ~ % west -V
West version: v0.7.3
mike@Mikes-MacBook-Pro-10-1 ~ %
That is, "build" appears not to be a legal west command. Also, there is no "nrf9160dk_nrf9160ns", board, but there is a "nrf9160dk_nrf9160 board.

Currently at a standstill. Any hints? Diagnostics I can run?

Mike

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Einar Thorsrud — Wed, 30 Sep 2020 11:10:32 GMT

Hi Mike,

I do not immediately see what the problem is here. Did you make sure to select the non-secure when opening the project (board ending with "ns")? Which NCS version are you using? Does building from the command line work ("west build -b nrf9160dk_nrf9160ns")?

Einar

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Wed, 30 Sep 2020 00:13:40 GMT

OK, reinstalled my Python 3.8.5 environment using pyenv as advised. Got further, but still had the following issues:

Had to reboot to get the new Python environment to work properly. Simply starting a new terminal window was insufficient.
Section 2 of Getting Started Assistant verifications still fail; west is not installed in /bin/sh. No matter.
Got all the way to the final step of opening an NRF Connect SDK project and got the following error dialog. What setup stage, etc., am I missing?

Thanks,

Mike

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Mike Wirth — Tue, 29 Sep 2020 21:43:59 GMT

Many thanks, Einar. Will give this a shot and see how it works.

Have passed your Python3 installation recommendations along to several friends who are heavy Python aficionados and teachers.

Mike

RE: Installing nRF Connect for Desktop on macOS with APFS file system,?

Einar Thorsrud — Tue, 29 Sep 2020 09:23:47 GMT

Hi Mike,

[quote user=""]Has anyone succeeded in installing nRF Connect for Desktop on macOS Catalina (or a Big Sur beta) with an APFS-formatted system disk? If so, what do I need to do to get around the above listed issues?[/quote]

You can see from the error that there is a problem with west not being in the path. I also had issues with this, but got it working by installing (and managing) python via pyenv, as described here.

[quote user=""]Out of curiosity, when I've successfully completed this installation, do I have a full "base" installation of Zephyr (i.e., without all the optional modules), or do I need to go back and complete the Zephyr installation?[/quote]

Yes. If you follow the guide you will check out all repositories that are needed, including the full Zephyr repo. That is all handled for you by the west tool. (For instance, "west init -m github.com/.../sdk-nrf --mr v1.3.0" will check out the full nRF Connect SDK 1.3, including Zephyr, mcuboot and a large number of other repositories).

Einar