Date   

Re: Long-Term Bluetooth Mesh Reliability

Johan Hedberg
 

Hi Martin,

On 17 Feb 2019, at 14.07, Martin <ma@jgs-wg.de> wrote:
I am wondering if someone has already made experiments regarding the
long-term reliability of Bluetooth Mesh in Zephyr OS?

The reason why I am asking is this: I am on the latest master and I
use a Mesh setup consisting of ~10 devices (PCA10040 + PCA10059) with
an adjusted samples/boards/nrf52/mesh which additionally sends
heartbeat messages and at the same time blinks an LED (realized by a
timer that submits a work item which lights it, waits and switches it
off again). What I have been observing is the following: Devices that
only send a hertbeat message every 10 seconds run quite stable for
some days, but need to be power-cycled at some point in time (no
heartbeat messages, no LED blinking). Devices with higher load (e.g.
relay enabled, deliberately sending a higher amount of mesh messages)
are not responding within hours (no messages whatsoever, no LED
blinking). Even when taking pressure out of the mesh (not deliberately
sending messages anymore), they do not come back to life before I
power-cycle them.

Does someone possibly have an explanation for the issues I am
encountering or some tips regarding what I can try to tweak? I am
still trying to debug this issue but right now my results are not
meaningful expect that no new output appears in the serial console as
soon as the devices stop responding. On an older revision, I
presumably was hit by #12726 (paused execution and saw that next
pointer of queue was pointing to the current element), but could not
reproduce that I am still hit by it with the latest master.
I’m not aware of any such issues (long term usage instability), at least not in the Bluetooth/Mesh code itself, however you might want to retest together with #13431 which was merged yesterday, in case the cause of your issues is a stack overflow.

Johan


Long-Term Bluetooth Mesh Reliability

Martin <ma@...>
 

Hi,
I am wondering if someone has already made experiments regarding the
long-term reliability of Bluetooth Mesh in Zephyr OS?

The reason why I am asking is this: I am on the latest master and I
use a Mesh setup consisting of ~10 devices (PCA10040 + PCA10059) with
an adjusted samples/boards/nrf52/mesh which additionally sends
heartbeat messages and at the same time blinks an LED (realized by a
timer that submits a work item which lights it, waits and switches it
off again). What I have been observing is the following: Devices that
only send a hertbeat message every 10 seconds run quite stable for
some days, but need to be power-cycled at some point in time (no
heartbeat messages, no LED blinking). Devices with higher load (e.g.
relay enabled, deliberately sending a higher amount of mesh messages)
are not responding within hours (no messages whatsoever, no LED
blinking). Even when taking pressure out of the mesh (not deliberately
sending messages anymore), they do not come back to life before I
power-cycle them.

Does someone possibly have an explanation for the issues I am
encountering or some tips regarding what I can try to tweak? I am
still trying to debug this issue but right now my results are not
meaningful expect that no new output appears in the serial console as
soon as the devices stop responding. On an older revision, I
presumably was hit by #12726 (paused execution and saw that next
pointer of queue was pointing to the current element), but could not
reproduce that I am still hit by it with the latest master.

Thanks,
Martin


Re: West Issue

Henrik Brix Andersen
 

Hi,

Why are you using sudo to run ninja flash? That will execute ninja as root and therefore also west as root.
When you are running “west init” you run it as your regular user.

Regards,
Brix

--
Henrik Brix Andersen

On 14 Feb 2019, at 20.02, Brianna Fahrenkopf <bfahrenkopf@gmail.com> wrote:

Hello,

We are creating a project using Zephyr and whenever I try to flash to my board I receive this error about west even though it says that west is initialized. I saw some thread online about this issue but I can’t seem to find a resolution. Any help would be appreciated.

<Messages Image(2796314178).png>

Kind Regards,
Brianna Fahrenkopf


BUGS (Zephyr v1.14.0-rc1) Feb 16 2019

Kumar Gala
 

263:bug

120:priority: low
95:priority: medium
6:priority: high

31:area: Networking
29:Coverity
15:area: Bluetooth
13:platform: nRF
13:area: Logging
12:area: Kernel
11:area: Drivers
10:area: Xtensa
10:area: ARM
8:platform: NXP
8:platform: ESP32
8:area: Samples
8:area: Documentation
7:area: Shell
7:area: Memory Protection
6:area: Watchdog
6:area: Sockets
5:area: USB
5:area: Toolchains
5:area: Power Management
5:area: POSIX
5:area: MISRA-C
5:area: Build System
4:platform: STM32
4:area: I2C
4:area: Device Tree
3:good first issue
3:area: west
3:area: UART
3:area: Timer
3:area: Security
3:area: PWM
3:area: NIOS2
3:area: Counter
3:API
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Flash
2:area: File System
2:area: Conformance
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:platform: SiLabs
1:platform: ATMEL
1:area: native port
1:area: mcumgr
1:area: X86
1:area: Testing Suite
1:area: Pinmux
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: LWM2M
1:area: Kconfig
1:area: IPC
1:area: Flashing
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:Security Review
1:RFC
1:LTS


[Zephyr Main] Guide for coremark setup on Zephyr OS

Brett Preston
 

Redirecting to devel@...

---------- Forwarded message ---------
From: Chee, Chrislynn <chrislynn.chee@...>
Date: Fri, Feb 15, 2019 at 6:21 AM
Subject: [Zephyr Main] Guide for coremark setup on Zephyr OS
To: main@... <main@...>


Hi,

I try to setup coremark tool on Zephyr OS but not able to find much information online. I need this to be loaded to my dev kit https://www.microchip.com/DevelopmentTools/ProductDetails/atsamv71-xult which is a Cortex M7 evaluation kit.

 

Would someone be able to guide me through?

 

Regards,

Chrislynn Chee

 



--
Brett Preston
Sr. Program Manager
The Linux Foundation
+1 (971) 303-9030


related to #BluetoothMesh & DFU_OTA #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,
this PR in local repo, we can do DFU OTA using Android #nRFConnect.

But I've observe following things:
1) If board is in non-provisioned state then DFU OTA start immediately
2) If board is in provisioned state then DFU OTA process takes 5-10 seconds
    to show the status of progress in percentages.  

Is it is correct behaviour ? If no, then how to overcome it ?
------------------------------------------------------------------------------------------------------------
Sometimes when we start the GATT connection (to access SMP service for DFU OTA)
with device then it get immediately get disconnected. Why ?
--------------------------------------------------------------------------------------------------------------
As we all know, after device get provisioned, it stop advertising as "zephyr" 
plus it don't show UUID associated with it (like it is in unprovisioned state)

If there are multiple provisioned node available, then in case of Android
if we want to connect particular NODE (for DFU OTA) then using its MAC address
we could find it & connect to it.

But in case of iOS, we can't do that since MAC address are hidden.

If we have CONFIG_BT_PRIVACY=y enable this Kconfig option, then we can't connect to
particular NODE for DFU OTA since every time after reboot MAC address is different.

All this things are confusing for me? Could anyone would like to through some light on
this ?


Thanks !!





Re: West Issue

Carles Cufi
 

Hi Brianna,

 

A few things to try and check:

 

  1. Make sure you exit the current shell and open a new one if you had sourced zephyr-env.sh in a pre-west zephyr tree with that shell, since that places the wrong west in the path
  2. Make sure that you clean the build/build folder completely (delete it) since there might be pre-west artifacts
  3. Make sure that you have run “west init -l zephyr/” if you were initializing an existing zephyr copy
  4. Run “west –version” from within the zephyr folder and you should see 2 lines, both with 0.5.1 or higher

 

Carles

 

From: devel@... <devel@...> On Behalf Of Brianna Fahrenkopf
Sent: 14 February 2019 20:02
To: devel@...
Cc: Nicholas Yameen <nicholas_yameen@...>
Subject: [Zephyr-devel] West Issue

 

Hello,

 

We are creating a project using Zephyr and whenever I try to flash to my board I receive this error about west even though it says that west is initialized. I saw some thread online about this issue but I can’t seem to find a resolution. Any help would be appreciated. 

 

 

Kind Regards,

Brianna Fahrenkopf


West Issue

Brianna Fahrenkopf <bfahrenkopf@...>
 

Hello,

We are creating a project using Zephyr and whenever I try to flash to my board I receive this error about west even though it says that west is initialized. I saw some thread online about this issue but I can’t seem to find a resolution. Any help would be appreciated. 


Kind Regards,
Brianna Fahrenkopf


Re: Bluetooth mesh using nrf52 pca10040 #bluetoothmesh #nrf52832

Johan Hedberg
 

Hi,

On 14 Feb 2019, at 15.43, kunal.jagadish07@gmail.com wrote:
Hey, I am trying to establish a bluetooth mesh using the Raspberry Pi 3 (bluez meshctl) as the provisioner and the nrf52 boards as the nodes. The nodes have to periodically send sensor data (LPN) to the provisioner (Raspberry Pi) across the mesh. The mesh will consist of ~5k nodes. I want to extract the data and the rssi value from the transmitted packet on the Raspberry Pi. How would I go about with this?
Since this is a BlueZ question it’d be better asked on the BlueZ mailing lists. I’ve added it to CC. E.g. Brian or Inga (who know the BlueZ mesh implementation very well) might be able to answer your question. I’m not sure if meshctl tracks the RSSI internally, but to my understanding the new mesh deamon does, so it might be just a matter of ensuring that it gets exposed through D-Bus somehow.

What’s not clear to me is do you want this for testing/debugging purposes or something for an actual application use? If it’s just for testing/debugging you can e.g. use btmon to see the raw HCI traffic, and that’ll then also show you the RSSI of every received advertising packet.

Johan


Re: i.MX 6/7 Flexcan driver Zephyr porting

Andrei Gansari
 

Hello Aymeric,

If you don’t mind using the bare metal driver in your application as Maureen suggested, there is also i.MX RT 1050 EVKB board that does support Ethernet and has an unpopulated CAN connector at J11. It's a cortex M7.

Andrei

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Maureen Helm
Sent: Thursday, February 14, 2019 3:50 PM
To: Aymeric <aymeric.aillet.iot.bzh@gmail.com>; Zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] i.MX 6/7 Flexcan driver Zephyr porting

Hi Aymeric,
There is a bare metal flexcan driver in ext/hal/nxp/imx/drivers that you can use as a starting point. You can create a shim to adapt it to the Zephyr CAN API, similar to what has been done for other NXP drivers.

For Ethernet, do you want to run that on the M4 Zephyr core or the A7 Linux core? It would be more challenging to get that working on the M4 core since we don't have a bare metal Ethernet driver to start with, and I don't know offhand if hardware allows that.

Maureen

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Aymeric
Sent: Wednesday, February 13, 2019 8:31 AM
To: Zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] i.MX 6/7 Flexcan driver Zephyr porting

Hi all,

I'm new to Zephyr's project, I tested some of the samples on a couples of boards.

For my project, I need a board on which Zephyr would support CAN & TCP/IP Stack.

I only found Zephyr CAN drivers for STM32 boards but they usually don't are equipped with Ethernet or at least are not supported.

So, my question is, is iMX 6/7 flexcan driver in a porting for Zephyr ?

My goal would be to use a NXP i.MX7 Colibri Board with a Evaluation Board, hardwarely, this board is CAN & Ethernet support.

My only other alternative would be to use a Stand-alone CAN controller but if I can avoid it, it would be nice.

Any advice would be appreciated.

Thanks,

Aymeric


Bluetooth mesh using nrf52 pca10040 #bluetoothmesh #nrf52832

kunal.jagadish07@...
 

Hey, I am trying to establish a bluetooth mesh using the Raspberry Pi 3 (bluez meshctl) as the provisioner and the nrf52 boards as the nodes. The nodes have to periodically send sensor data (LPN) to the provisioner (Raspberry Pi) across the mesh. The mesh will consist of ~5k nodes. I want to extract the data and the rssi value from the transmitted packet on the Raspberry Pi. How would I go about with this? 


Re: i.MX 6/7 Flexcan driver Zephyr porting

Maureen Helm
 

Hi Aymeric,
There is a bare metal flexcan driver in ext/hal/nxp/imx/drivers that you can use as a starting point. You can create a shim to adapt it to the Zephyr CAN API, similar to what has been done for other NXP drivers.

For Ethernet, do you want to run that on the M4 Zephyr core or the A7 Linux core? It would be more challenging to get that working on the M4 core since we don't have a bare metal Ethernet driver to start with, and I don't know offhand if hardware allows that.

Maureen

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Aymeric
Sent: Wednesday, February 13, 2019 8:31 AM
To: Zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] i.MX 6/7 Flexcan driver Zephyr porting

Hi all,

I'm new to Zephyr's project, I tested some of the samples on a couples of boards.

For my project, I need a board on which Zephyr would support CAN & TCP/IP Stack.

I only found Zephyr CAN drivers for STM32 boards but they usually don't are equipped with Ethernet or at least are not supported.

So, my question is, is iMX 6/7 flexcan driver in a porting for Zephyr ?

My goal would be to use a NXP i.MX7 Colibri Board with a Evaluation Board, hardwarely, this board is CAN & Ethernet support.

My only other alternative would be to use a Stand-alone CAN controller but if I can avoid it, it would be nice.

Any advice would be appreciated.

Thanks,

Aymeric


BUGS (Zephyr v1.14.0-rc1) Feb 14 2019

Kumar Gala
 

257:bug

121:priority: low
97:priority: medium
6:priority: high

32:area: Networking
29:Coverity
16:area: Bluetooth
13:platform: nRF
12:area: Kernel
11:area: Logging
11:area: Drivers
11:area: ARM
10:area: Xtensa
8:platform: ESP32
8:area: Samples
7:platform: NXP
7:area: Shell
7:area: Documentation
6:area: Sockets
6:area: Memory Protection
5:area: USB
5:area: Toolchains
5:area: Power Management
5:area: POSIX
5:area: MISRA-C
4:platform: STM32
4:area: Watchdog
4:area: I2C
4:area: Device Tree
4:area: Build System
3:good first issue
3:area: west
3:area: UART
3:area: Timer
3:area: Security
3:area: PWM
3:area: NIOS2
3:area: Counter
3:API
2:area: native port
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Flash
2:area: File System
2:area: Conformance
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:platform: SiLabs
1:platform: ATMEL
1:area: mcumgr
1:area: X86
1:area: Testing Suite
1:area: Pinmux
1:area: PCI
1:area: OpenThread
1:area: OTA
1:area: LWM2M
1:area: IPC
1:area: Flashing
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:Security Review
1:RFC
1:LTS


Re: strange board DTS parsing error

Kumar Gala
 

Reg is specifying which chip select to use. In your dts snippet since you have a cs-gpio I assumed that there is a single CS and so reg should be 0 instead of 1.

- k

On Feb 12, 2019, at 10:05 PM, Li, Jun R <jun.r.li@intel.com> wrote:

Hah, it works after reg is changed to <0>. Thank you, Kumar!

By the way, what does "reg=<0>" mean for the sensor bmi160 here?

Regards,
Jun


On 2/12/19, 19:36, "Kumar Gala" <kumar.gala@linaro.org> wrote:

I’m guessing this is because the reg should be set to 0 and not 1.

So it should be:

bmi160@0 {



reg = <0>;
...
};

- k

On Feb 12, 2019, at 6:11 PM, Li, Jun R <jun.r.li@intel.com> wrote:

Hi all,

I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e., adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file
“boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:

+
+&spi1 {
+ cs-gpios = <&gpiob 5 0>;
+ status = "ok";
+
+ bmi160@1 {
+ compatible = "bosch,bmi160";
+ reg = <0x1>;
+ label = "bmi160";
+ spi-max-frequency = <640000>;
+ int-gpios = <&gpioa 4 0>;
+ status = "ok";
+ };
+};

I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:

cmake -DBOARD=stm32f4_disco ..
Zephyr version: 1.14.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
-- Selected BOARD stm32f4_disco
-- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base
-- Overlaying /home/my/zephyr/dts/common/common.dts
Traceback (most recent call last):
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>
main()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main
generate_node_definitions()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions
extract_node_include_info(reduced, k, k, None)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info
node_compat, sub_node_address, c, v, names)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property
reg.extract(node_address, names, def_label, 1)
File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract
extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)
File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller
prop_array = [prop_array[index]]
IndexError: list index out of range
CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):
command failed with return code: 1
Call Stack (most recent call first):
/home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)
CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.

Thank you!

Jun Li



BUGS (Zephyr v1.14.0-rc1) Feb 13 2019

Kumar Gala
 

268:bug

126:priority: low
105:priority: medium
8:priority: high

39:Coverity

39:area: Networking
15:area: Bluetooth
13:area: Kernel
12:nRF
11:area: Logging
11:area: Drivers
11:area: ARM
10:area: Xtensa
9:area: LWM2M
9:NXP
8:area: Samples
8:area: Documentation
8:ESP32
7:area: Shell
7:area: Memory Protection
5:area: USB
5:area: Sockets
5:area: Power Management
5:area: POSIX
5:MISRA-C
4:west
4:area: Watchdog
4:area: Toolchains
4:area: I2C
4:area: Device Tree
4:area: Counter
4:area: Build System
4:STM32
3:good first issue
3:area: UART
3:area: Timer
3:area: Security
3:area: PWM
3:area: NIOS2
3:API
2:net_conformance
2:area: Tests
2:area: Testing
2:area: Sensors
2:area: Sanitycheck
2:area: SPI
2:area: Portability
2:area: Other
2:area: GPIO
2:area: Flash
2:area: File System
2:area: C Library
2:area: Boards
2:area: ARC
2:EXT
1:to do
1:question
1:area: native port
1:area: mcumgr
1:area: X86
1:area: Testing Suite
1:area: Pinmux
1:area: PCI
1:area: OTA
1:area: IPC
1:area: Ethernet
1:area: Debugging
1:area: Crypto / RNG
1:area: Console
1:area: Configuration System
1:TSC
1:SiLabs
1:Security Review
1:RFC
1:OpenThread
1:LTS
1:ATMEL


i.MX 6/7 Flexcan driver Zephyr porting

Aymeric
 

Hi all,

I'm new to Zephyr's project, I tested some of the samples on a couples of boards.

For my project, I need a board on which Zephyr would support CAN & TCP/IP Stack.

I only found Zephyr CAN drivers for STM32 boards but they usually don't are equipped with Ethernet or at least are not supported.

So, my question is, is iMX 6/7 flexcan driver in a porting for Zephyr ?

My goal would be to use a NXP i.MX7 Colibri Board with a Evaluation Board, hardwarely, this board is CAN & Ethernet support.

My only other alternative would be to use a Stand-alone CAN controller but if I can avoid it, it would be nice.

Any advice would be appreciated.

Thanks,

Aymeric


Re: strange board DTS parsing error

Li, Jun R
 

Hah, it works after reg is changed to <0>. Thank you, Kumar!

By the way, what does "reg=<0>" mean for the sensor bmi160 here?

Regards,
Jun


On 2/12/19, 19:36, "Kumar Gala" <kumar.gala@linaro.org> wrote:

I’m guessing this is because the reg should be set to 0 and not 1.

So it should be:

bmi160@0 {



reg = <0>;
...
};

- k

On Feb 12, 2019, at 6:11 PM, Li, Jun R <jun.r.li@intel.com> wrote:
>
> Hi all,
>
> I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e., adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file
> “boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:
>
> +
> +&spi1 {
> + cs-gpios = <&gpiob 5 0>;
> + status = "ok";
> +
> + bmi160@1 {
> + compatible = "bosch,bmi160";
> + reg = <0x1>;
> + label = "bmi160";
> + spi-max-frequency = <640000>;
> + int-gpios = <&gpioa 4 0>;
> + status = "ok";
> + };
> +};
>
> I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:
>
> cmake -DBOARD=stm32f4_disco ..
> Zephyr version: 1.14.0
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
> -- Selected BOARD stm32f4_disco
> -- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base
> -- Overlaying /home/my/zephyr/dts/common/common.dts
> Traceback (most recent call last):
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>
> main()
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main
> generate_node_definitions()
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions
> extract_node_include_info(reduced, k, k, None)
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info
> node_compat, sub_node_address, c, v, names)
> File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property
> reg.extract(node_address, names, def_label, 1)
> File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract
> extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)
> File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller
> prop_array = [prop_array[index]]
> IndexError: list index out of range
> CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):
> command failed with return code: 1
> Call Stack (most recent call first):
> /home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)
> CMakeLists.txt:3 (include)
>
> -- Configuring incomplete, errors occurred!
>
> If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.
>
> Thank you!
>
> Jun Li
>
>


Re: strange board DTS parsing error

Kumar Gala
 

I’m guessing this is because the reg should be set to 0 and not 1.

So it should be:

bmi160@0 {



reg = <0>;
...
};

- k

On Feb 12, 2019, at 6:11 PM, Li, Jun R <jun.r.li@intel.com> wrote:

Hi all,

I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e., adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file
“boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:

+
+&spi1 {
+ cs-gpios = <&gpiob 5 0>;
+ status = "ok";
+
+ bmi160@1 {
+ compatible = "bosch,bmi160";
+ reg = <0x1>;
+ label = "bmi160";
+ spi-max-frequency = <640000>;
+ int-gpios = <&gpioa 4 0>;
+ status = "ok";
+ };
+};

I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:

cmake -DBOARD=stm32f4_disco ..
Zephyr version: 1.14.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
-- Selected BOARD stm32f4_disco
-- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base
-- Overlaying /home/my/zephyr/dts/common/common.dts
Traceback (most recent call last):
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>
main()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main
generate_node_definitions()
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions
extract_node_include_info(reduced, k, k, None)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info
node_compat, sub_node_address, c, v, names)
File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property
reg.extract(node_address, names, def_label, 1)
File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract
extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)
File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller
prop_array = [prop_array[index]]
IndexError: list index out of range
CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):
command failed with return code: 1
Call Stack (most recent call first):
/home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)
CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.

Thank you!

Jun Li


strange board DTS parsing error

Li, Jun R
 

Hi all,

 

I’m trying to add a sensor board to a STM32F4 discovery board for a prototype, i.e.,  adding a BMI160 sensor to the SPI1 bus. To do that, I’ve modified the file

“boards/arm/stm32f4_disco/stm32f4_disco.dts” and added the following section:

 

+

+&spi1 {

+       cs-gpios = <&gpiob 5 0>;

+       status = "ok";

+

+       bmi160@1 {

+                compatible = "bosch,bmi160";

+                reg = <0x1>;

+                label = "bmi160";

+                spi-max-frequency = <640000>;

+                int-gpios = <&gpioa 4 0>;

+                status = "ok";

+        };

+};

 

I used samples/hello_world to validate my changes. However, when I built “hello_world” by specifying the board to “stm32f4_disco”, I got the following errors:

 

cmake -DBOARD=stm32f4_disco ..

Zephyr version: 1.14.0

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")

-- Selected BOARD stm32f4_disco

-- Loading /home/my/zephyr/boards/arm/stm32f4_disco/stm32f4_disco.dts as base

-- Overlaying /home/my/zephyr/dts/common/common.dts

Traceback (most recent call last):

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 542, in <module>

    main()

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 524, in main

    generate_node_definitions()

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 471, in generate_node_definitions

    extract_node_include_info(reduced, k, k, None)

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 300, in extract_node_include_info

    node_compat, sub_node_address, c, v, names)

  File "/home/my/zephyr/scripts/dts/extract_dts_includes.py", line 219, in extract_property

    reg.extract(node_address, names, def_label, 1)

  File "/home/my/zephyr/scripts/dts/extract/reg.py", line 49, in extract

    extract_controller(node_address, "cs-gpios", cs_gpios, reg[0], def_label, "cs-gpio", True)

  File "/home/my/zephyr/scripts/dts/extract/globals.py", line 373, in extract_controller

    prop_array = [prop_array[index]]

IndexError: list index out of range

CMake Error at /home/my/zephyr/cmake/dts.cmake:145 (message):

  command failed with return code: 1

Call Stack (most recent call first):

  /home/my/zephyr/cmake/app/boilerplate.cmake:401 (include)

  CMakeLists.txt:3 (include)

 

-- Configuring incomplete, errors occurred!

 

If I comment either the line “cs-gpios = <&gpiob 5 0>;” or the section “bmi160@1 { ...}” above, the cmake configuration will succeed. But keeping both will get the above errors. I have no idea why it generated the parsing error. I saw the board dts definition file “boards/arc/arduino_101_sss/arduino_101_sss.dts” also did the same thing but it doesn’t get this kind of error.

 

Thank you!

Jun Li

 


Re: ZEPHYR_TOOLCHAIN_VARIANT=host in docs? (Was: Zephyr SDK 0.10.0-rc2 available)

Marti Bolivar <marti@...>
 

On Mon, Feb 11, 2019 at 12:42 PM Marc Herbert <marc.herbert@intel.com> wrote:



On 8 Feb 2019, at 08:28, Nashif, Anas <anas.nashif@intel.com> wrote:

Do we make Zephyr 1.14 release with the stable 0.9.5 SDK?
No, Zephyr release is not tied to a toolchain. The SDK was always a one stop for everything you need to build and use zephyr, but you should be able to use any toolchain.
… including no “toolchain" in some cases thanks to ZEPHYR_TOOLCHAIN_VARIANT=host

I noticed ZEPHYR_TOOLCHAIN_VARIANT=host doesn’t seem mentioned in the documentation (I found it in the source). Would a one-liner in the "Getting Started" page be acceptable? I can submit.
I am responsible for this oversight in the documentation. If you
wouldn't mind sending a fix I would be happy to review it.

Thanks.

https://docs.zephyrproject.org/latest/getting_started/index.html?highlight=zephyr_toolchain_variant
https://docs.zephyrproject.org/latest/search.html?q=zephyr_toolchain_variant

Marc




2201 - 2220 of 7903