Hello,

I am trying to setup Eclipse with GNU MCU Eclipse plugin as an IDE debugger for Zephyr under Ubuntu 19.04. That is mainly in hopes to be able to debug with multiple threads, since I can't seem to get the gdb to detect more than thread at a time, even with the application configured with CONFIG_OPENOCD_SUPPORT=y set. For the test I'm using the Philosophers example provided by Zephyr.

So far I've been following the guide in the zephyr documentation and completed the configuration, but when I try to debug the program I get the following error:

Error in services launch sequence

Launching command [/home/pnimac/.local/bin/pyocd gdbserver --port 3333 --telnet-port 4444 --frequency 8000000 --pack="/home/pnimac/pyocd-packs/Keil.STM32F4xx_DFP.2.14.0.pack" -c echo "Started by GNU MCU Eclipse"] failed.

Launching command [/home/pnimac/.local/bin/pyocd gdbserver --port 3333 --telnet-port 4444 --frequency 8000000 --pack="/home/pnimac/pyocd-packs/Keil.STM32F4xx_DFP.2.14.0.pack" -c echo "Started by GNU MCU Eclipse"] failed.

Cannot run program "/home/pnimac/.local/bin/pyocd gdbserver": Unknown reason

Hello Marti,

On Fri, 6 Sep 2019 17:41:56 +0000
"Bolivar, Marti" <Marti.Bolivar@nordicsemi.no> wrote:

Hi Paul,

These are important questions, and I'm glad you've asked them. I will
try to provide a fair amount of detail along with short answers.

[]

Of course, no test suite is perfect, but I hope this addresses your
concerns, or at least answers your questions. We're always trying to
improve the test suite and welcome any suggestions.

It definitely does, and I much appreciate the detailed response
(hopefully you wrote it not just as a response, but also a checklist
for yourself, confirming there're no obvious things missed). It
actually took some time to go in detail thru it, and I agree that good
thought was put into various cases, it works close to the best possible
(and I'm conservative only because I didn't use it much enough).

To address a potential follow-up, I am looking into adding better
coverage metrics to the test suite (it's tricky because a lot of the

Sounds great, and even the test file you referred to is 20K, so testing
coverage is definitely not "bare". My only concern would be that
maintaining west has become a non-trivial endeavor, but I guess, that
part is covered, so all readers of the original and this thread should
be happy about it!


Thanks again!

Thanks,
Marti

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hi all,

This week we will look at:

- GPIO: Update on progress
- Roadmap for GPIO inclusion: https://github.com/zephyrproject-rtos/zephyr/issues/18530
- Merge https://github.com/zephyrproject-rtos/zephyr/pull/16648 to topic-gpio

- V4Z: Quick update on PR status https://github.com/zephyrproject-rtos/zephyr/pull/17194

- Sensor API: Update on progress

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,

Hi,

I was sent the below link recently regarding CVE2018-5383 and I was curious if there was any issue with Zephyr's Bluetooth implementation. I did a search through the mailing list, github and documentation but couldn't find anything.

http://www.cs.technion.ac.il/~biham/BT/bt-fixed-coordinate-invalid-curve-attack.pdf

Is there a status on this?

Thanks

Thanks Martí for the extensive explanation.

I just want to add one more comment

b) "Is it true that west, when
asked to update modules, doesn't run any workcopy-destructive
commands, like git reset, some forms of git checkout; or, if it does,
it first performs (regression-tested) check for local changes in the
corresponding modules ?"

The default "west update" behavior uses "git checkout --detach".

From git-checkout(1):

Prepare to work on top of <commit>, by detaching HEAD at
it (see "DETACHED HEAD" section), and updating the index
and the files in the working tree. Local modifications to
the files in the working tree are kept, so that the
resulting working tree will be the state recorded in the
commit plus the local modifications.

Beyond preserving working tree state (unless there is a bug in git
itself), this leaves your existing branches behind untouched.

This is also the rationale behind leaving west projects in a detached HEAD state. If we were to use a specific branch name there would be potential for name collisions with local branches, as well as the potential for the emergence of serious bugs in the logic that would handle the branch maintenance and switching.

Carles

Hi Paul,

These are important questions, and I'm glad you've asked them. I will
try to provide a fair amount of detail along with short answers.

Paul Sokolovsky <paul.sokolovsky@linaro.org> writes:

Hello Marti,

On Wed, 4 Sep 2019 16:39:22 +0000
"Bolivar, Marti" <marti.bolivar@nordicsemi.no> wrote:

Marti Bolivar <marti.bolivar@nordicsemi.no> writes:

Hi,

West v0.6.1 contains a ... bug ...

It won't cause data loss, but it will cause west update to fail to
check out the correct revision in some cases.

Speaking of data loss... I figure I have local changes in modules
managed (stroked thru) initially checked out by west. Can west be
trusted:

1) To never touch those changes during normal development process, i.e.
building and running apps?

Short answer is "yes".

First, west doesn't change the contents of the manifest repository,
ever. In upstream zephyr's case, that means builtin west commands won't
edit files in the zephyr repository, only read them. The lone exception
is "west init", which is used upstream to clone the zephyr repository
itself. And if you try to run "west init" again in a way that would
touch an existing installation, it aborts without doing anything -- in
part, to avoid touching existing files in unexpected ways.

This behavior is tested, e.g.:

https://github.com/zephyrproject-rtos/west/blob/master/tests/test_project.py#L227

You can of course shoot yourself in the foot with something like this:

$ west forall -c "rm -rf .git *" # DO NOT RUN THIS

but I don't think that's what you're asking about.

Side note:
this is unlike Google repo, which pulls and can rebase the
manifest repository when you run "repo sync", then attempts to
rebase all your local working copies. I've seen this cause lots of
problems, so not touching zephyr (and not rebasing modules by
default) was an important constraint when we were designing west.

Second, none of the west extension commands in the zephyr repository
(completion, boards, build, sign, flash, debug, debugserver, attach) run
git, so they won't check out any changes that way.

There are of course ways to shoot yourself in the foot with the zephyr
extensions by asking them to overwrite a file in your working copy or
build directory you care about, e.g.:

$ west sign [...] -B some-file-i-care-about
$ west build --pristine=always -d build-dir-with-unsaved-.config-changes

But, well, "you asked for it, you got it" (YAFIYGI).

2) To likewise never overwrite those changes on "west update"?

Not by default; see below.

I guess it boils down to questions: a) "Is it true that west never tries
to perform any unattended module updates, and does that only if
explicitly asked (west update)" and

Updates to modules via git only happens during west update -- again,
barring YAFIYGI commands like:

$ west forall -c "git reset --hard HEAD"

West doesn't perform unattended updates. I personally hate tools that
update me without asking first. West won't download updates and ask you
if you want to apply them (like a web browser), either: you need to
explicitly ask west to pull changes from the network and/or apply them to
your working trees.

b) "Is it true that west, when
asked to update modules, doesn't run any workcopy-destructive commands,
like git reset, some forms of git checkout; or, if it does, it first
performs (regression-tested) check for local changes in the
corresponding modules ?"

The default "west update" behavior uses "git checkout --detach".

From git-checkout(1):

Prepare to work on top of <commit>, by detaching HEAD at
it (see "DETACHED HEAD" section), and updating the index
and the files in the working tree. Local modifications to
the files in the working tree are kept, so that the
resulting working tree will be the state recorded in the
commit plus the local modifications.

Beyond preserving working tree state (unless there is a bug in git
itself), this leaves your existing branches behind untouched.

This is also tested, e.g.:

https://github.com/zephyrproject-rtos/west/blob/master/tests/test_project.py#L186

Note that if local changes conflict with what would be checked out, git
checkout --detach simply fails with "Your local changes to the following
files would be overwritten by checkout: <list-of-files>".

In that case, "west update" fails on that project, keeps going to the
others, and ultimately exits with an error. I would argue it has done
the right thing by leaving your code alone in the problematic project,
while trying to do its job everywhere it can.

When that happens, "west update" also prints an error at the very end of
the command output alerting you that something went wrong, like this:

ERROR: update failed for projects: <list-of-failed-projects>

This is meant to help the user in case the error output scrolls past
their terminal window too quickly.

Now, you *can* ask west to rebase locally checked out branches with
"west update --rebase" -- YAFIYGI.

Of course, no test suite is perfect, but I hope this addresses your
concerns, or at least answers your questions. We're always trying to
improve the test suite and welcome any suggestions.

To address a potential follow-up, I am looking into adding better
coverage metrics to the test suite (it's tricky because a lot of the
code is run in python subprocesses, as is the case in the above
test_project.py example, so coverage from those runs needs to be
collected and combined to produce meaningful results). From there, we
can look at what's missing and make improvements.

That of course does not address behavioral concerns like "what happens
to my working tree in this situation?", which is a separate and ongoing
effort. If you have any specific concerns, please let me know and I'll
do my best to add missing tests as needed.

Thanks,
Marti

Hello Marti,

On Wed, 4 Sep 2019 16:39:22 +0000
"Bolivar, Marti" <marti.bolivar@nordicsemi.no> wrote:

Marti Bolivar <marti.bolivar@nordicsemi.no> writes:

Hi,

West v0.6.1 contains a ... bug ...

It won't cause data loss, but it will cause west update to fail to
check out the correct revision in some cases.

Speaking of data loss... I figure I have local changes in modules
managed (stroked thru) initially checked out by west. Can west be
trusted:

1) To never touch those changes during normal development process, i.e.
building and running apps?
2) To likewise never overwrite those changes on "west update"?

I guess it boils down to questions: a) "Is it true that west never tries
to perform any unattended module updates, and does that only if
explicitly asked (west update)" and b) "Is it true that west, when
asked to update modules, doesn't run any workcopy-destructive commands,
like git reset, some forms of git checkout; or, if it does, it first
performs (regression-tested) check for local changes in the
corresponding modules ?"

Thanks.

Marti

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

I'm looking for information on supporting a #usb based wifi adapter, with or without off-loaded stack support?

--tnx
--tom

Hi all,

We are trying to optimise our device for BLE advertisement reception.  We are using Zephyr 1.14 with a nRF52832 module that is configured for up to 4 BLE connections (with our device acting as the peripheral).  The scanning is set as passive and is set for 100% scanning with a interval of 60ms and a window of 60ms.  Also we are not currently using the experimental split controller.

We are also using the default BLE connection perferred parameters:

From what I have read the default Zephyr 1.14 BLE controller doesn't always switch to scanning when not servicing connections or advertising but can be blocked from scanning if a schedualled advertising/connection need conflicts.

Without empirically testing I was wondering if I could get some theoretical tips on what would be a good starting point?

Thanks,

Nick Ward

Hi,
Please let me know if there is a way to restrict advertising to a given primary channel. I am using nRF52840 USB dongle.

Rgds,
Venkat.

"leonardomt via Lists.Zephyrproject.Org"
<leonardomt=gmail.com@lists.zephyrproject.org> writes:

Hi and thanks for your prompt response!

I tried both toolchains, gnuarmemb and zephyr.

I can successfully load a zephyr project *without cpp support* into Segger (as in the link) or Eclipse and compile, flash and debug just fine.
Also, you are right in that everything works as expected when using the command line, no matter if the project is c or cpp.

The issue only occurs when you use Eclipse to import a project that requires cpp support:
Eclipse wont recognize some functions (such as printk) and some symbols, instead it will highlight them as if they were not declared anywhere.

Just to make sure I understood correctly, you successfully built the
project (the cpp version; main.c --> main.cpp), but did you import it
into Eclipse and got no errors after indexing finished?

No, sorry, I just built it on the command line.

I read that Eclipse has two separate tools for indexing and resolving
symbols/function so I wonder if this error has anything to do with the
configuration in Eclipse as opposed to the cmake generator. Another
likely situation is that I am not setting things right... either way,
help is appreciated!

I'm not an Eclipse user, sorry :(. It does sound like there's something
wrong with the way either linking or symbol resolution is going on in
Eclipse, though.

Sorry I couldn't be more help. I thought you were seeing this issue on
the command line.

Marti

Thanks!
Leo

Hi and thanks for your prompt response!

I tried both toolchains, gnuarmemb and zephyr.

I can successfully load a zephyr project *without cpp support* into Segger (as in the link) or Eclipse and compile, flash and debug just fine.
Also, you are right in that everything works as expected when using the command line, no matter if the project is c or cpp.

The issue only occurs when you use Eclipse to import a project that requires cpp support:
Eclipse wont recognize some functions (such as printk) and some symbols, instead it will highlight them as if they were not declared anywhere.

Just to make sure I understood correctly, you successfully built the project (the cpp version; main.c --> main.cpp), but did you import it into Eclipse and got no errors after indexing finished?

I read that Eclipse has two separate tools for indexing and resolving symbols/function so I wonder if this error has anything to do with the configuration in Eclipse as opposed to the cmake generator. Another likely situation is that I am not setting things right... either way, help is appreciated!

Thanks!
Leo

"leonardomt via Lists.Zephyrproject.Org"
<leonardomt=gmail.com@lists.zephyrproject.org> writes:

Hello!

Hi again!

I am failing to create a Zephyr project for Eclipse with C++ support.
Is there a working example or guide I can use as reference to set this up?
My end goal is to use Zephyr + nRF SDK in C++ with debugging in any IDE, preferably SEGGER or Eclipse.

After importing project "hello_world", Eclipse underlines function "printk" in red:
==> Function 'printk' could not be resolved <==
==> Symbol 'CONFIG_BOARD' could not be resolved <==

Here's the steps I follow to setup the project:
Toolchain:
Zephyr 2.0.0
west v0.6.0
ninja 1.9.0
cmake 3.15.2
Eclipse 4.12 + GNU MCU 4.5.1

Edit prj.conf and .config:
CONFIG_PRINTK=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_NEWLIB_LIBC=y
CONFIG_LIB_CPLUSPLUS=y

I copied these into samples/hello_world/prj.conf, but:

Run:
west build -b nrf52840_pca10056
C:/embedded/zephyrproject/zephyr/samples/hello_world -- -G"Eclipse
CDT4 - Ninja" -D_ECLIPSE_VERSION=4.12

I can't reproduce this on my Arch Linux machine with
ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb, toolchain version
gcc-arm-none-eabi-7-2018-q2-update.

The build finishes successfully for me, and works when I flash it to my
board.

What toolchain are you using? Can you try with gnuarmemb?

https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded

One warning:
<...>
[18/98] Building CXX object CMakeFiles/app.dir/src/main.cpp.obj
cc1plus.exe: warning: command line option '-Wno-pointer-sign' is valid for C/ObjC but not for C++

Import project into Eclipse
Error in main.cpp:
Function 'printk' could not be resolved

Also tried:
set (CMAKE_CXX_STANDARD 11) in CMakeLists.txt
Manually add "__cplusplus=201402L" as a symbol in Eclipse (cmake does not generate such symbol in .cproject)
Force boilerplate.cmake to call eclipse_cdt4_generator_amendment with
work mode = 2 (.cproject with __cplusplus)

BTW, since you mentioned Segger and you're using nRF:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/gs_programming.html#building-with-ses

Best,
Marti

Thanks!

Thanks Johjan

Yes I had just figured that out, the change to my source code is trivial, and not an issue, but I do find it strange that APIs are changing between rc1 and rc2. I would have thought that a change in API required a rev in the second digit of the release number.

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

Lawrence King <lawrence.king@irdeto.com> writes:

It all becomes clear now...

I checked out various revisions of zephyr (rc1, rc2, etc) and ran west update at each step. You are correct it compiles correctly if I run 'west update' AFTER checking out a particular kernel (I had done 'west update' BEFORE checking out the latest kernel).

Thanks for your help.

Sure thing! I am glad that fixed your issue.

Marti

P.S, of course in the process of upgrading the kernel step-by-step my app is broken somewhere between rc1 and rc2, but that is a separate problem for a separate thread if I can't figure it out. " error: macro "BT_GATT_CCC" passed 2 arguments, but takes just 1 "

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

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@nordicsemi.no>
Sent: Wednesday, September 4, 2019 2:22 PM
To: Lawrence King <lawrence.king@irdeto.com>; Nashif, Anas <anas.nashif@intel.com>; Zephyr-users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] nrf.h missing....

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@lists.zephyrproject.org> writes:

Yes, in fact it was the process of running ‘west update’ that broke my
build in the first place.

Can you provide details on this?

As explained in the documentation PR, if you change your zephyr repository without running west update, the other repositories (in this case, the nRF HAL) may be either missing or out of sync with the main zephyr repository. This will lead to bad results.

You can think of "west update" as being like "git submodule update".

Thanks,
Marti

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

From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Nashif, Anas
Sent: Wednesday, September 4, 2019 2:10 PM
To: Lawrence King <lawrence.king@irdeto.com>;
Zephyr-users@lists.zephyrproject.org
Cc: carles.cufi@nordicsemi.no
Subject: Re: [Zephyr-users] nrf.h missing....

Did you run `west update` ?

From:
<users@lists.zephyrproject.org<mailto:users@lists.zephyrproject.org>>
on behalf of Lawrence King
<lawrence.king@irdeto.com<mailto:lawrence.king@irdeto.com>>
Date: Wednesday, 4 September 2019 at 14:05
To:
"Zephyr-users@lists.zephyrproject.org<mailto:Zephyr-users@lists.zephyr
project.org>"
<Zephyr-users@lists.zephyrproject.org<mailto:Zephyr-users@lists.zephyr
project.org>>
Cc: "carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>"
<carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>>
Subject: [Zephyr-users] nrf.h missing....

Today I upgraded to the head of the zephyr tree and my compile broke.
Backing up to the labels
v2.0.0-rc3
v2.0.0-rc2
v2.0.0-rc1
I found that my compile became broken somewhere between rc1 and rc2. A quick ‘git bisect’ found that the change that breaks my compile is:

cf3af6af5fa3e656d6caf0b3429fde52e895fa79 is the first bad commit
commit cf3af6af5fa3e656d6caf0b3429fde52e895fa79
Author: Carles Cufi <carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>>
Date: Thu Aug 15 17:17:01 2019 +0200

ext: hal: Make Nordic HALs a Zephyr module

Moved to an external repo,
https://github.com/zephyrproject-rtos/hal_nordic.

Signed-off-by: Carles Cufi
<carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>>

:100644 100644 73ad5c4f4fd10c2c1e3fbc0cc718b9f44cc198e7 696b06ec0d05db577603e10331186412f60ecbe3 M CODEOWNERS
:040000 040000 26b7c0c40f816f24989e7a7507cc21e298413f8e 8e387167b591b949828dc0ca08e0aff80ad5919f M ext
:040000 040000 772099e01dd7e4f586c782eb079b11ffbec86d39 2b5a71ac9918e09e3c801b2e90746da19f8b9437 M modules
:100644 100644 08f26e785ead096c10fcec7905c0e1061b8ba3f6 fe98cafd8cf915bf73f82e25abfb5a4c2b83fcbd M west.yml

For now my workaround is to stay at rc1.

I am using today’s release of west (0.6.2), I haven’t tried reverting west yet, but I did try manually running cmake and ninja and I get the same error, so I suspect this is not a west problem.

Here is the build error message I get (can’t find <nrf.h>):

lawrence@VM:~/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky$
west build -b nrf52840_mdk
-- west build: build configuration:
source directory: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky
build directory: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build (created)
BOARD: nrf52840_mdk (origin: command line)
-- west build: generating a build system Zephyr version: 2.0.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version
"3.6.8", minimum required is "3.4")
-- Selected BOARD nrf52840_mdk
-- Found west: /home/lawrence/.local/bin/west (found suitable version
"0.6.2", minimum required is "0.6.0")
-- Loading
/home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/nrf52840_mdk
/nrf52840_mdk.dts as base
-- Overlaying
/home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts
Device tree configuration written to
/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/bu
ild/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in
/home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig
Loaded configuration '/home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk_defconfig'
Merged configuration '/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/prj.conf'
Configuration saved to '/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/.config'

warning: UART_CONSOLE (defined at drivers/console/Kconfig:46) was
assigned the value 'y' but got the value 'n'. You can check symbol
information (including dependencies) in the 'menuconfig' interface
(see the Application Development Primer section of the manual), or in
the Kconfig reference at
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_CONSOLE.html (which is updated regularly from the master branch). See the 'Setting configuration values' section of the Board Porting Guide as well.

warning: the choice symbol UART_0_NRF_UART (defined at
drivers/serial/Kconfig.nrfx:28) was selected (set =y), but no symbol
ended up as the choice selection. You can check symbol information
(including dependencies) in the 'menuconfig' interface (see the
Application Development Primer section of the manual), or in the
Kconfig reference at
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_0_NRF_UART.html (which is updated regularly from the master branch). See the 'Setting configuration values' section of the Board Porting Guide as well.
-- Cache files will be written to: /home/lawrence/.cache/zephyr
-- The C compiler identification is GNU 6.3.1
-- The CXX compiler identification is GNU 6.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success Including module:
civetweb in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/lib/civetweb
Including module: esp-idf in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/esp-idf/zephyr
Including module: fatfs in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/fs/fatfs
Including module: qmsi in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/qmsi
Including module: cypress in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/cypress
Including module: silabs in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/silabs
Including module: st in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/st
Including module: stm32 in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/stm32
Including module: libmetal in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/hal/libmetal
Including module: lvgl in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/lib/gui/lvgl
Including module: mbedtls in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/crypto/mbedtls
Including module: mcumgr in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/lib/mcumgr
Including module: nffs in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/fs/nffs
Including module: open-amp in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/lib/open-amp
Including module: openthread in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/lib/openthread
Including module: segger in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/debug/segger
Including module: tinycbor in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/lib/tinycbor
Including module: littlefs in path:
/home/lawrence/workspace/rc-demo/zephyr/modules/fs/littlefs
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/bu
ild
-- west build: building application
[2/109] Preparing syscall dependency handling

[8/109] Building C object
zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
FAILED: zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
ccache /usr/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.0.0-rc1-156-gcf3af6af5fa3 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../../../../kernel/include -I../../../../arch/arm/include -I../../../../include -I../../../../include/drivers -Izephyr/include/generated -I../../../../soc/arm/nordic_nrf/nrf52 -I../../../../soc/arm/nordic_nrf/include -I../../../../ext/hal/cmsis/Include -isystem ../../../../lib/libc/minimal/include -isystem /usr/lib/gcc/arm-none-eabi/6.3.1/include -isystem /usr/lib/gcc/arm-none-eabi/6.3.1/include-fixed -Os -imacros/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m4 -imacros/home/lawrence/workspace/rc-demo/zephyr/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 -ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -c /home/lawrence/workspace/rc-demo/zephyr/zephyr/arch/arm/core/offsets/offsets.c
In file included from ../../../../include/arch/arm/cortex_m/cmsis.h:17:0,
from ../../../../include/arch/arm/cortex_m/mpu/arm_mpu_v7m.h:10,
from ../../../../include/arch/arm/cortex_m/mpu/arm_mpu.h:13,
from ../../../../include/arch/arm/arch.h:246,
from ../../../../include/arch/cpu.h:17,
from ../../../../include/kernel_includes.h:34,
from ../../../../include/kernel.h:17,
from ../../../../kernel/include/kernel_structs.h:10,
from /home/lawrence/workspace/rc-demo/zephyr/zephyr/arch/arm/core/offsets/offsets.c:26:
../../../../soc/arm/nordic_nrf/nrf52/soc.h:17:17: fatal error: nrf.h:
No such file or directory #include <nrf.h>
^
compilation terminated.
ninja: build stopped: subcommand failed.
ERROR: command exited with status 1: /home/lawrence/.local/bin/cmake
--build
/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/bu
ild

The problem exists compiling simple things like blinky. To reproduce the issue run the following commands:
$ cd zephyr/samples/basic/blinky $ west build -b
nrf52840_mdk

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

[1]<https://careers.irdeto.com/> [2 - linkedin] <https://www.linkedin.com/company/irdeto/> [3 - instagram] <https://www.instagram.com/lifeatirdeto/?hl=en> [4 - youtube] <https://www.youtube.com/channel/UCwgT0-wMbEqx3qLfrPIEnRg> [6 - facebook] <https://www.facebook.com/JoinIrdeto/> [7] <https://twitter.com/Irdeto?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

Hi,

On 4 Sep 2019, at 21.30, Lawrence King <lawrence.king@irdeto.com> wrote:

P.S, of course in the process of upgrading the kernel step-by-step my app is broken somewhere between rc1 and rc2, but that is a separate problem for a separate thread if I can't figure it out. " error: macro "BT_GATT_CCC" passed 2 arguments, but takes just 1 “

See this commit:

https://github.com/zephyrproject-rtos/zephyr/pull/18270/commits/730778b4864abdd6a79cc38c071d03ae0aa6e015

Basically the fix is just to drop your custom bt_gatt_ccc_cfg array and not pass it as a parameter to BT_GATT_CCC().

Johan

it seems extremely serious, considering that west basically has one job (versioning).

One of those jobs that everyone needs but no one wants to do?



PS: versioning plus a bit more https://docs.zephyrproject.org/latest/guides/west/why.html

It all becomes clear now...

I checked out various revisions of zephyr (rc1, rc2, etc) and ran west update at each step. You are correct it compiles correctly if I run 'west update' AFTER checking out a particular kernel (I had done 'west update' BEFORE checking out the latest kernel).

Thanks for your help.

P.S, of course in the process of upgrading the kernel step-by-step my app is broken somewhere between rc1 and rc2, but that is a separate problem for a separate thread if I can't figure it out. " error: macro "BT_GATT_CCC" passed 2 arguments, but takes just 1 "

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

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@lists.zephyrproject.org> writes:

Yes, in fact it was the process of running ‘west update’ that broke my
build in the first place.

Can you provide details on this?

As explained in the documentation PR, if you change your zephyr
repository without running west update, the other repositories (in this
case, the nRF HAL) may be either missing or out of sync with the main
zephyr repository. This will lead to bad results.

You can think of "west update" as being like "git submodule update".

Thanks,
Marti

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

From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Nashif, Anas
Sent: Wednesday, September 4, 2019 2:10 PM
To: Lawrence King <lawrence.king@irdeto.com>; Zephyr-users@lists.zephyrproject.org
Cc: carles.cufi@nordicsemi.no
Subject: Re: [Zephyr-users] nrf.h missing....

Did you run `west update` ?

From: <users@lists.zephyrproject.org<mailto:users@lists.zephyrproject.org>> on behalf of Lawrence King <lawrence.king@irdeto.com<mailto:lawrence.king@irdeto.com>>
Date: Wednesday, 4 September 2019 at 14:05
To: "Zephyr-users@lists.zephyrproject.org<mailto:Zephyr-users@lists.zephyrproject.org>" <Zephyr-users@lists.zephyrproject.org<mailto:Zephyr-users@lists.zephyrproject.org>>
Cc: "carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>" <carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>>
Subject: [Zephyr-users] nrf.h missing....

Today I upgraded to the head of the zephyr tree and my compile broke. Backing up to the labels
v2.0.0-rc3
v2.0.0-rc2
v2.0.0-rc1
I found that my compile became broken somewhere between rc1 and rc2. A quick ‘git bisect’ found that the change that breaks my compile is:

cf3af6af5fa3e656d6caf0b3429fde52e895fa79 is the first bad commit
commit cf3af6af5fa3e656d6caf0b3429fde52e895fa79
Author: Carles Cufi <carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>>
Date: Thu Aug 15 17:17:01 2019 +0200

ext: hal: Make Nordic HALs a Zephyr module

Moved to an external repo,
https://github.com/zephyrproject-rtos/hal_nordic.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no<mailto:carles.cufi@nordicsemi.no>>

:100644 100644 73ad5c4f4fd10c2c1e3fbc0cc718b9f44cc198e7 696b06ec0d05db577603e10331186412f60ecbe3 M CODEOWNERS
:040000 040000 26b7c0c40f816f24989e7a7507cc21e298413f8e 8e387167b591b949828dc0ca08e0aff80ad5919f M ext
:040000 040000 772099e01dd7e4f586c782eb079b11ffbec86d39 2b5a71ac9918e09e3c801b2e90746da19f8b9437 M modules
:100644 100644 08f26e785ead096c10fcec7905c0e1061b8ba3f6 fe98cafd8cf915bf73f82e25abfb5a4c2b83fcbd M west.yml

For now my workaround is to stay at rc1.

I am using today’s release of west (0.6.2), I haven’t tried reverting west yet, but I did try manually running cmake and ninja and I get the same error, so I suspect this is not a west problem.

Here is the build error message I get (can’t find <nrf.h>):

lawrence@VM:~/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky$ west build -b nrf52840_mdk
-- west build: build configuration:
source directory: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky
build directory: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build (created)
BOARD: nrf52840_mdk (origin: command line)
-- west build: generating a build system
Zephyr version: 2.0.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.8", minimum required is "3.4")
-- Selected BOARD nrf52840_mdk
-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.6.2", minimum required is "0.6.0")
-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts as base
-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts
Device tree configuration written to /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig
Loaded configuration '/home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk_defconfig'
Merged configuration '/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/prj.conf'
Configuration saved to '/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/.config'

warning: UART_CONSOLE (defined at drivers/console/Kconfig:46) was assigned the value 'y' but got the
value 'n'. You can check symbol information (including dependencies) in the 'menuconfig' interface
(see the Application Development Primer section of the manual), or in the Kconfig reference at
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_CONSOLE.html (which is updated
regularly from the master branch). See the 'Setting configuration values' section of the Board
Porting Guide as well.

warning: the choice symbol UART_0_NRF_UART (defined at drivers/serial/Kconfig.nrfx:28) was selected
(set =y), but no symbol ended up as the choice selection. You can check symbol information
(including dependencies) in the 'menuconfig' interface (see the Application Development Primer
section of the manual), or in the Kconfig reference at
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_0_NRF_UART.html (which is updated
regularly from the master branch). See the 'Setting configuration values' section of the Board
Porting Guide as well.
-- Cache files will be written to: /home/lawrence/.cache/zephyr
-- The C compiler identification is GNU 6.3.1
-- The CXX compiler identification is GNU 6.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
Including module: civetweb in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/civetweb
Including module: esp-idf in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/esp-idf/zephyr
Including module: fatfs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/fs/fatfs
Including module: qmsi in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/qmsi
Including module: cypress in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/cypress
Including module: silabs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/silabs
Including module: st in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/st
Including module: stm32 in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/stm32
Including module: libmetal in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/libmetal
Including module: lvgl in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/gui/lvgl
Including module: mbedtls in path: /home/lawrence/workspace/rc-demo/zephyr/modules/crypto/mbedtls
Including module: mcumgr in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/mcumgr
Including module: nffs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/fs/nffs
Including module: open-amp in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/open-amp
Including module: openthread in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/openthread
Including module: segger in path: /home/lawrence/workspace/rc-demo/zephyr/modules/debug/segger
Including module: tinycbor in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/tinycbor
Including module: littlefs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/fs/littlefs
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build
-- west build: building application
[2/109] Preparing syscall dependency handling

[8/109] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
FAILED: zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
ccache /usr/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.0.0-rc1-156-gcf3af6af5fa3 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../../../../kernel/include -I../../../../arch/arm/include -I../../../../include -I../../../../include/drivers -Izephyr/include/generated -I../../../../soc/arm/nordic_nrf/nrf52 -I../../../../soc/arm/nordic_nrf/include -I../../../../ext/hal/cmsis/Include -isystem ../../../../lib/libc/minimal/include -isystem /usr/lib/gcc/arm-none-eabi/6.3.1/include -isystem /usr/lib/gcc/arm-none-eabi/6.3.1/include-fixed -Os -imacros/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m4 -imacros/home/lawrence/workspace/rc-demo/zephyr/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 -ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -c /home/lawrence/workspace/rc-demo/zephyr/zephyr/arch/arm/core/offsets/offsets.c
In file included from ../../../../include/arch/arm/cortex_m/cmsis.h:17:0,
from ../../../../include/arch/arm/cortex_m/mpu/arm_mpu_v7m.h:10,
from ../../../../include/arch/arm/cortex_m/mpu/arm_mpu.h:13,
from ../../../../include/arch/arm/arch.h:246,
from ../../../../include/arch/cpu.h:17,
from ../../../../include/kernel_includes.h:34,
from ../../../../include/kernel.h:17,
from ../../../../kernel/include/kernel_structs.h:10,
from /home/lawrence/workspace/rc-demo/zephyr/zephyr/arch/arm/core/offsets/offsets.c:26:
../../../../soc/arm/nordic_nrf/nrf52/soc.h:17:17: fatal error: nrf.h: No such file or directory
#include <nrf.h>
^
compilation terminated.
ninja: build stopped: subcommand failed.
ERROR: command exited with status 1: /home/lawrence/.local/bin/cmake --build /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build

The problem exists compiling simple things like blinky. To reproduce the issue run the following commands:
$ cd zephyr/samples/basic/blinky
$ west build -b nrf52840_mdk

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

[1]<https://careers.irdeto.com/> [2 - linkedin] <https://www.linkedin.com/company/irdeto/> [3 - instagram] <https://www.instagram.com/lifeatirdeto/?hl=en> [4 - youtube] <https://www.youtube.com/channel/UCwgT0-wMbEqx3qLfrPIEnRg> [6 - facebook] <https://www.facebook.com/JoinIrdeto/> [7] <https://twitter.com/Irdeto?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

"Nashif, Anas via Lists.Zephyrproject.Org"
<anas.nashif=intel.com@lists.zephyrproject.org> writes:

Did you run `west update` ?

Probably should add this to the getting started guide:

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

From: <users@lists.zephyrproject.org> on behalf of Lawrence King <lawrence.king@irdeto.com>
Date: Wednesday, 4 September 2019 at 14:05
To: "Zephyr-users@lists.zephyrproject.org" <Zephyr-users@lists.zephyrproject.org>
Cc: "carles.cufi@nordicsemi.no" <carles.cufi@nordicsemi.no>
Subject: [Zephyr-users] nrf.h missing....

Today I upgraded to the head of the zephyr tree and my compile broke. Backing up to the labels
v2.0.0-rc3
v2.0.0-rc2
v2.0.0-rc1
I found that my compile became broken somewhere between rc1 and rc2. A quick ‘git bisect’ found that the change that breaks my compile is:

cf3af6af5fa3e656d6caf0b3429fde52e895fa79 is the first bad commit
commit cf3af6af5fa3e656d6caf0b3429fde52e895fa79
Author: Carles Cufi <carles.cufi@nordicsemi.no>
Date: Thu Aug 15 17:17:01 2019 +0200

ext: hal: Make Nordic HALs a Zephyr module

Moved to an external repo,
https://github.com/zephyrproject-rtos/hal_nordic.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>

:100644 100644 73ad5c4f4fd10c2c1e3fbc0cc718b9f44cc198e7 696b06ec0d05db577603e10331186412f60ecbe3 M CODEOWNERS
:040000 040000 26b7c0c40f816f24989e7a7507cc21e298413f8e 8e387167b591b949828dc0ca08e0aff80ad5919f M ext
:040000 040000 772099e01dd7e4f586c782eb079b11ffbec86d39 2b5a71ac9918e09e3c801b2e90746da19f8b9437 M modules
:100644 100644 08f26e785ead096c10fcec7905c0e1061b8ba3f6 fe98cafd8cf915bf73f82e25abfb5a4c2b83fcbd M west.yml

For now my workaround is to stay at rc1.

I am using today’s release of west (0.6.2), I haven’t tried reverting west yet, but I did try manually running cmake and ninja and I get the same error, so I suspect this is not a west problem.

Here is the build error message I get (can’t find <nrf.h>):

lawrence@VM:~/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky$ west build -b nrf52840_mdk
-- west build: build configuration:
source directory: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky
build directory: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build (created)
BOARD: nrf52840_mdk (origin: command line)
-- west build: generating a build system
Zephyr version: 2.0.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.8", minimum required is "3.4")
-- Selected BOARD nrf52840_mdk
-- Found west: /home/lawrence/.local/bin/west (found suitable version "0.6.2", minimum required is "0.6.0")
-- Loading /home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts as base
-- Overlaying /home/lawrence/workspace/rc-demo/zephyr/zephyr/dts/common/common.dts
Device tree configuration written to /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in /home/lawrence/workspace/rc-demo/zephyr/zephyr/Kconfig
Loaded configuration '/home/lawrence/workspace/rc-demo/zephyr/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk_defconfig'
Merged configuration '/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/prj.conf'
Configuration saved to '/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/.config'

warning: UART_CONSOLE (defined at drivers/console/Kconfig:46) was assigned the value 'y' but got the
value 'n'. You can check symbol information (including dependencies) in the 'menuconfig' interface
(see the Application Development Primer section of the manual), or in the Kconfig reference at
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_CONSOLE.html (which is updated
regularly from the master branch). See the 'Setting configuration values' section of the Board
Porting Guide as well.

warning: the choice symbol UART_0_NRF_UART (defined at drivers/serial/Kconfig.nrfx:28) was selected
(set =y), but no symbol ended up as the choice selection. You can check symbol information
(including dependencies) in the 'menuconfig' interface (see the Application Development Primer
section of the manual), or in the Kconfig reference at
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_0_NRF_UART.html (which is updated
regularly from the master branch). See the 'Setting configuration values' section of the Board
Porting Guide as well.
-- Cache files will be written to: /home/lawrence/.cache/zephyr
-- The C compiler identification is GNU 6.3.1
-- The CXX compiler identification is GNU 6.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
Including module: civetweb in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/civetweb
Including module: esp-idf in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/esp-idf/zephyr
Including module: fatfs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/fs/fatfs
Including module: qmsi in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/qmsi
Including module: cypress in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/cypress
Including module: silabs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/silabs
Including module: st in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/st
Including module: stm32 in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/stm32
Including module: libmetal in path: /home/lawrence/workspace/rc-demo/zephyr/modules/hal/libmetal
Including module: lvgl in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/gui/lvgl
Including module: mbedtls in path: /home/lawrence/workspace/rc-demo/zephyr/modules/crypto/mbedtls
Including module: mcumgr in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/mcumgr
Including module: nffs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/fs/nffs
Including module: open-amp in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/open-amp
Including module: openthread in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/openthread
Including module: segger in path: /home/lawrence/workspace/rc-demo/zephyr/modules/debug/segger
Including module: tinycbor in path: /home/lawrence/workspace/rc-demo/zephyr/modules/lib/tinycbor
Including module: littlefs in path: /home/lawrence/workspace/rc-demo/zephyr/modules/fs/littlefs
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build
-- west build: building application
[2/109] Preparing syscall dependency handling

[8/109] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
FAILED: zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
ccache /usr/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.0.0-rc1-156-gcf3af6af5fa3 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../../../../kernel/include -I../../../../arch/arm/include -I../../../../include -I../../../../include/drivers -Izephyr/include/generated -I../../../../soc/arm/nordic_nrf/nrf52 -I../../../../soc/arm/nordic_nrf/include -I../../../../ext/hal/cmsis/Include -isystem ../../../../lib/libc/minimal/include -isystem /usr/lib/gcc/arm-none-eabi/6.3.1/include -isystem /usr/lib/gcc/arm-none-eabi/6.3.1/include-fixed -Os -imacros/home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m4 -imacros/home/lawrence/workspace/rc-demo/zephyr/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 -ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -c /home/lawrence/workspace/rc-demo/zephyr/zephyr/arch/arm/core/offsets/offsets.c
In file included from ../../../../include/arch/arm/cortex_m/cmsis.h:17:0,
from ../../../../include/arch/arm/cortex_m/mpu/arm_mpu_v7m.h:10,
from ../../../../include/arch/arm/cortex_m/mpu/arm_mpu.h:13,
from ../../../../include/arch/arm/arch.h:246,
from ../../../../include/arch/cpu.h:17,
from ../../../../include/kernel_includes.h:34,
from ../../../../include/kernel.h:17,
from ../../../../kernel/include/kernel_structs.h:10,
from /home/lawrence/workspace/rc-demo/zephyr/zephyr/arch/arm/core/offsets/offsets.c:26:
../../../../soc/arm/nordic_nrf/nrf52/soc.h:17:17: fatal error: nrf.h: No such file or directory
#include <nrf.h>
^
compilation terminated.
ninja: build stopped: subcommand failed.
ERROR: command exited with status 1: /home/lawrence/.local/bin/cmake --build /home/lawrence/workspace/rc-demo/zephyr/zephyr/samples/basic/blinky/build

The problem exists compiling simple things like blinky. To reproduce the issue run the following commands:
$ cd zephyr/samples/basic/blinky
$ west build -b nrf52840_mdk

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

[1]<https://careers.irdeto.com/> [2 - linkedin] <https://www.linkedin.com/company/irdeto/> [3 - instagram] <https://www.instagram.com/lifeatirdeto/?hl=en> [4 - youtube] <https://www.youtube.com/channel/UCwgT0-wMbEqx3qLfrPIEnRg> [6 - facebook] <https://www.facebook.com/JoinIrdeto/> [7] <https://twitter.com/Irdeto?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.