Date   

Re: MCUBoot as a west module

Becker Markus
 

Hi Marti.

Hi,

I am trying to get Zephyr up and running with MCUboot as bootloader.

Is the documentation at https://juullabs-oss.github.io/mcuboot/readme-zephyr.html up-to-date?
Or is there a possibility to build mcuboot as a west module in one go
with the application and get a merged hex file?
A single merged hex isn't possible upstream, but mcuboot is being added as a west module here:
[MB] Alright, I had seen it in https://github.com/NordicPlayground/fw-nrfconnect-nrf. But since I could not get the partition manager to use the external flash device, I have been switching back to upstream Zephyr.

https://github.com/zephyrproject-rtos/zephyr/pull/17868
[MB] OK, so this PR ties in the west module. After this, you build mcuboot in applications/mcuboot/boot/zephyr/build according to https://juullabs-oss.github.io/mcuboot/readme-zephyr.html and build the application with the prj.conf?

CONFIG_MCUBOOT_CMAKELISTS_DIR="$ ZEPHYR_BASE/applications/mcuboot/boot/zephyr/"
CONFIG_MCUBOOT_BUILD_STRATEGY_FROM_SOURCE=y
CONFIG_MCUBOOT_IMAGE_VERSION="0.0.1+0"
CONFIG_BOOT_SIGNATURE_KEY_FILE="root-rsa-2048.pem"
# CONFIG_MCUMGR is not set
# CONFIG_IS_BOOTLOADER is not set
CONFIG_BOOTLOADER_MCUBOOT=y

You can build and flash the bootloader once, then flash your application separately.


I am also interested in getting mcuboot/Zephyr working using an
external flash chip for the secondary slot:
http://lists.runtime.co/pipermail/dev-mcuboot_lists.runtime.co/2019-Se
ptember/000634.html. Any hints?
I've often wondered whether this is true myself. I've heard conflicting reports.
After adding

diff --git a/boot/zephyr/prj.conf b/boot/zephyr/prj.conf
index dd67333..f55739d 100644
--- a/boot/zephyr/prj.conf
+++ b/boot/zephyr/prj.conf
@@ -47,3 +47,12 @@ CONFIG_LOG=y
CONFIG_LOG_IMMEDIATE=y
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=0
+
+### Enable external flash support
+CONFIG_SPI=y
+CONFIG_SPI_NOR=y
+CONFIG_SPI_NOR_SECTOR_SIZE=4096
+CONFIG_SPI_NOR_PAGE_SIZE=256
+CONFIG_SPI_NOR_CS_WAIT_DELAY=50

And

diff --git a/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts b/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts
index d90b1dd684..aa50abb5f5 100644
--- a/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts
+++ b/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts
@@ -186,6 +188,23 @@ arduino_i2c: &i2c0 {
has-be32k;
wp-gpios = <&gpio0 22 0>;
hold-gpios = <&gpio0 23 0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ // use same layout on external flash as in internal flash
+ // optimize external flash layout later
+ slot1_partition: partition@73000 {
+ label = "image-1";
+ reg = <0x00073000 0x000067000>;
+ };
+ scratch_partition: partition@da000 {
+ label = "image-scratch";
+ reg = <0x000da000 0x0001e000>;
+ };
+ };
};
};

@@ -214,6 +233,7 @@ arduino_spi: &spi3 {
label = "image-0";
reg = <0x0000C000 0x000067000>;
};
+ /*
slot1_partition: partition@73000 {
label = "image-1";
reg = <0x00073000 0x000067000>;
@@ -222,7 +242,7 @@ arduino_spi: &spi3 {
label = "image-scratch";
reg = <0x000da000 0x0001e000>;
};
-
+ */

I am currently getting

FATAL: ***** USAGE FAULT *****
FATAL: Illegal load of EXC_RETURN into PC
FATAL: r0/a1: 0xf3efb501 r1/a2: 0xf1a08005 r2/a3: 0xea4f0010
FATAL: r3/a4: 0x490400c0 r12/ip: 0xc9094401 r14/lr: 0xe8bd4798
FATAL: xpsr: 0x00004708
FATAL: Faulting instruction address (r15/pc): 0x49024001

on spi_context_release() in zephyr/drivers/spi/spi_nrfx_spi.c. Seems like _current Thread is NULL at DEVICE_AND_API_INIT in POST_KERNEL stage.

Best,
Marti
________________________________
The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.


Re: MCUBoot as a west module

Bolivar, Marti
 

"Becker Markus via Lists.Zephyrproject.Org"
<markus.becker=tridonic.com@lists.zephyrproject.org> writes:

Hi,

I am trying to get Zephyr up and running with MCUboot as bootloader.

Is the documentation at https://juullabs-oss.github.io/mcuboot/readme-zephyr.html up-to-date?
Or is there a possibility to build mcuboot as a west module in one go
with the application and get a merged hex file?
A single merged hex isn't possible upstream, but mcuboot is being added
as a west module here:

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

You can build and flash the bootloader once, then flash your
application separately.


I am also interested in getting mcuboot/Zephyr working using an
external flash chip for the secondary slot:
http://lists.runtime.co/pipermail/dev-mcuboot_lists.runtime.co/2019-September/000634.html. Any
hints?
I've often wondered whether this is true myself. I've heard conflicting
reports.

Best,
Marti


Thanks,
Markus
________________________________
The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.


MCUBoot as a west module

Becker Markus
 

Hi,

 

I am trying to get Zephyr up and running with MCUboot as bootloader.

 

Is the documentation at https://juullabs-oss.github.io/mcuboot/readme-zephyr.html up-to-date?

Or is there a possibility to build mcuboot as a west module in one go with the application and get a merged hex file?

 

I am also interested in getting mcuboot/Zephyr working using an external flash chip for the secondary slot: http://lists.runtime.co/pipermail/dev-mcuboot_lists.runtime.co/2019-September/000634.html. Any hints?

 

Thanks,

Markus


The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.


Re: marat

Marc Herbert
 

Try removing D: from-DBOARD_ROOT=D:\CoIDE\UPS_SecurityBoard\boards

 

You can also try a relative path.

 

Marc

 

From: <users@...> on behalf of Erwan Gouriou <erwan.gouriou@...>
Date: Friday, 13 September 2019 at 08:06
To: "murad.durdyev.1989@..." <murad.durdyev.1989@...>
Cc: users <users@...>
Subject: Re: [Zephyr-users] marat

 

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'


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@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


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

Nick 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@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


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@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


#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@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

781 - 800 of 2475