Date   

Re: marat

Erwan Gouriou
 

Hi Murad,

Seems Cmake somehow convert you build path to a reserved Cmake string that trigger the issue.
I'm not familiar with build on windows, but I'd suggest to work around your build path.

Erwan


On Fri, 13 Sep 2019 at 15:47, murad.durdyev.1989 via Lists.Zephyrproject.Org <murad.durdyev.1989=mail.ru@...> wrote:
Hi! I make new board (stm32l433) and i cant start building with "west". It's messages in my Windows terminal. What i do wrong?

D:\CoIDE\UPS_SecurityBoard\sample_a_board>west build -b peus_l433rc -- -DBOARD_ROOT=D:\CoIDE\UPS_SecurityBoard\boards
-- west build: build configuration:
       source directory: D:\CoIDE\UPS_SecurityBoard\sample_a_board
       build directory: D:\CoIDE\UPS_SecurityBoard\sample_a_board\build
       BOARD: peus_l433rc (origin: command line)
-- west build: generating a build system
Zephyr version: 2.0.0
-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7.4", minimum required is "3.4")
-- Selected BOARD peus_l433rc
-- Found west: C:/Python37/Scripts/west.exe (found suitable version "0.6.2", minimum required is "0.6.0")
-- Loading D:/CoIDE/UPS_SecurityBoard/sample_a_board/boards/arm/peus_l433rc/peus_l433rc.dts as base
-- Overlaying C:/zephyrproject/zephyr/dts/common/common.dts
Device tree configuration written to D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in C:/zephyrproject/zephyr/Kconfig
Loaded configuration 'D:/CoIDE/UPS_SecurityBoard/sample_a_board/boards/arm/peus_l433rc/peus_l433rc_defconfig'
Merged configuration 'D:/CoIDE/UPS_SecurityBoard/sample_a_board/prj.conf'
Configuration saved to 'D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/zephyr/.config'
-- Cache files will be written to: C:\Users\Lenovo\AppData\Local/.cache/zephyr
-- The C compiler identification is GNU 8.3.1
-- The CXX compiler identification is GNU 8.3.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/gnu_arm_embedded/bin/arm-none-eabi-gcc.exe
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at C:/zephyrproject/zephyr/cmake/extensions.cmake:371 (add_library):
  The target name
  "D:__CoIDE__UPS_SecurityBoard__sample_a_board__boards__arm__peus_l433rc" is
  reserved or not valid for certain CMake features, such as generator
  expressions, and may result in undefined behavior.
Call Stack (most recent call first):
  C:/zephyrproject/zephyr/cmake/extensions.cmake:348 (zephyr_library_named)
  boards/arm/peus_l433rc/CMakeLists.txt:4 (zephyr_library)
 
 
CMake Error at C:/zephyrproject/zephyr/cmake/extensions.cmake:387 (target_sources):
  Cannot specify sources for target
  "D:__CoIDE__UPS_SecurityBoard__sample_a_board__boards__arm__peus_l433rc"
  which is not built by this project.
Call Stack (most recent call first):
  boards/arm/peus_l433rc/CMakeLists.txt:5 (zephyr_library_sources)
 
 
CMake Error at C:/zephyrproject/zephyr/cmake/extensions.cmake:391 (target_include_directories):
  Cannot specify include directories for target
  "D:__CoIDE__UPS_SecurityBoard__sample_a_board__boards__arm__peus_l433rc"
  which is not built by this project.
Call Stack (most recent call first):
  boards/arm/peus_l433rc/CMakeLists.txt:6 (zephyr_library_include_directories)
 
 
Including module: atmel in path: C:\zephyrproject\modules\hal\atmel
Including module: civetweb in path: C:\zephyrproject\modules\lib\civetweb
Including module: esp-idf in path: C:\zephyrproject\modules\hal\esp-idf\zephyr
Including module: fatfs in path: C:\zephyrproject\modules\fs\fatfs
Including module: qmsi in path: C:\zephyrproject\modules\hal\qmsi
Including module: cypress in path: C:\zephyrproject\modules\hal\cypress
Including module: nordic in path: C:\zephyrproject\modules\hal\nordic
Including module: openisa in path: C:\zephyrproject\modules\hal\openisa
Including module: microchip in path: C:\zephyrproject\modules\hal\microchip
Including module: silabs in path: C:\zephyrproject\modules\hal\silabs
Including module: st in path: C:\zephyrproject\modules\hal\st
Including module: stm32 in path: C:\zephyrproject\modules\hal\stm32
Including module: ti in path: C:\zephyrproject\modules\hal\ti
Including module: libmetal in path: C:\zephyrproject\modules\hal\libmetal
Including module: lvgl in path: C:\zephyrproject\modules\lib\gui\lvgl
Including module: mbedtls in path: C:\zephyrproject\modules\crypto\mbedtls
Including module: mcumgr in path: C:\zephyrproject\modules\lib\mcumgr
Including module: nffs in path: C:\zephyrproject\modules\fs\nffs
Including module: nxp in path: C:\zephyrproject\modules\hal\nxp
Including module: open-amp in path: C:\zephyrproject\modules\lib\open-amp
Including module: openthread in path: C:\zephyrproject\modules\lib\openthread
Including module: segger in path: C:\zephyrproject\modules\debug\segger
Including module: tinycbor in path: C:\zephyrproject\modules\lib\tinycbor
Including module: littlefs in path: C:\zephyrproject\modules\fs\littlefs
-- Configuring incomplete, errors occurred!
See also "D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/CMakeFiles/CMakeOutput.log".
See also "D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/CMakeFiles/CMakeError.log".
ERROR: command exited with status 1: 'D:\ProgramFiles\CMake\Programm\bin\cmake.EXE' '-BD:\CoIDE\UPS_SecurityBoard\sample_a_board\build' '-SD:\CoIDE\UPS_SecurityBoard\sample_a_board' -GNinja -DBOARD=peus_l433rc '-DBOARD_ROOT=D:\CoIDE\UPS_SecurityBoard\boards'


marat

murad.durdyev.1989@...
 

Hi! I make new board (stm32l433) and i cant start building with "west". It's messages in my Windows terminal. What i do wrong?

D:\CoIDE\UPS_SecurityBoard\sample_a_board>west build -b peus_l433rc -- -DBOARD_ROOT=D:\CoIDE\UPS_SecurityBoard\boards
-- west build: build configuration:
       source directory: D:\CoIDE\UPS_SecurityBoard\sample_a_board
       build directory: D:\CoIDE\UPS_SecurityBoard\sample_a_board\build
       BOARD: peus_l433rc (origin: command line)
-- west build: generating a build system
Zephyr version: 2.0.0
-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7.4", minimum required is "3.4")
-- Selected BOARD peus_l433rc
-- Found west: C:/Python37/Scripts/west.exe (found suitable version "0.6.2", minimum required is "0.6.0")
-- Loading D:/CoIDE/UPS_SecurityBoard/sample_a_board/boards/arm/peus_l433rc/peus_l433rc.dts as base
-- Overlaying C:/zephyrproject/zephyr/dts/common/common.dts
Device tree configuration written to D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/zephyr/include/generated/generated_dts_board.conf
Parsing Kconfig tree in C:/zephyrproject/zephyr/Kconfig
Loaded configuration 'D:/CoIDE/UPS_SecurityBoard/sample_a_board/boards/arm/peus_l433rc/peus_l433rc_defconfig'
Merged configuration 'D:/CoIDE/UPS_SecurityBoard/sample_a_board/prj.conf'
Configuration saved to 'D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/zephyr/.config'
-- Cache files will be written to: C:\Users\Lenovo\AppData\Local/.cache/zephyr
-- The C compiler identification is GNU 8.3.1
-- The CXX compiler identification is GNU 8.3.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/gnu_arm_embedded/bin/arm-none-eabi-gcc.exe
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at C:/zephyrproject/zephyr/cmake/extensions.cmake:371 (add_library):
  The target name
  "D:__CoIDE__UPS_SecurityBoard__sample_a_board__boards__arm__peus_l433rc" is
  reserved or not valid for certain CMake features, such as generator
  expressions, and may result in undefined behavior.
Call Stack (most recent call first):
  C:/zephyrproject/zephyr/cmake/extensions.cmake:348 (zephyr_library_named)
  boards/arm/peus_l433rc/CMakeLists.txt:4 (zephyr_library)
 
 
CMake Error at C:/zephyrproject/zephyr/cmake/extensions.cmake:387 (target_sources):
  Cannot specify sources for target
  "D:__CoIDE__UPS_SecurityBoard__sample_a_board__boards__arm__peus_l433rc"
  which is not built by this project.
Call Stack (most recent call first):
  boards/arm/peus_l433rc/CMakeLists.txt:5 (zephyr_library_sources)
 
 
CMake Error at C:/zephyrproject/zephyr/cmake/extensions.cmake:391 (target_include_directories):
  Cannot specify include directories for target
  "D:__CoIDE__UPS_SecurityBoard__sample_a_board__boards__arm__peus_l433rc"
  which is not built by this project.
Call Stack (most recent call first):
  boards/arm/peus_l433rc/CMakeLists.txt:6 (zephyr_library_include_directories)
 
 
Including module: atmel in path: C:\zephyrproject\modules\hal\atmel
Including module: civetweb in path: C:\zephyrproject\modules\lib\civetweb
Including module: esp-idf in path: C:\zephyrproject\modules\hal\esp-idf\zephyr
Including module: fatfs in path: C:\zephyrproject\modules\fs\fatfs
Including module: qmsi in path: C:\zephyrproject\modules\hal\qmsi
Including module: cypress in path: C:\zephyrproject\modules\hal\cypress
Including module: nordic in path: C:\zephyrproject\modules\hal\nordic
Including module: openisa in path: C:\zephyrproject\modules\hal\openisa
Including module: microchip in path: C:\zephyrproject\modules\hal\microchip
Including module: silabs in path: C:\zephyrproject\modules\hal\silabs
Including module: st in path: C:\zephyrproject\modules\hal\st
Including module: stm32 in path: C:\zephyrproject\modules\hal\stm32
Including module: ti in path: C:\zephyrproject\modules\hal\ti
Including module: libmetal in path: C:\zephyrproject\modules\hal\libmetal
Including module: lvgl in path: C:\zephyrproject\modules\lib\gui\lvgl
Including module: mbedtls in path: C:\zephyrproject\modules\crypto\mbedtls
Including module: mcumgr in path: C:\zephyrproject\modules\lib\mcumgr
Including module: nffs in path: C:\zephyrproject\modules\fs\nffs
Including module: nxp in path: C:\zephyrproject\modules\hal\nxp
Including module: open-amp in path: C:\zephyrproject\modules\lib\open-amp
Including module: openthread in path: C:\zephyrproject\modules\lib\openthread
Including module: segger in path: C:\zephyrproject\modules\debug\segger
Including module: tinycbor in path: C:\zephyrproject\modules\lib\tinycbor
Including module: littlefs in path: C:\zephyrproject\modules\fs\littlefs
-- Configuring incomplete, errors occurred!
See also "D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/CMakeFiles/CMakeOutput.log".
See also "D:/CoIDE/UPS_SecurityBoard/sample_a_board/build/CMakeFiles/CMakeError.log".
ERROR: command exited with status 1: 'D:\ProgramFiles\CMake\Programm\bin\cmake.EXE' '-BD:\CoIDE\UPS_SecurityBoard\sample_a_board\build' '-SD:\CoIDE\UPS_SecurityBoard\sample_a_board' -GNinja -DBOARD=peus_l433rc '-DBOARD_ROOT=D:\CoIDE\UPS_SecurityBoard\boards'


Re: Documentation in PDF

Kinder, David B <david.b.kinder@...>
 

Following up, we found issues with some images that were preventing a PDF flavor of the documentation to be built, and these images have been fixed in the master branch.

-- david

 

 

 

From: users@... <users@...> On Behalf Of Marc Herbert
Sent: Wednesday, September 11, 2019 12:08 PM
To: Karol P <karprzy7@...>; Zephyr-users@...
Subject: Re: [Zephyr-users] Documentation in PDF

 

Hi Karol,

 

Have you tried this on Linux:

 

  cd zephyr

  make pdfdocs

 

Cheers,

 

Marc

 

 

From: <users@...> on behalf of Karol P <karprzy7@...>
Date: Wednesday, 11 September 2019 at 11:44
To: "Zephyr-users@..." <Zephyr-users@...>
Subject: [Zephyr-users] Documentation in PDF

 

Hi all,

I was wondering if there is available source for zephyr's documentation in PDF or any format that will look good printed without much hassle. 

 

I'd like to read e.g. this, make my own notes and whatnot but online it isn't very comfortable. 

 

Sorry if this was already on the list, I tried searching through archive but did not find anything related.

 

Cheers,

Karol 


Re: Documentation in PDF

Marc Herbert
 

Hi Karol,

 

Have you tried this on Linux:

 

  cd zephyr

  make pdfdocs

 

Cheers,

 

Marc

 

 

From: <users@...> on behalf of Karol P <karprzy7@...>
Date: Wednesday, 11 September 2019 at 11:44
To: "Zephyr-users@..." <Zephyr-users@...>
Subject: [Zephyr-users] Documentation in PDF

 

Hi all,

I was wondering if there is available source for zephyr's documentation in PDF or any format that will look good printed without much hassle. 

 

I'd like to read e.g. this, make my own notes and whatnot but online it isn't very comfortable. 

 

Sorry if this was already on the list, I tried searching through archive but did not find anything related.

 

Cheers,

Karol 


Documentation in PDF

Karol P
 

Hi all,
I was wondering if there is available source for zephyr's documentation in PDF or any format that will look good printed without much hassle. 

I'd like to read e.g. this, make my own notes and whatnot but online it isn't very comfortable. 

Sorry if this was already on the list, I tried searching through archive but did not find anything related.

Cheers,
Karol 


Error in services launch sequence #debugging #eclipse #gdb

Peter <nimac.peter@...>
 

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
However, I can run the gdb debugger or simply flash the code just fine by using following commands:

west debug
west debugserver
west flash

Below are the screenshots of my configuration. I am passing the --pack option since I'm using STM Nucleo-144 F446ZE, which is not installed with pyOCD by default and I cannot install it using other means. Anyway, according to the error message it seems to me the command is called correctly. 



Any help is greatly appreciated.

Best regards!
Peter


Re: west and (no) data loss, was: Re: [Zephyr-users] Do not use west v0.6.1; upgrade to v0.6.2

Paul Sokolovsky
 

Hello Marti,

On Fri, 6 Sep 2019 17:41:56 +0000
"Bolivar, Marti" <Marti.Bolivar@...> 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


API meeting: Agenda

Carles Cufi
 

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,


Bluetooth security #ble

nix.ward@...
 

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


Re: west and (no) data loss, was: Re: [Zephyr-users] Do not use west v0.6.1; upgrade to v0.6.2

Carles Cufi
 

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


Re: west and (no) data loss, was: Re: [Zephyr-users] Do not use west v0.6.1; upgrade to v0.6.2

Bolivar, Marti
 

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@...> writes:

Hello Marti,

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

Marti Bolivar <marti.bolivar@...> 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


west and (no) data loss, was: Re: [Zephyr-users] Do not use west v0.6.1; upgrade to v0.6.2

Paul Sokolovsky
 

Hello Marti,

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

Marti Bolivar <marti.bolivar@...> 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


#usb wifi adapter support #usb

thomasu1@...
 

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

--tnx
--tom


How to configure BLE scanning for optimal effective time scanning #ble #bluetooth

nick.ward@...
 

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:
CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=y
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=24
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=40
CONFIG_BT_PERIPHERAL_PREF_SLAVE_LATENCY=0

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


BLE advertising channel selection for nRF52840

Venkat Rao Vallapaneni <vallapaneni@...>
 

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.


Re: C++ support (Eclipse CDT4) - 'printk' could not be resolved #west

Bolivar, Marti
 

"leonardomt via Lists.Zephyrproject.Org"
<leonardomt=gmail.com@...> 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


Re: C++ support (Eclipse CDT4) - 'printk' could not be resolved #west

leonardomt@...
 

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







Re: C++ support (Eclipse CDT4) - 'printk' could not be resolved #west

Bolivar, Marti
 

"leonardomt via Lists.Zephyrproject.Org"
<leonardomt=gmail.com@...> 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!


Re: nrf.h missing....

Lawrence King
 

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

-----Original Message-----
From: Hedberg, Johan <@jhe>
Sent: Wednesday, September 4, 2019 3:02 PM
To: Lawrence King <lawrence.king@...>
Cc: Bolivar, Marti <Marti.Bolivar@...>; Nashif, Anas <anas.nashif@...>; Zephyr-users@...; users@...
Subject: Re: [Zephyr-users] nrf.h missing....

Hi,

On 4 Sep 2019, at 21.30, Lawrence King <lawrence.king@...> 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


Re: nrf.h missing....

Bolivar, Marti
 

Lawrence King <lawrence.king@...> 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@...>
Sent: Wednesday, September 4, 2019 2:22 PM
To: Lawrence King <lawrence.king@...>; Nashif, Anas <anas.nashif@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] nrf.h missing....

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@...> 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@... <users@...> On
Behalf Of Nashif, Anas
Sent: Wednesday, September 4, 2019 2:10 PM
To: Lawrence King <lawrence.king@...>;
Zephyr-users@...
Cc: carles.cufi@...
Subject: Re: [Zephyr-users] nrf.h missing....

Did you run `west update` ?

From:
<users@...<mailto:users@...>>
on behalf of Lawrence King
<lawrence.king@...<mailto:lawrence.king@...>>
Date: Wednesday, 4 September 2019 at 14:05
To:
"Zephyr-users@...<mailto:Zephyr-users@...
project.org>"
<Zephyr-users@...<mailto:Zephyr-users@...
project.org>>
Cc: "carles.cufi@...<mailto:carles.cufi@...>"
<carles.cufi@...<mailto:carles.cufi@...>>
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@...<mailto:carles.cufi@...>>
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@...<mailto:carles.cufi@...>>

: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.