How to set TOOLCHAIN_HOME in command line, Ubuntu based Zephyr SDK?

[tedhavelka]

Hello Nordic DevZone,

My name is Ted, and I'm having some difficulty with a recently installed Nordic / Zephyr SDK and toolchain.  On 2021-07-24 I downloaded and installed the Zephyr project and Nordics's SDK that's linked from the nRF9160 product overview page.  The specific instructions I used are at Nordic site's page "">developer.nordicsemi.com/.../index.html

My need is work related.  At present I'm tasked to bring up our nRF9160 dev board and begin writing drivers for additional sensors and memory devices not on this board.

I followed instructions for the "Ubuntu" installation steps, as that's my development environment.  I am using the command line, no IDE.

When attempting to build an ARM based blinky demo, the `west` driven build process fails early with the message:

    CMake Error at /home/ted/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake:8 (message):
      Zephyr was unable to find the toolchain.  Is the environment misconfigured?

I am including full build messages below.

In terms of preparing my workstation and installing dependencies, steps 1 through 4 of "Getting Started" succeed without errors.  In particular for step 4, "Install Toolchain" I am able to download and to run the ".run" file for Zephyr SDK version 0.12.4.  I first installed this SDK in /opt/zephyr-sdk-0.12.4.  Next I attempt to build the ARM based blinky application for the nRF9160 dev board with this command:

    $ west build -b [email protected] ./samples/basic/blinky

To this command the following messages appear:


ted@localhost:~/zephyrproject/zephyr$ west build -b [email protected] ./samples/basic/blinky
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): /home/ted/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: /home/ted/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.6.99 (/home/ted/zephyrproject/zephyr), build: zephyr-v2.6.0-1460-g17d2e9d084b2
-- Found west (found suitable version "0.11.0", minimum required is "0.7.1")
-- Board: nrf9160dk_nrf9160, Revision: 1.0.0 (Active: 0.14.0)
-- Cache files will be written to: /home/ted/.cache/zephyr
-- Using toolchain: zephyr 0.12.4 (/opt/zephyr-sdk-0.12.4)
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: cross-compile (arm-unknown-linux-gnueabi-)
CMake Error at /home/ted/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake:8 (message):
  Zephyr was unable to find the toolchain.  Is the environment misconfigured?

  User-configuration:

  ZEPHYR_TOOLCHAIN_VARIANT: cross-compile

  Internal variables:

  CROSS_COMPILE: arm-unknown-linux-gnueabi-

  TOOLCHAIN_HOME:

Call Stack (most recent call first):
  /home/ted/zephyrproject/zephyr/cmake/generic_toolchain.cmake:42 (include)
  /home/ted/zephyrproject/zephyr/cmake/app/boilerplate.cmake:570 (include)
  /home/ted/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/ted/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: /usr/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/home/ted/zephyrproject/zephyr/build -S/home/ted/zephyrproject/zephyr/samples/basic/blinky -GNinja

From these messages it looks like there is a variable that's internal to `west` or some other facet of this SDK, namely the variable TOOLCHAIN_HOME.  I confirm also that the cmake file indicated above is the source of the fatal error message:


    ~/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake


The first few lines of this file are:


  1 # SPDX-License-Identifier: Apache-2.0
  2
  3 set_ifndef(CC gcc)
  4
  5 find_program(CMAKE_C_COMPILER ${CROSS_COMPILE}${CC}   PATHS ${TOOLCHAIN_HOME} NO_DEFAULT_PATH)
  6
  7 if(CMAKE_C_COMPILER STREQUAL CMAKE_C_COMPILER-NOTFOUND)
  8   message(FATAL_ERROR "Zephyr was unable to find the toolchain. Is the environment misconfigured?
  9 User-configuration:
 10 ZEPHYR_TOOLCHAIN_VARIANT: ${ZEPHYR_TOOLCHAIN_VARIANT}
 11 Internal variables:
 12 CROSS_COMPILE: ${CROSS_COMPILE}
 13 TOOLCHAIN_HOME: ${TOOLCHAIN_HOME}
 14 ")
 15 endif()
   .
   .
   .

Line 13 plus the build messages tell me that variable $TOOLCHAIN_HOME is unset.  But I don't find any mention of how to set this variable, either semi-permanently as an environment variable (that's not working) or each time manually when invoking the build process.

The nRF9160 SDK / Zephyr Ubuntu set up instructions state that the Zephyr project tools, or meta-tool, can automatically find a given example project's toolchain when the toolchain is installed in /opt or ~, among a few other conventional places.  I've installed Zephyr's tools in both these locations, per Nordic's "getting started".   Yet the internal variable $TOOLCHAIN_HOME is unset and seems to be the reason that the simplest of demos is failing to start compiling.

I have found only a couple other posts on any forum with this error message, and the solutions in those were not related or did not solve the issue for me on my workstation.

Are there any further debugging steps I can take?  Or command line options I can pass to set $TOOLCHAIN_HOME and allow the nRF9160 Zephyr projects from NordicSemi to build?

Lastly am I correct to say that, in my scenario, $TOOLCHAIN_HOME can and should be set to /opt/zephyr-sdk-0.12.4?

Thank you in advance!

- Ted

[Marte Myrvold]

Hi Ted,

As raj mentions, the environment variables must be set in order to be able to build. If you are using Toolchain Manager to install the SDK, as in Raj's case, these are set automatically when you open the terminal or SES through there. If you install the SDK manually instead, you must set these manually as well.

The toolchain west is mentioning here is the GNU Arm Embedded Toolchain. When installing the SDK manually, you should download it from here: GNU Arm Embedded Toolchain, and extract the contents of the root folder. We recommend extracting it into a folder such as ~/gnuarmemb on Linux. Please make sure to not have any spaces or special characters in the folder or path, as that might cause errors when building. Following this, you must define the environment variables ZEPHYR_TOOLCHAIN_VARIANT and GNUARMEMB_TOOLCHAIN_PATH. The value of the latter should be the folder you extracted the contents into. You can set this using the following commands in a terminal:

export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH="~/gnuarmemb"
source zephyr/zephyr-env.sh

I see you mention following steps 1 through 4 in the guide in the Zephyr documentation. Did you follow this guide only when installing, or did you follow the guide in our documentation as well? Some of the steps differ, so if you want to use NCS, and not only the Zephyr SDK, i recommend following the guide in our documentation. You can found it at Installing the nRF Connect SDK manually.

You must also set ZEPHYR_BASE. You can either set this in your system's environment variables, or you can do it by calling the command:

source zephyr/zephyr-env.sh

This command must be called from inside the ncs folder, and it must be called every time you open a new terminal window, unless you have set ZEPHYR_BASE in your system's environment variables. Please also see Set up the command-line build environment for more information. ZEPHYR_BASE should be where your zephyr folder is located, for example "~/ncs/zephyr" if you are using NCS. So if you want to set it manually you can do it using the following command in a terminal:

export ZEPHYR_BASE="~/ncs/zephyr"

I hope this solves your issue. If not, please let me know!

Best regards,

Marte

[tedhavelka]

2021-07-29 - second reply from Ted

By the way Marte, I am familiar and comfortable with amending my local .bashrc start up script.  I have sections in this file with environment variable assignments for various projects and toolchains.  Any configuration steps I would need to repeat on every shell start up, I would look for a way to automate such steps.

- Ted

[tedhavelka]

2021-08-03

Ted noting:  This reply follows earlier, helpful responses from Devzone participants Raj and Marte.

In my initial post on about 2021-07-29 I promised to share the cmake file amendments which permit me to build a Zephyr example project from the SDK whose installation is detailed in Nordics Zephyr guide page at:

*  https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/getting_started/index.html#getting-started

I had reached this page while following steps to set up needed tools and software development pieces for the nRF9160 DK (Development Kit or dev' board).  Being new to Zephyr I had not paid close attention to the left navigation pane of this Nordic guide.  Thus I missed that I'd moved away from nRF9160 DK as a topic and to a different guide altogether.  Nonetheless the Zephyr toolchain (cross-compiler and related tools) and SDK offer example code board support for Nordic's nRF9160.  Two important paths related to compile a Zephyr RTOS blinky demo include:

   ${HOME}/zephyrproject/zephyr/samples/basic/blinky

   ${HOME}/zephyrproject/zephyr/cmake/compiler/gcc

Both paths are part of Zephyr SDK 0.12.4 at git commit hash:

   commit 17d2e9d084b2f02f8d39cd38eecdd7c0b5af59a2 (HEAD -> main, origin/main)
   Author: Uday Ammu <[email protected]>
   Date: Wed Jun 23 16:04:54 2021 -0700

This SDK did not build its blinky example project following download.  I needed to inform cmake of the specific name of the ARM cross compiler which came with the toolchain download step in the Nordic Zephyr guide.  Line 8 in the cmake file listed below sets the cross-compiler name.  It actually sets the prefix of the name of most of the build tools, e.g. gcc, ar, nm and others.

On line 12, and this line took longer to figure out, I amend cmake's call to what looks like a function find_program(...).  Specifically I add "PATHS ENV PATH" to the arguments in this function call, so cmake picks up the location of the newly installed Zephyr cross-compile toolchain.

Outside of cmake and the SDK, in a .bashrc start up script I amended my $PATH variable to include the toolchain path:

    PATH="${PATH}":/opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin

Cmake amendments on lines 8 and 12 are both needed.  Interestingly, they appear to work even for an alternate SDK (ncs v1.4.1), which I downloaded a couple days later to obtain board support for Sparkfun's Thing Plus dev board.  I suspect there is some west meta-tool or cmake cacheing taking place, for Zephyr's toolchain to be found by cmake facilities in the alternate, non-Zephyr SDK.

The content of the cmake file of the first SDK, with described modifications is here:

1 # SPDX-License-Identifier: Apache-2.0
2
3 set_ifndef(CC gcc)
4
5 ## 2021-07-28 - Ted adding local assignment to empty variable:
6 ## Reference: cmake.org/.../set.html
7 #unset(CROSS_COMPILE)
8 set(CROSS_COMPILE arm-zephyr-eabi-)
9
10 ## 2021-08-01 Refernce: cmake.org/.../find_program.html
11 ##find_program(CMAKE_C_COMPILER ${CROSS_COMPILE}${CC} PATHS ${TOOLCHAIN_HOME} NO_DEFAULT_PATH)
12 find_program(CMAKE_C_COMPILER ${CROSS_COMPILE}${CC} PATHS ${TOOLCHAIN_HOME} PATHS ENV PATH NO_DEFAULT_PATH)
13
14 if(CMAKE_C_COMPILER STREQUAL CMAKE_C_COMPILER-NOTFOUND)
15 message(FATAL_ERROR "Zephyr was unable to find the toolchain. Is the environment misconfigured (- MARK 1 -)?
16 User-configuration:
17 ZEPHYR_TOOLCHAIN_VARIANT: ${ZEPHYR_TOOLCHAIN_VARIANT}
18 Internal variables:
19 CROSS_COMPILE: ${CROSS_COMPILE}
20 CC: ${CC}
21 name of compiler: ${CROSS_COMPILE}${CC}
22 TOOLCHAIN_HOME: ${TOOLCHAIN_HOME}
23 ")
24 endif()
25
26 execute_process(
27 COMMAND ${CMAKE_C_COMPILER} --version
28 RESULT_VARIABLE ret
29 OUTPUT_QUIET
30 ERROR_QUIET
31 )
32 if(ret)
33 message(FATAL_ERROR "Executing the below command failed. Are permissions set correctly?
34 '${CMAKE_C_COMPILER} --version'
35 "
36 )
37 endif()

I share these details in the interest of capturing what has taken more time than ideal to figure out.  My goal is to move beyond the example projects, and be able to construct a Zephyr, make / cmake project more from the ground up.  I am stepping through the Nordic Zephyr toolchain and SDK guide again.  I am watching closely for any steps I may have missed.  If I find such mistakes on my part, I'll update this post.

Next steps will be to learn where and how GPIO definitions and device trees for a given processor or dev board are written.  Questions about this aspect of the hardware abstraction layer in Nordic and Zephyr SDKs will likely be future post.

Thanks again Marte and Raj for the help!

- Ted