Date   

Re: Recursive checkout with West

barry.solomon@...
 

In case this is useful to anyone. I am doing a recursive checkout currently with a little bit of a hack. So I have a west file that just includes my project and the nordic NCS release. The NCS release has its own west.yml file that specifies the version of zephyr, mcuboot, and many more. To do the recursive part, I made a custom west command that is part of my project. So first I do init. This loads my project and NCS repo that contains the other west.yml file. The I run my west custom_update command instead of west update. My command modifies the config file .west to point to the NCS repo, and then the executes west update, which pulls in all the source specified by the other west.yml file. If you wanted to do multiple levels or recursion you could create multiple scripts or just make one complicated script.


Re: MIMXRT1060_EVK touch screen support #input

Maureen Helm
 

Hi Olivier,

The touch input hasn’t been enabled upstream yet. I posted a draft pull request to add this, but it hasn’t been merged because we haven’t solidified the API.

https://github.com/zephyrproject-rtos/zephyr/pull/16119

 

Maureen

 

From: users@... <users@...> On Behalf Of boucard_olivier via Lists.Zephyrproject.Org
Sent: Monday, October 14, 2019 8:56 AM
To: users@...
Cc: users@...
Subject: [Zephyr-users] MIMXRT1060_EVK touch screen support #input #input

 

Hello,

I'm new to Zephyr, so pardon me if this is a trivial question.

At the moment I'm trying Zephyr on my MIMXRT1060_RT and so far I'm satisfied with the experience, everything works as expected.
Except that I also have the display connected, and while I'm able to play with LVGL for the GUI, I don't see, or understand, how to make the touch screen works.

Any help appreciated.

Olivier


MIMXRT1060_EVK touch screen support #input

BOUCARD Olivier
 

Hello,

I'm new to Zephyr, so pardon me if this is a trivial question.

At the moment I'm trying Zephyr on my MIMXRT1060_RT and so far I'm satisfied with the experience, everything works as expected.
Except that I also have the display connected, and while I'm able to play with LVGL for the GUI, I don't see, or understand, how to make the touch screen works.

Any help appreciated.

Olivier


Re: Recursive checkout with West

Jørn Villesen Christensen <extjvc@...>
 

Hi Carles (and others),

On 11/10/2019 21.46, Cufi, Carles wrote:
Hi there,

-----Original Message-----
From: users@... <users@...> On
Behalf Of Jørn Villesen Christensen via Lists.Zephyrproject.Org
Sent: 11 October 2019 21:20
To: users@...
Cc: users@...
Subject: [Zephyr-users] Recursive checkout with West

Hi Zephyr community,

I am a little bit uncertain whether this is the correct list to ask for
help; if not I would appreciate if you could guide me to the correct
place :-)

TLDR: (Current) main question: Is it possible to make West work with
recursive West-based projects? I.e. have a top level project (managed by
West) that has another dependency (Zephyr) that also have a west.yml
file?

A little more background:

I am new to Zephyr and to West, but I am working on a project where we
are considering to use both :-) We do have other external dependencies
and we also have a variety of products that a) uses the same
dependencies (drivers, controllers, etc.) and b) may or may not use
Zephyr, or different configurations of Zephyr.

So in a learning step, we tried to make a top level project that would
depend on Zephyr and another project. The intention was just to see how
West and the build system would behave. What happens is that West is
able to check out the project and to download the dependencies in the
top level west.yml. However, it does not download the dependencies of
Zephyr.

Is this possible? Or is this really unintended use of West (and Zephyr)?
Not currently, but work to support this is ongoing right now, since this has been requested multiple times already and we realize it is a critical feature to have.

Feel free to track progress and add your requirements here:
https://github.com/zephyrproject-rtos/west/issues/221

Thank you for your response and link to the issue you are working on. But it seems to me that what you are working on / discussing is a slightly different issue - or at least different solution (than I had imagined) to the challenges I face. Let me sketch it out.

My vision / idea (a.k.a. recursive parsing):
I envisioned that we had a top level project with a west.yml. Upon running west update, west would check out project dependencies (as today), but then it would examine each of these projects to see if they would contain a west.yml. If so, it would run a west update on those as well, ignoring that it is already in a (parent) west project.

What I understand you are creating:
You are creating functionality to merge multiple west.yml files into one. If I understand correctly, the idea is to write a top-level west template file (west-top.yml) and then merge this with all west.yml files from the project dependencies (that are west projects). This creates a merged west.yml file that the top level project need to maintain.

Have you (as the Zephyr community) considered the recursive parsing approach?

Below are my thoughts on (implementing) this. If you find it interesting, I would love some feedback. If you already considered this (and decided against it) feel free to skip reading the last part of my mail. But I would like to hear your thoughts on the subject :-) (Perhaps you can link me to a discussion elsewhere :) ).

=== Longer story: ===

The main benefits of recursive parsing (as I see it):
The top level project would only have a single west.yml file to maintain - and it would be short. It would not need to keep track of all dependency dependencies. If a project dependency is to be updated, you would not need to run the merge command again (and resolve possible conflicts from intermittent changes).

Challenges in build procedure:
I am not that familiar with West's build system - except that it uses cmake and ninja in the background - but I do realise that special care need to be taken when building project dependencies. As I see it, there are two situations:

  1. If the project is *not* a west-managed project: How are these compiled and linked today? [1]   I would expect the procedures to be transferable to the recursive parsing build procedure - with minor tweaks.
  2. If the project *is* a west-managed project: Normally this project would be the top project and need to be linked to a final executable. But in the recursive parsing scheme, these projects need to be compiled only, and then only linked in the top level project. I guess such logic would be able to be build into the West build system.

[1]: Not really a question. I don't know it, but it is on my todo list to read up upon. So ignore this question unless it has significance for this discussion.

Then there is an issue about duplicated (sub) dependencies:
Say we have a top level project that depends on suba and subb. Each of these two sub projects depends on subc. Here are two situations:

  1. suba and subb both depend on the same version of subc.
  2. suba and subb depend on different versions of subc.

I think the discussion on how to handle this should be deferred to another place than this (already too long) mail - but I guess this is an issue that would also have to be considered in the merge-yml-files approach that you are working on atm.

If you got this far: Thank you for taking your time to read my thoughts :-)

BR
Jørn



Call for help: SAM0 GPIO driver

Carles Cufi
 

Hi all,

As you all know we are currently transitioning to a new GPIO driver API.
With this transition comes the need to port all existing GPIO drivers to the new API, and work for this is currently ongoing.

We have, however, identified a driver that currently has no one assigned to for its port to the new API: SAM0.

We therefore ask for help to all users that either can do the porting work or can test the work on real hardware.
If we cannot find anyone soon we might be forced to drop support for this platform, since we cannot wok on a driver that we do not know well nor have hardware for.

Progress is documented in this issue:
https://github.com/zephyrproject-rtos/zephyr/issues/18530

Thanks in advance,

Carles


Re: Recursive checkout with West

Carles Cufi
 

Hi there,

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Jørn Villesen Christensen via Lists.Zephyrproject.Org
Sent: 11 October 2019 21:20
To: users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: [Zephyr-users] Recursive checkout with West

Hi Zephyr community,

I am a little bit uncertain whether this is the correct list to ask for
help; if not I would appreciate if you could guide me to the correct
place :-)

TLDR: (Current) main question: Is it possible to make West work with
recursive West-based projects? I.e. have a top level project (managed by
West) that has another dependency (Zephyr) that also have a west.yml
file?

A little more background:

I am new to Zephyr and to West, but I am working on a project where we
are considering to use both :-) We do have other external dependencies
and we also have a variety of products that a) uses the same
dependencies (drivers, controllers, etc.) and b) may or may not use
Zephyr, or different configurations of Zephyr.

So in a learning step, we tried to make a top level project that would
depend on Zephyr and another project. The intention was just to see how
West and the build system would behave. What happens is that West is
able to check out the project and to download the dependencies in the
top level west.yml. However, it does not download the dependencies of
Zephyr.

Is this possible? Or is this really unintended use of West (and Zephyr)?
Not currently, but work to support this is ongoing right now, since this has been requested multiple times already and we realize it is a critical feature to have.

Feel free to track progress and add your requirements here:
https://github.com/zephyrproject-rtos/west/issues/221

Regards,

Carles


Re: Recursive checkout with West

Jørn Villesen Christensen <extjvc@...>
 

Now with actual attachment, sorry :-o

On 11/10/2019 21.20, Jørn Villesen Christensen wrote:
Hi Zephyr community,

I am a little bit uncertain whether this is the correct list to ask for
help; if not I would appreciate if you could guide me to the correct
place :-)

TLDR: (Current) main question: Is it possible to make West work with
recursive West-based projects? I.e. have a top level project (managed by
West) that has another dependency (Zephyr) that also have a west.yml file?

A little more background:

I am new to Zephyr and to West, but I am working on a project where we
are considering to use both :-) We do have other external dependencies
and we also have a variety of products that a) uses the same
dependencies (drivers, controllers, etc.) and b) may or may not use
Zephyr, or different configurations of Zephyr.

So in a learning step, we tried to make a top level project that would
depend on Zephyr and another project. The intention was just to see how
West and the build system would behave. What happens is that West is
able to check out the project and to download the dependencies in the
top level west.yml. However, it does not download the dependencies of
Zephyr.

Is this possible? Or is this really unintended use of West (and Zephyr)?

I have added an example west.yml of what I wanted to do to illustrate
the situation :-)

BR
Jørn





Recursive checkout with West

Jørn Villesen Christensen <extjvc@...>
 

Hi Zephyr community,

I am a little bit uncertain whether this is the correct list to ask for
help; if not I would appreciate if you could guide me to the correct
place :-)

TLDR: (Current) main question: Is it possible to make West work with
recursive West-based projects? I.e. have a top level project (managed by
West) that has another dependency (Zephyr) that also have a west.yml file?

A little more background:

I am new to Zephyr and to West, but I am working on a project where we
are considering to use both :-) We do have other external dependencies
and we also have a variety of products that a) uses the same
dependencies (drivers, controllers, etc.) and b) may or may not use
Zephyr, or different configurations of Zephyr.

So in a learning step, we tried to make a top level project that would
depend on Zephyr and another project. The intention was just to see how
West and the build system would behave. What happens is that West is
able to check out the project and to download the dependencies in the
top level west.yml. However, it does not download the dependencies of
Zephyr.

Is this possible? Or is this really unintended use of West (and Zephyr)?

I have added an example west.yml of what I wanted to do to illustrate
the situation :-)

BR
Jørn


West v0.6.3 tagged

Bolivar, Marti
 

Hi,

I am announcing the release of west v0.6.3.

It includes a fix for issue #322, which was backported from the master
branch. This affects Zephyr LTS users with non-ASCII content in their
CMake caches. Users not affected by this issue can ignore this update.

The release can be obtained from:

https://github.com/zephyrproject-rtos/west/releases/tag/v0.6.3
https://pypi.org/project/west/0.6.3/

And installed with one of:

pip3 install --user west==0.6.3
pip3 install west==0.6.3

Thanks,
Marti

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

src/west/cmake.py | 2 +-
src/west/version.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

Attie Grande (1):
resolved UTF-8 encoding issue in CMakeCache, closes #322

Marti Bolivar (1):
West v0.6.3


Re: Build error with west T2 star topology

Marc Herbert
 

On 9 Oct 2019, at 02:05, Attilio Dona <attilio.dona@gmail.com> wrote:

My guess was that for a tagged zephyr release, for example v2.0.0, then there is a v2.0.0 tag on the nordic_hal module, but this is not the case ...
While it's possible, there's no need to tag modules because the west.yml manifest already performs that.


The process of selecting the right modules versions it is quite obscure to me.
A west (or repo) manifest _is_ that process.


works, but if a (current at the time of writing) master revision of zephyr it is used than the compilation fails and a different hal_nordic version must be used.
If you get a different manifest when using a different version of Zephyr, then you MUST run west update -r.


Please give the west documentation another read.


Re: Build error with west T2 star topology

Attilio Dona <attilio.dona@...>
 
Edited

Finally I've found the problem.

adding this entry in west.yml make the compilation ok:

projects:
...
- name: mcumgr revision: 84934959d2d1722a23b7e7e200191ae4a6f96168
  path: modules/lib/mcumgr


Why this originate the error "
cbor_encoder_writer.h: No such file or directory", that is a file which belongs to tinycbor module, it is a complete mistery to me.

I have also noticed that it is somehow difficult to find the right combination of modules version, for me it was just try by errors unless the right fit it is found.

For example:

- name: zephyr
  remote: zephyr
  revision: v2.0.0
  west-commands: scripts/west-commands.yml
- name: hal_nordic
  remote: zephyr
  revision: 7bf2d404d0bf7f36d77d5090b5207f8b4676776c
  path: modules/hal/nordic

works, but if a (current at the time of writing) master revision of zephyr it is used than the compilation fails and a different hal_nordic version must be used.

The process of selecting the right modules versions it is quite obscure to me.

My guess was that for a tagged zephyr release, for example v2.0.0, then there is a v2.0.0 tag on the nordic_hal module, but this is not the case ...  


Re: Build error with west T2 star topology

Bolivar, Marti
 

"Attilio Dona via Lists.Zephyrproject.Org"
<attilio.dona=gmail.com@lists.zephyrproject.org> writes:

I'm trying to setup a T2 topology (Star topology with an application
repository as the manifest repository
<https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported>
).

The most similar problem that I've found it is from the thread
https://lists.zephyrproject.org/g/users/message/1710
but after all the checkings I'm not able to get my setup working.

zhing is the directory of my manifest project, with the following
zhing/west.yml config

manifest:
defaults:
remote: upstream

remotes:
- name: upstream
url-base: https://github.com/attdona
- name: zephyr
url-base: https://github.com/zephyrproject-rtos
- name: juullabs-oss
url-base: https://github.com/JuulLabs-OSS

projects:
- name: net-tools
remote: zephyr
revision: 30b7efa827b04d2e47840716b0372737fe7d6c92
- name: tinycbor
remote: zephyr
path: modules/lib/tinycbor
revision: 31ae89e4b768612722620cb6cb173a0de4a19cc9
- name: zephyr
remote: zephyr
revision: v2.0.0
west-commands: scripts/west-commands.yml
- name: mcuboot
remote: juullabs-oss
revision: 704b8ba4815fc1d214df477676ca6d2eb419a4eb
- name: hal_nordic
remote: zephyr
revision: 7bf2d404d0bf7f36d77d5090b5207f8b4676776c
path: modules/hal/nordic
- name: mbedtls
remote: zephyr
revision: 4bba3b845453033b7ac9ecabb6cf694d8c1381a1
path: modules/crypto/mbedtls

self:
path: zhing


When I build my project I get a compilation error because tinycbor includes
are not present in compilation rules.

Below a build with a build with the zephyrsmp_srv sample that reproduce the
problem.

(zh) adona@attilio-pc:~/tmp/ZHING$ west build -b nrf52840_pca10056
zephyr/samples/subsys/mgmt/mcumgr/smp_svr --pristine
Thanks for including a full log of a pristine build.

-- west build: making build dir /home/adona/tmp/ZHING/build pristine
-- west build: build configuration:
source directory:
/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr
build directory: /home/adona/tmp/ZHING/build
BOARD: nrf52840_pca10056 (origin: command line)
-- west build: generating a build system
Zephyr version: 2.0.0
-- Found PythonInterp: /home/adona/tmp/ZHING/zhing/zh/bin/python (found
suitable version "3.6.8", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
-- Found west: /home/adona/tmp/ZHING/zhing/zh/bin/west (found suitable
version "0.6.2", minimum required is "0.6.0")
-- Loading
/home/adona/tmp/ZHING/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts
as base
-- Overlaying /home/adona/tmp/ZHING/zephyr/dts/common/common.dts
Device tree configuration written to
/home/adona/tmp/ZHING/build/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in /home/adona/tmp/ZHING/zephyr/Kconfig
Loaded configuration
'/home/adona/tmp/ZHING/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig'
Merged configuration
'/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/prj.conf'
Configuration saved to '/home/adona/tmp/ZHING/build/zephyr/.config'
-- Cache files will be written to: /home/adona/.cache/zephyr
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
Including module: tinycbor in path:
/home/adona/tmp/ZHING/modules/lib/tinycbor
Looks like the tinycbor module as found, based on this output.

Including module: nordic in path: /home/adona/tmp/ZHING/modules/hal/nordic
Including module: mbedtls in path:
/home/adona/tmp/ZHING/modules/crypto/mbedtls
-- Configuring done
-- Generating done
-- Build files have been written to: /home/adona/tmp/ZHING/build
-- west build: building application
[1/202] Preparing syscall dependency handling

[117/202] Building C object CMakeFiles/app.dir/src/main.c.obj
FAILED: CMakeFiles/app.dir/src/main.c.obj
ccache /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-DBUILD_VERSION=zephyr-v2.0.0 -DKERNEL -DNRF52840_XXAA -D_FORTIFY_SOURCE=2
-D__ZEPHYR__=1 -I/home/adona/tmp/ZHING/zephyr/kernel/include
-I/home/adona/tmp/ZHING/zephyr/arch/arm/include
-I/home/adona/tmp/ZHING/zephyr/include
-I/home/adona/tmp/ZHING/zephyr/include/drivers -Izephyr/include/generated
-I/home/adona/tmp/ZHING/zephyr/soc/arm/nordic_nrf/nrf52
-I/home/adona/tmp/ZHING/zephyr/soc/arm/nordic_nrf/include
-I/home/adona/tmp/ZHING/zephyr/ext/lib/crypto/tinycrypt/include
-I/home/adona/tmp/ZHING/zephyr/ext/lib/fnmatch/.
-I/home/adona/tmp/ZHING/zephyr/ext/hal/cmsis/Include
-I/home/adona/tmp/ZHING/zephyr/subsys/bluetooth
-I/home/adona/tmp/ZHING/zephyr/subsys/bluetooth/controller/ll_sw/nordic
-I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx
-I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx/drivers/include
-I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx/hal
-I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx/mdk
-I/home/adona/tmp/ZHING/modules/hal/nordic/. -isystem
/home/adona/tmp/ZHING/zephyr/lib/libc/minimal/include -isystem
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/include
-isystem
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/include-fixed
-Os -imacros/home/adona/tmp/ZHING/build/zephyr/include/generated/autoconf.h
-ffreestanding -fno-common -g -mthumb -mcpu=cortex-m4
-imacros/home/adona/tmp/ZHING/zephyr/include/toolchain/zephyr_stdint.h
-Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main
-Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable
-Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic
-fno-strict-overflow -fno-reorder-functions -fno-defer-pop
-fmacro-prefix-map=/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr=CMAKE_SOURCE_DIR
-fmacro-prefix-map=/home/adona/tmp/ZHING/zephyr=ZEPHYR_BASE
-ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99
-nostdinc -MD -MT CMakeFiles/app.dir/src/main.c.obj -MF
CMakeFiles/app.dir/src/main.c.obj.d -o CMakeFiles/app.dir/src/main.c.obj
-c
/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/src/main.c
In file included from
/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/src/main.c:12:
/home/adona/tmp/ZHING/zephyr/include/mgmt/buf.h:11:10: fatal error:
cbor_encoder_writer.h: No such file or directory
#include "cbor_encoder_writer.h"
^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

west is on PATH and tinycbor seems correctly managed:

(zh) adona@attilio-pc:~/tmp/ZHING$ west -V
West version: v0.6.2

(zh) adona@attilio-pc:~/tmp/ZHING$ type west
west is hashed (/home/adona/tmp/ZHING/zhing/zh/bin/west)

(zh) adona@attilio-pc:~/tmp/ZHING$ west list tinycbor
tinycbor modules/lib/tinycbor
31ae89e4b768612722620cb6cb173a0de4a19cc9
https://github.com/zephyrproject-rtos/tinycbor

(zh) adona@attilio-pc:~/tmp/ZHING$ cat build/zephyr_modules.txt
"tinycbor":"/home/adona/tmp/ZHING/modules/lib/tinycbor"
"nordic":"/home/adona/tmp/ZHING/modules/hal/nordic"
"mbedtls":"/home/adona/tmp/ZHING/modules/crypto/mbedtls"
I agree that this all looks fine where the west manifest and zephyr
modules are concerned.


What could be wrong?
The compiler command line for the file which fails to build doesn't have
/home/adona/tmp/ZHING/modules/lib/tinycbor/src on the include path. That
is where cbor_encoder_writer.h is located, so it makes sense that the
build is failing.

Any other check that is it worth to be done?
Looking at tinycbor/CMakeLists.txt, my guess is that somehow
CONFIG_TINYCBOR=n in your build, which is preventing the TINYCBOR
library from being linked into zephyr_interface. Just a guess, though.
You can check /home/adona/tmp/ZHING/build/zephyr/.config to be sure.

On my machine, using the upstream manifest and building the same app,
it's y:

$ grep CONFIG_TINYCBOR build/zephyr/.config
CONFIG_TINYCBOR=y

If you see =n, that's the problem, but then I'm not sure what could be
causing it.

Marti


Thanks for your help,
Attilio


API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will look at:

- GPIO: Update on progress
- Look at the PRs with driver conversion
- Check the timeline
- Debouncing: https://github.com/zephyrproject-rtos/zephyr/issues/19649
- Legacy interrupt config: https://github.com/zephyrproject-rtos/zephyr/issues/19552
- Workaround proposed: https://github.com/zephyrproject-rtos/zephyr/pull/19553

- Sensor API: Update on progress (if the involved parties are present)

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Build error with west T2 star topology

attilio.dona@...
 


The most similar problem that I've found it is from the thread https://lists.zephyrproject.org/g/users/message/1710
but after all the checkings I'm not able to get my setup working. 

zhing is the directory of my manifest project, with the following zhing/west.yml config

manifest:
  defaults:
    remoteupstream

  remotes:
    - nameupstream
      url-basehttps://github.com/attdona
    - namezephyr
    - namejuullabs-oss
      url-basehttps://github.com/JuulLabs-OSS

  projects:
    - namenet-tools
      remotezephyr
      revision30b7efa827b04d2e47840716b0372737fe7d6c92
    - nametinycbor
      remotezephyr
      pathmodules/lib/tinycbor
      revision31ae89e4b768612722620cb6cb173a0de4a19cc9
    - namezephyr
      remotezephyr
      revisionv2.0.0
      west-commandsscripts/west-commands.yml
    - namemcuboot
      remotejuullabs-oss
      revision704b8ba4815fc1d214df477676ca6d2eb419a4eb
    - namehal_nordic
      remotezephyr
      revision7bf2d404d0bf7f36d77d5090b5207f8b4676776c
      pathmodules/hal/nordic
    - namembedtls
      remotezephyr
      revision4bba3b845453033b7ac9ecabb6cf694d8c1381a1
      pathmodules/crypto/mbedtls

  self:
    pathzhing


When I build my project I get a compilation error because tinycbor includes are not present in compilation rules.

Below a build with a build with the zephyrsmp_srv sample that reproduce the problem.

(zh) adona@attilio-pc:~/tmp/ZHING$ west build -b nrf52840_pca10056 zephyr/samples/subsys/mgmt/mcumgr/smp_svr --pristine
-- west build: making build dir /home/adona/tmp/ZHING/build pristine
-- west build: build configuration:
       source directory: /home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr
       build directory: /home/adona/tmp/ZHING/build
       BOARD: nrf52840_pca10056 (origin: command line)
-- west build: generating a build system
Zephyr version: 2.0.0
-- Found PythonInterp: /home/adona/tmp/ZHING/zhing/zh/bin/python (found suitable version "3.6.8", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
-- Found west: /home/adona/tmp/ZHING/zhing/zh/bin/west (found suitable version "0.6.2", minimum required is "0.6.0")
-- Loading /home/adona/tmp/ZHING/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts as base
-- Overlaying /home/adona/tmp/ZHING/zephyr/dts/common/common.dts
Device tree configuration written to /home/adona/tmp/ZHING/build/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in /home/adona/tmp/ZHING/zephyr/Kconfig
Loaded configuration '/home/adona/tmp/ZHING/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig'
Merged configuration '/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/prj.conf'
Configuration saved to '/home/adona/tmp/ZHING/build/zephyr/.config'
-- Cache files will be written to: /home/adona/.cache/zephyr
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
Including module: tinycbor in path: /home/adona/tmp/ZHING/modules/lib/tinycbor
Including module: nordic in path: /home/adona/tmp/ZHING/modules/hal/nordic
Including module: mbedtls in path: /home/adona/tmp/ZHING/modules/crypto/mbedtls
-- Configuring done
-- Generating done
-- Build files have been written to: /home/adona/tmp/ZHING/build
-- west build: building application
[1/202] Preparing syscall dependency handling

[117/202] Building C object CMakeFiles/app.dir/src/main.c.obj
FAILED: CMakeFiles/app.dir/src/main.c.obj
ccache /opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=zephyr-v2.0.0 -DKERNEL -DNRF52840_XXAA -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I/home/adona/tmp/ZHING/zephyr/kernel/include -I/home/adona/tmp/ZHING/zephyr/arch/arm/include -I/home/adona/tmp/ZHING/zephyr/include -I/home/adona/tmp/ZHING/zephyr/include/drivers -Izephyr/include/generated -I/home/adona/tmp/ZHING/zephyr/soc/arm/nordic_nrf/nrf52 -I/home/adona/tmp/ZHING/zephyr/soc/arm/nordic_nrf/include -I/home/adona/tmp/ZHING/zephyr/ext/lib/crypto/tinycrypt/include -I/home/adona/tmp/ZHING/zephyr/ext/lib/fnmatch/. -I/home/adona/tmp/ZHING/zephyr/ext/hal/cmsis/Include -I/home/adona/tmp/ZHING/zephyr/subsys/bluetooth -I/home/adona/tmp/ZHING/zephyr/subsys/bluetooth/controller/ll_sw/nordic -I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx -I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx/drivers/include -I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx/hal -I/home/adona/tmp/ZHING/modules/hal/nordic/nrfx/mdk -I/home/adona/tmp/ZHING/modules/hal/nordic/. -isystem /home/adona/tmp/ZHING/zephyr/lib/libc/minimal/include -isystem /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/include -isystem /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/include-fixed -Os -imacros/home/adona/tmp/ZHING/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m4 -imacros/home/adona/tmp/ZHING/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/adona/tmp/ZHING/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99 -nostdinc -MD -MT CMakeFiles/app.dir/src/main.c.obj -MF CMakeFiles/app.dir/src/main.c.obj.d -o CMakeFiles/app.dir/src/main.c.obj   -c /home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/src/main.c
In file included from /home/adona/tmp/ZHING/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/src/main.c:12:
/home/adona/tmp/ZHING/zephyr/include/mgmt/buf.h:11:10: fatal error: cbor_encoder_writer.h: No such file or directory
 #include "cbor_encoder_writer.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

west is on PATH and tinycbor seems correctly managed:

(zh) adona@attilio-pc:~/tmp/ZHING$ west -V
West version: v0.6.2

(zh) adona@attilio-pc:~/tmp/ZHING$ type west
west is hashed (/home/adona/tmp/ZHING/zhing/zh/bin/west)
 
(zh) adona@attilio-pc:~/tmp/ZHING$ west list tinycbor
tinycbor     modules/lib/tinycbor         31ae89e4b768612722620cb6cb173a0de4a19cc9 https://github.com/zephyrproject-rtos/tinycbor

(zh) adona@attilio-pc:~/tmp/ZHING$ cat build/zephyr_modules.txt 
"tinycbor":"/home/adona/tmp/ZHING/modules/lib/tinycbor"
"nordic":"/home/adona/tmp/ZHING/modules/hal/nordic"
"mbedtls":"/home/adona/tmp/ZHING/modules/crypto/mbedtls"

What could be wrong? 
Any other check that is it worth to be done?

Thanks for your help,
Attilio


Re: build failed due to missing headers

Stephane D'Alu
 

On 10/4/19 9:12 PM, Lawrence King wrote:
Hi Stephane:
Charles and I went through the Getting Started guide a month or so ago, getting ~/.local/bin into the path was one of thing I had tripped over, and we made sure it was in the getting started guide, normally west is installed in ~/.local/bin/west and we made sure you put this in your path. See: https://docs.zephyrproject.org/latest/getting_started/index.html#install-host-dependencies
Shame on me, I missed it :(

Lawrence King
Principal Developer
+1(416)627-7302
-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Stephane D'Alu
Sent: Friday, October 4, 2019 2:58 PM
To: Bolivar, Marti <marti.bolivar@nordicsemi.no>; Cufi, Carles <Carles.Cufi@nordicsemi.no>; users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers
On 10/4/19 8:35 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 7:52 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 5:38 PM, Stephane D'Alu wrote:
On 10/4/19 5:09 PM, Cufi, Carles wrote:


-----Original Message-----
From: users@lists.zephyrproject.org
<users@lists.zephyrproject.org> On Behalf Of Stephane D'Alu via
Lists.Zephyrproject.Org
Sent: 04 October 2019 14:48
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers

On 10/4/19 2:07 PM, Cufi, Carles wrote:


On 10/4/19 1:50 PM, Cufi, Carles wrote:
Hi there,

I'm doing (west version is 0.6.2):
     west build -b nrf52840_mdk samples/basic/blinky

and got:
...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error:
nrfx.h: No such file or directory
     #include <nrfx.h>
              ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


Any idea, on what is wrong and how to fix it?
Works fine here, are you sure you ran "west update"?

[...]
Can you try removing the entire
/home/sdalu/Z/zephyrproject/zephyr/build folder and building
again? It might be an issue with stale build files.
Same thing:

$ rm -rf build
$ ~/.local/bin/west -vvv build -b nrf52840_mdk samples/basic/blinky ...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No
such file or directory
   #include <nrfx.h>
            ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


I attached the full log
Right, but I noticed now that your .zephyrrc ontains:

my ~/.zephyrrc:
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export
CROSS_COMPILE=/usr/local/gcc-arm-embedded/bin/arm-none-eabi-
export HOSTCC=cc
Could you try using ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb and
GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded/ instead?
See here:
https://docs.zephyrproject.org/latest/getting_started/toolchain_3
rd_party_x_compilers.html#gnu-arm-embedded


I think that cross-compile is valid to use when your toolchain is
installed in a certain way (using your distro's package manager?)
whereas gnuarmemb is the right one to use when you download the
GNU Arm Embedded toolchain and place it somewhere in your disk.

~/.zypherrc is now:
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded
export HOSTCC=cc


I removed the build directory, started a new session so that env
is correctly loaded with new values



Same error :(
Note also, that I'm on freebsd, that's shouldn't impact the way
build is working, but perhaps something is not done correctly in west ?
Can you check for a line like this in build/zephyr_modules.txt?

$ grep nordic build/zephyr_modules.txt
"nordic":"/home/mbolivar/zp/modules/hal/nordic"
don't have such file
That's your problem, then. If you're doing a pristine build and the
build system finds west on PATH, it ought to be generating this file.

Looking at your full log, I see:

-- Selected BOARD nrf52840_mdk
-- Loading
/home/sdalu/Z/zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_md
k.dts
as base

On my system, I get:

-- Selected BOARD nrf52840_pca10056
-- Found west: /home/mbolivar/.virtualenvs/west-dev/bin/west (found
suitable version "0.6.99", minimum required is "0.6.0")
-- Loading
/home/mbolivar/zp/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca1005
6.dts as base

Note "Found west" appears in my output, but not yours.

Can you please make sure 'west' is on PATH and try again with a
pristine build directory?
You got it! That was related to west not being in the PATH.
It is now compiling fine, thanks
Perhaps it could be usefudl for other to add a note in the getting started guide, that west must be accessible using PATH

--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925


Re: build failed due to missing headers

Bolivar, Marti
 

"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

You got it! That was related to west not being in the PATH.
It is now compiling fine, thanks
Great!

Perhaps it could be usefudl for other to add a note in the getting
started guide, that west must be accessible using PATH
I don't know how pip3 works on FreeBSD, but the instructions in the
getting started guide were designed so that binaries obtained with "pip3
install" -- west is one of them -- do end up on PATH for supported
platforms (Linux, macOS, Windows). So I think this is covered.

Thanks,
Marti


Re: build failed due to missing headers

Lawrence King
 

Hi Stephane:

Charles and I went through the Getting Started guide a month or so ago, getting ~/.local/bin into the path was one of thing I had tripped over, and we made sure it was in the getting started guide, normally west is installed in ~/.local/bin/west and we made sure you put this in your path. See: https://docs.zephyrproject.org/latest/getting_started/index.html#install-host-dependencies

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Stephane D'Alu
Sent: Friday, October 4, 2019 2:58 PM
To: Bolivar, Marti <marti.bolivar@nordicsemi.no>; Cufi, Carles <Carles.Cufi@nordicsemi.no>; users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers

On 10/4/19 8:35 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 7:52 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 5:38 PM, Stephane D'Alu wrote:
On 10/4/19 5:09 PM, Cufi, Carles wrote:


-----Original Message-----
From: users@lists.zephyrproject.org
<users@lists.zephyrproject.org> On Behalf Of Stephane D'Alu via
Lists.Zephyrproject.Org
Sent: 04 October 2019 14:48
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers

On 10/4/19 2:07 PM, Cufi, Carles wrote:


On 10/4/19 1:50 PM, Cufi, Carles wrote:
Hi there,

I'm doing (west version is 0.6.2):
     west build -b nrf52840_mdk samples/basic/blinky

and got:
...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error:
nrfx.h: No such file or directory
     #include <nrfx.h>
              ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


Any idea, on what is wrong and how to fix it?
Works fine here, are you sure you ran "west update"?

[...]
Can you try removing the entire
/home/sdalu/Z/zephyrproject/zephyr/build folder and building
again? It might be an issue with stale build files.
Same thing:

$ rm -rf build
$ ~/.local/bin/west -vvv build -b nrf52840_mdk samples/basic/blinky ...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No
such file or directory
   #include <nrfx.h>
            ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


I attached the full log
Right, but I noticed now that your .zephyrrc ontains:

my ~/.zephyrrc:
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export
CROSS_COMPILE=/usr/local/gcc-arm-embedded/bin/arm-none-eabi-
export HOSTCC=cc
Could you try using ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb and
GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded/ instead?
See here:
https://docs.zephyrproject.org/latest/getting_started/toolchain_3
rd_party_x_compilers.html#gnu-arm-embedded


I think that cross-compile is valid to use when your toolchain is
installed in a certain way (using your distro's package manager?)
whereas gnuarmemb is the right one to use when you download the
GNU Arm Embedded toolchain and place it somewhere in your disk.

~/.zypherrc is now:
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded
export HOSTCC=cc


I removed the build directory, started a new session so that env
is correctly loaded with new values



Same error :(
Note also, that I'm on freebsd, that's shouldn't impact the way
build is working, but perhaps something is not done correctly in west ?
Can you check for a line like this in build/zephyr_modules.txt?

$ grep nordic build/zephyr_modules.txt
"nordic":"/home/mbolivar/zp/modules/hal/nordic"
don't have such file
That's your problem, then. If you're doing a pristine build and the
build system finds west on PATH, it ought to be generating this file.

Looking at your full log, I see:

-- Selected BOARD nrf52840_mdk
-- Loading
/home/sdalu/Z/zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_md
k.dts
as base

On my system, I get:

-- Selected BOARD nrf52840_pca10056
-- Found west: /home/mbolivar/.virtualenvs/west-dev/bin/west (found
suitable version "0.6.99", minimum required is "0.6.0")
-- Loading
/home/mbolivar/zp/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca1005
6.dts as base

Note "Found west" appears in my output, but not yours.

Can you please make sure 'west' is on PATH and try again with a
pristine build directory?
You got it! That was related to west not being in the PATH.
It is now compiling fine, thanks


Perhaps it could be usefudl for other to add a note in the getting started guide, that west must be accessible using PATH


--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925


Re: build failed due to missing headers

Stephane D'Alu
 

On 10/4/19 8:35 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 7:52 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 5:38 PM, Stephane D'Alu wrote:
On 10/4/19 5:09 PM, Cufi, Carles wrote:


-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Stephane D'Alu via Lists.Zephyrproject.Org
Sent: 04 October 2019 14:48
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers

On 10/4/19 2:07 PM, Cufi, Carles wrote:


On 10/4/19 1:50 PM, Cufi, Carles wrote:
Hi there,

I'm doing (west version is 0.6.2):
     west build -b nrf52840_mdk samples/basic/blinky

and got:
...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No
such file or directory
     #include <nrfx.h>
              ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


Any idea, on what is wrong and how to fix it?
Works fine here, are you sure you ran "west update"?

[...]
Can you try removing the entire
/home/sdalu/Z/zephyrproject/zephyr/build folder and building again? It
might be an issue with stale build files.
Same thing:

$ rm -rf build
$ ~/.local/bin/west -vvv build -b nrf52840_mdk samples/basic/blinky ...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such
file or directory
   #include <nrfx.h>
            ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


I attached the full log
Right, but I noticed now that your .zephyrrc ontains:

my ~/.zephyrrc:
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/local/gcc-arm-embedded/bin/arm-none-eabi-
export HOSTCC=cc
Could you try using ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb and
GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded/ instead?
See here:
https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded


I think that cross-compile is valid to use when your toolchain is
installed in a certain way (using your distro's package manager?)
whereas gnuarmemb is the right one to use when you download the GNU
Arm Embedded toolchain and place it somewhere in your disk.

~/.zypherrc is now:
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded
export HOSTCC=cc


I removed the build directory, started a new session so that env is
correctly loaded with new values



Same error :(
Note also, that I'm on freebsd, that's shouldn't impact the way build is
working, but perhaps something is not done correctly in west ?
Can you check for a line like this in build/zephyr_modules.txt?

$ grep nordic build/zephyr_modules.txt
"nordic":"/home/mbolivar/zp/modules/hal/nordic"
don't have such file
That's your problem, then. If you're doing a pristine build and the build
system finds west on PATH, it ought to be generating this file.
Looking at your full log, I see:
-- Selected BOARD nrf52840_mdk
-- Loading
/home/sdalu/Z/zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts
as base
On my system, I get:
-- Selected BOARD nrf52840_pca10056
-- Found west: /home/mbolivar/.virtualenvs/west-dev/bin/west (found suitable version "0.6.99", minimum required is "0.6.0")
-- Loading /home/mbolivar/zp/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts as base
Note "Found west" appears in my output, but not yours.
Can you please make sure 'west' is on PATH and try again with a pristine
build directory?
You got it! That was related to west not being in the PATH.
It is now compiling fine, thanks


Perhaps it could be usefudl for other to add a note in the getting started guide, that west must be accessible using PATH


--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925


Re: build failed due to missing headers

Bolivar, Marti
 

"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 7:52 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 5:38 PM, Stephane D'Alu wrote:
On 10/4/19 5:09 PM, Cufi, Carles wrote:


-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Stephane D'Alu via Lists.Zephyrproject.Org
Sent: 04 October 2019 14:48
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers

On 10/4/19 2:07 PM, Cufi, Carles wrote:


On 10/4/19 1:50 PM, Cufi, Carles wrote:
Hi there,

I'm doing (west version is 0.6.2):
     west build -b nrf52840_mdk samples/basic/blinky

and got:
...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No
such file or directory
     #include <nrfx.h>
              ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


Any idea, on what is wrong and how to fix it?
Works fine here, are you sure you ran "west update"?

[...]
Can you try removing the entire
/home/sdalu/Z/zephyrproject/zephyr/build folder and building again? It
might be an issue with stale build files.
Same thing:

$ rm -rf build
$ ~/.local/bin/west -vvv build -b nrf52840_mdk samples/basic/blinky ...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such
file or directory
   #include <nrfx.h>
            ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


I attached the full log
Right, but I noticed now that your .zephyrrc ontains:

my ~/.zephyrrc:
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/local/gcc-arm-embedded/bin/arm-none-eabi-
export HOSTCC=cc
Could you try using ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb and
GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded/ instead?
See here:
https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded


I think that cross-compile is valid to use when your toolchain is
installed in a certain way (using your distro's package manager?)
whereas gnuarmemb is the right one to use when you download the GNU
Arm Embedded toolchain and place it somewhere in your disk.

~/.zypherrc is now:
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded
export HOSTCC=cc


I removed the build directory, started a new session so that env is
correctly loaded with new values



Same error :(
Note also, that I'm on freebsd, that's shouldn't impact the way build is
working, but perhaps something is not done correctly in west ?
Can you check for a line like this in build/zephyr_modules.txt?

$ grep nordic build/zephyr_modules.txt
"nordic":"/home/mbolivar/zp/modules/hal/nordic"
don't have such file
That's your problem, then. If you're doing a pristine build and the build
system finds west on PATH, it ought to be generating this file.

Looking at your full log, I see:

-- Selected BOARD nrf52840_mdk
-- Loading
/home/sdalu/Z/zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts
as base

On my system, I get:

-- Selected BOARD nrf52840_pca10056
-- Found west: /home/mbolivar/.virtualenvs/west-dev/bin/west (found suitable version "0.6.99", minimum required is "0.6.0")
-- Loading /home/mbolivar/zp/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts as base

Note "Found west" appears in my output, but not yours.

Can you please make sure 'west' is on PATH and try again with a pristine
build directory?


sdalu@hyperion:~/Z/zephyrproject$ find . -name 'zephyr_modules.txt'
// no files reported //




You can also try running "west list -f {abspath} hal_nordic" to see if
the module is found by west on your system. If not, that is in fact the
problem. If so, it's an issue higher up in the stack.
Guessing that abspath is ~/Z/zephyrproject in my case ?
I really meant to copy paste that exact string, hehe.

The -f option is a (python) format string specifier, and {abspath} means
"put the absolute path of the project here". The default -f is
"{name:12} {path:28} {revision:40} {url}", which is more information
than we need here, so I was suggesting a shorter command that would get
to the heart of the issue (as the build system runs plain "west list -f
{abspath}" to print the absolute paths of all the projects in the
manfiest).

You can see 'west list -h' for more details.


$ ~/.local/bin/west list -f ~/Z/zephyrproject/ hal_nordic
/home/sdalu/Z/zephyrproject/
This is equivalent to "echo ~/Z/zephyrproject/", so it's not quite
helpful here.

Thanks!
Marti



in ~/Z/zephyrproject, I have a modules directory with nordic files
$ ls modules/hal/nordic
CMakeLists.txt nrfx_config_nrf52811.h nrfx_glue.c
drivers nrfx_config_nrf52832.h nrfx_glue.h
nrfx nrfx_config_nrf52840.h nrfx_log.h
nrfx_config_nrf51.h nrfx_config_nrf9160.h zephyr
nrfx_config_nrf52810.h nrfx_config.h




Marti




--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925


--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925


Re: build failed due to missing headers

Stephane D'Alu
 

On 10/4/19 7:52 PM, Bolivar, Marti wrote:
"Stephane D'Alu via Lists.Zephyrproject.Org"
<stephane.dalu=insa-lyon.fr@lists.zephyrproject.org> writes:

On 10/4/19 5:38 PM, Stephane D'Alu wrote:
On 10/4/19 5:09 PM, Cufi, Carles wrote:


-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Stephane D'Alu via Lists.Zephyrproject.Org
Sent: 04 October 2019 14:48
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] build failed due to missing headers

On 10/4/19 2:07 PM, Cufi, Carles wrote:


On 10/4/19 1:50 PM, Cufi, Carles wrote:
Hi there,

I'm doing (west version is 0.6.2):
     west build -b nrf52840_mdk samples/basic/blinky

and got:
...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No
such file or directory
     #include <nrfx.h>
              ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


Any idea, on what is wrong and how to fix it?
Works fine here, are you sure you ran "west update"?

[...]
Can you try removing the entire
/home/sdalu/Z/zephyrproject/zephyr/build folder and building again? It
might be an issue with stale build files.
Same thing:

$ rm -rf build
$ ~/.local/bin/west -vvv build -b nrf52840_mdk samples/basic/blinky ...
...
../soc/arm/nordic_nrf/nrf52/soc.h:16:10: fatal error: nrfx.h: No such
file or directory
   #include <nrfx.h>
            ^~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.


I attached the full log
Right, but I noticed now that your .zephyrrc ontains:

my ~/.zephyrrc:
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/local/gcc-arm-embedded/bin/arm-none-eabi-
export HOSTCC=cc
Could you try using ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb and
GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded/ instead?
See here:
https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded


I think that cross-compile is valid to use when your toolchain is
installed in a certain way (using your distro's package manager?)
whereas gnuarmemb is the right one to use when you download the GNU
Arm Embedded toolchain and place it somewhere in your disk.

~/.zypherrc is now:
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/usr/local/gcc-arm-embedded
export HOSTCC=cc


I removed the build directory, started a new session so that env is
correctly loaded with new values



Same error :(
Note also, that I'm on freebsd, that's shouldn't impact the way build is
working, but perhaps something is not done correctly in west ?
Can you check for a line like this in build/zephyr_modules.txt?
$ grep nordic build/zephyr_modules.txt
"nordic":"/home/mbolivar/zp/modules/hal/nordic"
don't have such file

sdalu@hyperion:~/Z/zephyrproject$ find . -name 'zephyr_modules.txt'
// no files reported //




You can also try running "west list -f {abspath} hal_nordic" to see if
the module is found by west on your system. If not, that is in fact the
problem. If so, it's an issue higher up in the stack.
Guessing that abspath is ~/Z/zephyrproject in my case ?

$ ~/.local/bin/west list -f ~/Z/zephyrproject/ hal_nordic
/home/sdalu/Z/zephyrproject/


in ~/Z/zephyrproject, I have a modules directory with nordic files
$ ls modules/hal/nordic
CMakeLists.txt nrfx_config_nrf52811.h nrfx_glue.c
drivers nrfx_config_nrf52832.h nrfx_glue.h
nrfx nrfx_config_nrf52840.h nrfx_log.h
nrfx_config_nrf51.h nrfx_config_nrf9160.h zephyr
nrfx_config_nrf52810.h nrfx_config.h



Marti




--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925


--
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 8925

721 - 740 of 2455