Project cannot be built in a docker container

[balix]

Hello,

I need to build a project in a Docker container. It built fine under Windows 10 with a connect SDK v1.9.1.

Now I am using a Docker image built with the Dockerfile for nrfconnect-toolchain: https://github.com/NordicPlayground/nrfconnect-chip-docker/tree/master/nrfconnect-toolchain

1. I am not sure which version of the connect SDK is installed with this image but I assume it would be the latest one (v2.0.0). Would that be incompatible with my project which was built with a SDK v1.9.1?

2. My main issue is an error during the build with west that I don't understand:

root@a81dfea4756f:/workspace/nRF52840_zephyr-bsp# west build
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base (cached)).
-- Application: /workspace/nRF52840_zephyr-bsp
-- Cache files will be written to: /workspace/nRF52840_zephyr-bsp/zephyr/.cache
-- Zephyr version: 3.1.99 (/workspace/nRF52840_zephyr-bsp/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Found dtc: /usr/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-9-2019-q4-major)
-- Found BOARD.dts: /workspace/nRF52840_zephyr-bsp/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Generated zephyr.dts: /workspace/nRF52840_zephyr-bsp/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /workspace/nRF52840_zephyr-bsp/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /workspace/nRF52840_zephyr-bsp/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /workspace/nRF52840_zephyr-bsp/build/zephyr/dts.cmake

/workspace/nRF52840_zephyr-bsp/prj.conf:28: warning: attempt to assign the value 'y' to the undefined symbol BT_LL_SOFTDEVICE

/workspace/nRF52840_zephyr-bsp/prj.conf:31: warning: attempt to assign the value 'y' to the undefined symbol BT_GATT_DM

/workspace/nRF52840_zephyr-bsp/prj.conf:33: warning: attempt to assign the value 'y' to the undefined symbol BT_RECV_IS_RX_THREAD
Parsing /workspace/nRF52840_zephyr-bsp/Kconfig
Loaded configuration '/workspace/nRF52840_zephyr-bsp/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'
Merged configuration '/workspace/nRF52840_zephyr-bsp/prj.conf'

error: Aborting due to Kconfig warnings

CMake Error at zephyr/cmake/modules/kconfig.cmake:290 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  zephyr/cmake/modules/zephyr_default.cmake:121 (include)
  zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:96 (include_boilerplate)
  CMakeLists.txt:11 (find_package)


-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: /usr/local/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/workspace/nRF52840_zephyr-bsp/build -S/workspace/nRF52840_zephyr-bsp -GNinja

I saw this ticket which seems to talk about what appears to be a related issue:  Cannot Replicate Build in Docker Environment

However the workaround addressed in this ticket did not work in my case.

Regards,

Benjamin

[tedhavelka]

Hi Benjamin,

To mirror Øyvind's reply and your question "Should these files (ncs) be in my project instead?", your found solution of running `west init && west update` puts the ncs files where your project needs them.  To run `west update` downloads the ncs pieces along side your project root directory.

To your question just before that, my Zephyr + Nordic based app is also in the same place, same directory as my ncs directory.  And in reality, the ncs code base ends up getting downloaded into a directory named 'nrf'.  But that is the core ncs collection of code libraries, sample apps and related resources from Nordic's repository.

Just a little background:  it took me about three weeks to figure out how to create my first stand alone, Zephyr RTOS based app.  I needed to do this because after getting Nordic ncs sample apps to build (from ncs v1.6.1, in summer of 2021) I needed to bring my own coding efforts under git version control.  I could not do that from the "west updated" copy of Nordic's ncs alone.  That collection of cloned repositories was already under the git control of Nordic's ncs.  With help from both Devzone and CircuitDojo community forums, I was able to pull out Nordic's nRF9160 blinky sample, create a west.yml manifest file for it, and then compile and flash that successfully using the same tools I'd used on the "in ncs" samples.

These are the tools you as well installed, following https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/gs_installing.html.

Once I understood how the west manifest files work, and the purposes they serve, it was easier to craft new Zephyr based apps and download the needed dependencies.

There are a few caveats:  custom apps depending on different versions of Zephyr RTOS, or different versions of Nordic ncs-sdk will each need their own west-initialized workspace, and the roughly two gigabytes of downloaded code projects to support them.  If you have two or more projects which depend on the same version of Zephyr, and non-conflicting same versions of Nordic ncs, it is possible to have just one west workspace for those multiple custom apps.  But only one of the custom app's manifest file should be treated as the arbiter or ruling manifest.  A manifest with fewer external code dependencies in one project won't update all the dependencies of a second project.  And of course we must assure that no two projects sharing one west workspace refer to alternate versions of the same third party code library or code base.

Disk space is pretty cheap these days, so you are likely safe to dedicate one west workspace to each Zephyr based project.

Curious about one thing Benjamin, when you use Docker containers are you able with the container to see USB programmers and other hardware you use to interact with your targeted board?  No issues or hoops to jump through there?

- Ted

[ealtan]

Hi Ted,

I am also interested in your "when you use Docker containers are you able with the container to see USB programmers and other hardware you use to interact with your targeted board? "  question.  I am running  Docker image on a Windows 10 PC.

I built my project successfully but when I do west flash, it doesn't see the board, even though it is connected and I can successfully program it via Visual Studio Code.   I get these errors :

-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
FATAL ERROR: "nrfjprog --ids" did not find a board; is the board connected?

Is there a procedure to use USB ports with Docker Container ?  

UPDATE:  I came across this message :  https://github.com/NordicPlayground/nrf-docker#flashing  

So, unless it is changed,  USB access in Windows and MacOS is not supported, yet.  

Thanks,

Ealtan

[tedhavelka]

Hi Ealtan,

In regards to using `west flash` within a virtual machine as provided by Oracle's VirtualBox software, it sounds as though your work station is running either Windows or MacOS, but you are setting up a VM with some flavor of Linux.  If not and you have time, please correct me on this surmise.

The reason I ask is that about a year ago I was using VM images on which I'd set up a basic Ubuntu 20.04 LTS, and some firmware development tools therein.  While the base VirtualBox software had a license free option, I tested out their "Oracle VM VirtualBox Extension Pack" which seemed necessary to provide access to hardware devices like COM ports and USB subsystem.

With this extension pack installed I was able to flash dev kits and custom hardware from my virtual machine running Ubuntu, with this VM running on Windows 10.  I believe I was using `nrfjprog` to flash external hardware.  So while it was not `west` I was able to complete a full "code, compile, flash, debug" work cycle from within a virtual machine.

I think `west` would work in or from this configuration of VM as well, as `west` mostly invokes other tools, and the key thing is for the VM to have a sane view and access to workstation peripherals and physical ports.

This extension pack however I learned at the time required a license.  Shortly after these explorations our team were granted permission to install Ubuntu on dedicated laptops.  This greatly simplified our firmware specific needs to connect programmers and debuggers to external hardware.

At present I don't have time to test the Docker image you're using -- thank you for sharing the link to it! -- yet I suspect that it entails the base, free VirtualBox as part of its configuration.  If it's just VirtualBox without any extension packs, that may be why the ability to flash devices is not yet supported.

Just thought I would share these thoughts, in case it jogs a memory or new idea to help you get tools and environments configured better.  Nice to know there is a Docker image which comes so close to providing a `west` and Zephyr supporting build environment!

Thanks for writing back.  Stay well, Ealtan

- Ted