Date   

k_uptime_get values in QEMU

martin.schoenstedt@...
 

Hello,
I am experiencing a problem and don't know how to solve it. Running k_uptime_get() returns the same value as k_uptime_ticks() and is a lot higher than the actual uptime in milliseconds. I did not change any configurations and am using Zephyr version 2.6.0. Did anyone encounter a similar problem or is this a problem related to QEMU? (I don't have a physical board to check the same samples there).
Thankful for any help!

kind regards
Martin Schönstedt


Re: Esp32 flashing issue on Ubuntu 20.10

William Fish
 

Hi,
It could be as simple as you can not have a console connection and trying to flash as the USB is not good at handling two simultaneous connects. Happens to me all the time.


Re: Esp32 flashing issue on Ubuntu 20.10

Frank Duignan
 

You need to be a member of the dialout group. For example
sudo adduser pritam dialout
Then logout and back in again

On Wed 28 Jul 2021, 15:28 pritam sutar, <pritamsutar660@...> wrote:
I am able to build code for esp32 but flash is being failed by denying permission on ttyUSB0.

Any help would be appreciated.


Esp32 flashing issue on Ubuntu 20.10

pritam sutar <pritamsutar660@...>
 

I am able to build code for esp32 but flash is being failed by denying permission on ttyUSB0.

Any help would be appreciated.


nRF9160 custom board dynamic GPIO #nrf9160

DKaplan@...
 

Shalom!

We have a nRF9160 custom board on which I cannot switch some of the IO lines.

For example we have two leds, P0.9 an P0.10 but only P0.9 works. The hardware guy reports the P0.10 output (scope) does not change when I toggle the output while debugging. I tried moving the led to P0.30 & P0.31 also without success. Also I need to change a uart1's rx and tx lines in some scenarios when it is not used to save energy. In this case I do not call uart_dev = device_get_binding("UART_1"), but want to just clear both lines. I am evidently doing something wrong or missing something. The gpio APIs all report no errors and in the debugger I see that the pin numbers are correct.
I have defined a custom board in the  \ncs\v1.6.0\zephyr\boards\arm\ folder based on the nrf21540dk_nrf52840.

I need to change IO on the fly to save power of course. I am new to Zephyr. I have all of the pins I plan to manipulate defined in the board's dts file in the zephyr\boards directory.

Do I need to add something to my ns overlay? I do not know why P0.9 works but P0.10 does not if it is a security error.
Could there possibly be a conflict with something else using those pins?
Where in my build output can I check what the pin definitions are in use?
Can I dynamically switch any GPIO pin or do I have to define all of them in my overlay files?
Can I dynamically redefine pins used in a module (uart,pwm,etc) to GPIO to lower power consumption?

Thanks David


Re: Compiler and linker warnings with GCC 11

Kumar Gala
 

Some of these issues might be resolved by:

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

- k

On Jul 21, 2021, at 4:06 AM, Sven Vainküla <svenvainkyla@gmail.com> wrote:

Hello!

After updating my GCC to version 11.1.0 I started getting a bunch of linker
errors when compiling projects. Previously I was using GCC 10.2.0.

For example, when building the sample hello_world project using:
west build -b stm32f4_disco
Many warnings are emitted that are related to
Z_KERNEL_STACK_ARRAY_x macros, for example:
[...]
[56/139] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/thread.c.obj
In file included from ../../../include/kernel_includes.h:39,
from ../../../include/kernel.h:17,
from /home/sv/extern-projects/zephyr/zephyr/arch/arm/core/aarch32/thread.c:15:
../../../include/kernel/thread_stack.h:157:16: warning: ignoring attribute 'section (".noinit.\"../../../kernel/include/kernel_internal.h\".1")' because it conflicts with previous 'section (".noinit.\"../../../arch/arm/include/aarch32/cortex_m/stack.h\".0")' [-Wattributes]
157 | struct z_thread_stack_element lsect \
| ^~~~~~~~~~~~~~~~~~~~~~
../../../include/kernel/thread_stack.h:221:9: note: in expansion of macro 'Z_KERNEL_STACK_ARRAY_DEFINE_IN'
221 | Z_KERNEL_STACK_ARRAY_DEFINE_IN(sym, nmemb, size, __kstackmem)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../kernel/include/kernel_internal.h:155:8: note: in expansion of macro 'K_KERNEL_STACK_ARRAY_DEFINE'
155 | extern K_KERNEL_STACK_ARRAY_DEFINE(z_interrupt_stacks, CONFIG_MP_NUM_CPUS,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../arch/arm/include/aarch32/cortex_m/stack.h:29:36: note: previous declaration here
29 | extern K_KERNEL_STACK_ARRAY_DEFINE(z_interrupt_stacks, CONFIG_MP_NUM_CPUS,
| ^~~~~~~~~~~~~~~~~~
../../../include/kernel/thread_stack.h:159:17: note: in definition of macro 'Z_KERNEL_STACK_ARRAY_DEFINE_IN'
159 | sym[nmemb][Z_KERNEL_STACK_LEN(size)]
| ^~~
../../../arch/arm/include/aarch32/cortex_m/stack.h:29:8: note: in expansion of macro 'K_KERNEL_STACK_ARRAY_DEFINE'
29 | extern K_KERNEL_STACK_ARRAY_DEFINE(z_interrupt_stacks, CONFIG_MP_NUM_CPUS,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
A couple of linker warnings are also emitted during linking:
[132/139] Linking C executable zephyr/zephyr_prebuilt.elf
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_line_str' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_aeabi_uldivmod.o)' being placed in section `.debug_line_str'
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_loclists' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_udivmoddi4.o)' being placed in section `.debug_loclists'
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_rnglists' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_udivmoddi4.o)' being placed in section `.debug_rnglists'
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_line_str' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_dvmd_tls.o)' being placed in section `.debug_line_str'
The same warnings occur when building for the nRF development kit.

Noticed the issue first while using the Nordic nRF SDK, but it also happens
with non-nRF Zephyr. Tested with latest Zephyr at the time of this e-mail
(HEAD at 0ef77d4ea41fb765061c64896b3fbd0b2e4bc276).

The configuration flag CONFIG_LINKER_ORPHAN_SECTION_PLACE does get rid of
the linker warnings, but the compiler warnings related to
Z_KERNEL_STACK_ARRAY_* remain.

I don't think that this is related to an invalid configuration of the build
environment, as compilation used to complete without these linker warnings.
This causes a lot of noise in the build logs that can mask other warnings.

Does anyone have any ideas on how to fix these build errors?
Is this a known bug or have I misconfigured something that just didn't
manifest with an older GCC?

Best regards
Sven Vainküla






Re: TF-M samples build

Bolivar, Marti
 

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

Hi,

Welcome to Zephyr! There is a pull request open adding a TF-M guide:

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

I haven't had a chance to read through it, but you may find it useful.
D'oh, I forgot to reply-all.


Martí

"Philippe Gerard via lists.zephyrproject.org"
<philippegera=gmail.com@lists.zephyrproject.org> writes:

HI All.
nice to meet you, this is my first day evaluating Zephyr. it looks pretty
exciting, i have struggled to build the TFM samples. is there a clear
procedure to build them on windows for a nRF5340DK target?

does it exist any other basic sample using TFM (such as an hello word)?

thanks a lot
Philippe



<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



Re: Cmake Error While Building Blinky Sample

Carles Cufi
 

Have you set GNUARMEMB_TOOLCHAIN_PATH ?

 

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

 

Also, have you tried cleaning your build/ folder?

 

Carles

 

From: users@... <users@...> On Behalf Of Daniel Wing via lists.zephyrproject.org
Sent: 21 July 2021 19:08
To: users@...
Subject: [Zephyr-users] Cmake Error While Building Blinky Sample

 

Hello,

 

I am trying to west build the blinky sample from the getting started guide (https://docs.zephyrproject.org/latest/getting_started/index.html). However, the below error comes up:

 

 

C:\zephyrproject\zephyr>west build -p auto -b nrf52840dk_nrf52840 samples\basic\blinky
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): C:/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.6.99 (C:/zephyrproject/zephyr), build: zephyr-v2.6.0-806-gf818d8770b04
-- Found west (found suitable version "0.11.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Cache files will be written to: C:/zephyrproject/zephyr/.cache
-- Found toolchain: gnuarmemb (C:/gnu_arm_embedded)
CMake Error at C:/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake:8 (message):
  Zephyr was unable to find the toolchain.  Is the environment misconfigured?


  User-configuration:

  ZEPHYR_TOOLCHAIN_VARIANT: gnuarmemb

  Internal variables:

  CROSS_COMPILE: C:/gnu_arm_embedded/bin/arm-none-eabi-

  TOOLCHAIN_HOME: C:/gnu_arm_embedded

Call Stack (most recent call first):
  C:/zephyrproject/zephyr/cmake/generic_toolchain.cmake:42 (include)
  C:/zephyrproject/zephyr/cmake/app/boilerplate.cmake:570 (include)
  C:/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  C:/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-DWEST_PYTHON=c:\python39\python.exe' '-BC:\zephyrproject\zephyr\build' '-SC:\zephyrproject\zephyr\samples\basic\blinky' -GNinja

 

 

I have tried restarting my pc, and checked the GNU ARM Embedded toolchain installation and that the environment variables were set correctly. I have also checked that the cmake folder exists in the zephyrproject and I tried reinstalling the cmake packages. Still the same error keeps occurring.

 

Any help with diagnosing and fixing this issue would be greatly appreciated.

 

 

Best,

Daniel Wing


TF-M samples build

Philippe Gerard <philippegera@...>
 

HI All. 
nice to meet you, this is my first day evaluating Zephyr. it looks pretty exciting, i have struggled to build the TFM samples. is there a clear procedure to build them on windows for a nRF5340DK target? 

does it exist any other basic sample using TFM (such as an hello word)?

thanks a lot
Philippe



Virus-free. www.avast.com


Cmake Error While Building Blinky Sample

Daniel Wing
 

Hello,

I am trying to west build the blinky sample from the getting started guide (https://docs.zephyrproject.org/latest/getting_started/index.html). However, the below error comes up:


C:\zephyrproject\zephyr>west build -p auto -b nrf52840dk_nrf52840 samples\basic\blinky
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): C:/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.6.99 (C:/zephyrproject/zephyr), build: zephyr-v2.6.0-806-gf818d8770b04
-- Found west (found suitable version "0.11.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Cache files will be written to: C:/zephyrproject/zephyr/.cache
-- Found toolchain: gnuarmemb (C:/gnu_arm_embedded)
CMake Error at C:/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake:8 (message):
  Zephyr was unable to find the toolchain.  Is the environment misconfigured?


  User-configuration:

  ZEPHYR_TOOLCHAIN_VARIANT: gnuarmemb

  Internal variables:

  CROSS_COMPILE: C:/gnu_arm_embedded/bin/arm-none-eabi-

  TOOLCHAIN_HOME: C:/gnu_arm_embedded

Call Stack (most recent call first):
  C:/zephyrproject/zephyr/cmake/generic_toolchain.cmake:42 (include)
  C:/zephyrproject/zephyr/cmake/app/boilerplate.cmake:570 (include)
  C:/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  C:/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-DWEST_PYTHON=c:\python39\python.exe' '-BC:\zephyrproject\zephyr\build' '-SC:\zephyrproject\zephyr\samples\basic\blinky' -GNinja



I have tried restarting my pc, and checked the GNU ARM Embedded toolchain installation and that the environment variables were set correctly. I have also checked that the cmake folder exists in the zephyrproject and I tried reinstalling the cmake packages. Still the same error keeps occurring.

Any help with diagnosing and fixing this issue would be greatly appreciated.


Best,
Daniel Wing


Compiler and linker warnings with GCC 11

Sven Vainküla <svenvainkyla@...>
 

Hello!

After updating my GCC to version 11.1.0 I started getting a bunch of linker
errors when compiling projects. Previously I was using GCC 10.2.0.

For example, when building the sample hello_world project using:
west build -b stm32f4_disco
Many warnings are emitted that are related to
Z_KERNEL_STACK_ARRAY_x macros, for example:
[...]
[56/139] Building C object
zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/thread.c.obj
In file included from ../../../include/kernel_includes.h:39,
                  from ../../../include/kernel.h:17,
                  from
/home/sv/extern-projects/zephyr/zephyr/arch/arm/core/aarch32/thread.c:15:
../../../include/kernel/thread_stack.h:157:16: warning: ignoring
attribute 'section (".noinit.\"../../../kernel/include/kernel_internal.h\".1")' because it conflicts with previous 'section (".noinit.\"../../../arch/arm/include/aarch32/cortex_m/stack.h\".0")' [-Wattributes]
   157 |         struct z_thread_stack_element lsect \
       |                ^~~~~~~~~~~~~~~~~~~~~~
../../../include/kernel/thread_stack.h:221:9: note: in expansion of
macro 'Z_KERNEL_STACK_ARRAY_DEFINE_IN'
   221 |         Z_KERNEL_STACK_ARRAY_DEFINE_IN(sym, nmemb, size,
__kstackmem)
       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../kernel/include/kernel_internal.h:155:8: note: in expansion
of macro 'K_KERNEL_STACK_ARRAY_DEFINE'
   155 | extern K_KERNEL_STACK_ARRAY_DEFINE(z_interrupt_stacks,
CONFIG_MP_NUM_CPUS,
       |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../arch/arm/include/aarch32/cortex_m/stack.h:29:36: note:
previous declaration here
    29 | extern K_KERNEL_STACK_ARRAY_DEFINE(z_interrupt_stacks,
CONFIG_MP_NUM_CPUS,
       |                                    ^~~~~~~~~~~~~~~~~~
../../../include/kernel/thread_stack.h:159:17: note: in definition of
macro 'Z_KERNEL_STACK_ARRAY_DEFINE_IN'
   159 |                 sym[nmemb][Z_KERNEL_STACK_LEN(size)]
       |                 ^~~
../../../arch/arm/include/aarch32/cortex_m/stack.h:29:8: note: in
expansion of macro 'K_KERNEL_STACK_ARRAY_DEFINE'
    29 | extern K_KERNEL_STACK_ARRAY_DEFINE(z_interrupt_stacks,
CONFIG_MP_NUM_CPUS,
       |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
A couple of linker warnings are also emitted during linking:
[132/139] Linking C executable zephyr/zephyr_prebuilt.elf
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_line_str' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_aeabi_uldivmod.o)' being placed in section `.debug_line_str'
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_loclists' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_udivmoddi4.o)' being placed in section `.debug_loclists'
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_rnglists' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_udivmoddi4.o)' being placed in section `.debug_rnglists'
/usr/lib/gcc/arm-none-eabi/11.1.0/../../../../arm-none-eabi/bin/ld.bfd: warning: orphan section `.debug_line_str' from `/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7e-m/nofp/libgcc.a(_dvmd_tls.o)' being placed in section `.debug_line_str'

The same warnings occur when building for the nRF development kit.

Noticed the issue first while using the Nordic nRF SDK, but it also happens
with non-nRF Zephyr. Tested with latest Zephyr at the time of this e-mail
(HEAD at 0ef77d4ea41fb765061c64896b3fbd0b2e4bc276).

The configuration flag CONFIG_LINKER_ORPHAN_SECTION_PLACE does get rid of
the linker warnings, but the compiler warnings related to
Z_KERNEL_STACK_ARRAY_* remain.

I don't think that this is related to an invalid configuration of the build
environment, as compilation used to complete without these linker warnings.
This causes a lot of noise in the build logs that can mask other warnings.

Does anyone have any ideas on how to fix these build errors?
Is this a known bug or have I misconfigured something that just didn't
manifest with an older GCC?

Best regards
Sven Vainküla


Re: lis2mdl magnetometer in microbit v2 #i2c #driver #lis2dw12

William Fish
 
Edited

I've had a quick look and am confused as there is reference to a file:
#include "lis2mdl_reg.h"

It appears that when this driver was created they may have forgotten to include both lis2mdl_reg.c and lis2mdl_reg.h, eg like these:
https://os.mbed.com/teams/ST/code/LIS2MDL//file/8562ae1a0534/lis2mdl_reg.c/https://github.com/tencentyun/qcloud-iot-c-sdk-porting-examples/blob/master/Tencent_icube_based_Nucleol476_FreeRTOS/Drivers/BSP/Components/lis2mdl/lis2mdl_reg.c

Billy..


Re: lis2mdl magnetometer in microbit v2 #i2c #driver #lis2dw12

Armando VISCONTI <armando.visconti@...>
 

Hi Marti,

On 7/14/21 9:15 PM, Bolivar, Marti wrote:
Hi,
+Armando
"frank.duignan via lists.zephyrproject.org"
<frank.duignan=gmail.com@lists.zephyrproject.org> writes:

I have been experimenting with the microbit v2 and zephyr.  Everything seems to work ok except for the magnetometer.  The values it produces do not change when you re-orient the device.  If you re-orient the device and power cycle it you will see a new set of values which will remain unchanged until the next power cycle. My build version is zephyr-v2.6.0-535-gbd09d4ff3f81
The accelerometer, bluetooth and digital i/o all work fine.
While wandering through the code and experimenting with various configuration options I came across an error in lis2mdl.c on line 453:
const struct lis2mdl_config *cfg = dev->config;
There is no 'dev' parameter passed to this function however there is a "config" parameter and this modification works:
const struct lis2mdl_config *cfg = config;// dev->config;
Did you send a pull request with the fix? If not, please do. Although
I'm confused about how this builds with no 'dev' in scope.
I confirm that, in case CONFIG_PM_DEVICE is enabled, the driver does not
build correctly.
I just created a pull request with the fix (#36975) as suggested by
Frank.

Having said that, I doubt this PR will fix the original issue of the
reporter ("The values it produces do not change when you re-orient the
device"), as the lis2mdl pm_control init routine was never called (in
the PR I fixed also this).

I suggest to open a specific bug for it and I'll look into it.
Thanks for reporting this build bug!

Armando


Re: lis2mdl magnetometer in microbit v2 #i2c #driver #lis2dw12

Bolivar, Marti
 

Hi,

+Armando

"frank.duignan via lists.zephyrproject.org"
<frank.duignan=gmail.com@lists.zephyrproject.org> writes:

I have been experimenting with the microbit v2 and zephyr.  Everything seems to work ok except for the magnetometer.  The values it produces do not change when you re-orient the device.  If you re-orient the device and power cycle it you will see a new set of values which will remain unchanged until the next power cycle. My build version is zephyr-v2.6.0-535-gbd09d4ff3f81
The accelerometer, bluetooth and digital i/o all work fine.
While wandering through the code and experimenting with various configuration options I came across an error in lis2mdl.c on line 453:
const struct lis2mdl_config *cfg = dev->config;
There is no 'dev' parameter passed to this function however there is a "config" parameter and this modification works:
const struct lis2mdl_config *cfg = config;// dev->config;
Did you send a pull request with the fix? If not, please do. Although
I'm confused about how this builds with no 'dev' in scope.

Martí




bt_gatt_read() multiply read #bluetooth #nrf52840

antonsolonovich@...
 

Hello,
I use nrf52840-dk as central_hr and nrf52833-dk as peripheral_hr, examples from NRF Connect SDK.
I want to read two or more values using bt_gatt_read().
Code:


dis->read_params.func = gatt_read_cb;
dis->read_params.handle_count  = 2;
dis->read_params.handles = dis_handles;
err = bt_gatt_read(dis->conn, &(dis->read_params));


I read two values,

BT_UUID_DIS_MODEL_NUMBER, which is "Model"

and BT_UUID_DIS_SERIAL_NUMBER, with value "serial"

Here you can see part of my log,


gatt read cb // We are in callback
 
data length 11 //One length for two values?
 
data = Modelserial //Don't understand how to split it
 
gatt read cb //Extra callback with zero length? Does it mean that reading finished?
 
data length 0
 
empty data


The problem is that in multiply read I get one callback and one length for all values,
and I don't understand how to split it, and what value for what characteristic is.

Also I've asked it on DevZone 
https://devzone.nordicsemi.com/f/nordic-q-a/77045/discovery-dis
but no success there

Thank you,
Anton


Re: Understanding Ztest and Test Execution for Zephyr

Kevin Townsend
 

At the recent Zephyr Dev Summit, there was a talk -- "On-target testing with Twister and the process of results publishing" -- which covers this. It doesn't look like that video has been published yet, but they're releasing them in batches and it should be available here shortly: https://zephyrproject.org/blog/

The "Testing Mini Conference" is the one you'll want, see Day One here: https://zephyrproject.org/zephyr-developer-summit-day-1-preview/

Kevin


On Tue, 13 Jul 2021 at 10:35, Pandey, Mithun <mithunpandey@...> wrote:

HI all,

 

I was going through the test documentation under https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/guides/test/ztest.rst

Is there any more documentation available regarding understanding Ztest framework, and also the testcase.yaml and other files available to define the test scenarios.

 

I am also trying to understand the way these test cases are executed, based on the GitHub actions, it looks like the tests are only running on the QEMU emulator on ubuntu VMs.

But seeing the test reports it looks like the Test are also running for different architectures under different boards on HW also.

 

How are the tests on HW getting executed and triggered for each pull requests ? any pointers in this area will be helpful.

 

Thanks and Regards

Mithun

 

 


Understanding Ztest and Test Execution for Zephyr

Pandey, Mithun
 

HI all,

 

I was going through the test documentation under https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/guides/test/ztest.rst

Is there any more documentation available regarding understanding Ztest framework, and also the testcase.yaml and other files available to define the test scenarios.

 

I am also trying to understand the way these test cases are executed, based on the GitHub actions, it looks like the tests are only running on the QEMU emulator on ubuntu VMs.

But seeing the test reports it looks like the Test are also running for different architectures under different boards on HW also.

 

How are the tests on HW getting executed and triggered for each pull requests ? any pointers in this area will be helpful.

 

Thanks and Regards

Mithun

 

 


lis2mdl magnetometer in microbit v2 #i2c #driver #lis2dw12

Frank Duignan
 

I have been experimenting with the microbit v2 and zephyr.  Everything seems to work ok except for the magnetometer.  The values it produces do not change when you re-orient the device.  If you re-orient the device and power cycle it you will see a new set of values which will remain unchanged until the next power cycle. My build version is zephyr-v2.6.0-535-gbd09d4ff3f81
The accelerometer, bluetooth and digital i/o all work fine.
While wandering through the code and experimenting with various configuration options I came across an error in lis2mdl.c on line 453:
const struct lis2mdl_config *cfg = dev->config;
There is no 'dev' parameter passed to this function however there is a "config" parameter and this modification works:
const struct lis2mdl_config *cfg = config;// dev->config;
 


Re: options for missing driver functions

Jeff Haynes <feedyurhed@...>
 


Yes, we have production boards for a medical device we’re building. 

Thanks,

Jeff



On Mon, Jul 5, 2021 at 11:35 AM Armando VISCONTI <armando.visconti@...> wrote:
On 6/30/21 9:26 PM, Jeff Haynes wrote:
>
> Thanks a lot for the fast response.  That sounds great and I'd be happy
> to contribute whenever you're ready.  Do you have any idea what you're
> thinking in terms of timing?
>

Well, I have other non-zephyr related stuff to carry on.
I guess I can start working on it in a couple of weeks from now.

Is this req related to any particular project?

Thanks,
Armando
--
If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Antoine de Saint-Exupery


Re: options for missing driver functions

Armando VISCONTI <armando.visconti@...>
 

On 6/30/21 9:26 PM, Jeff Haynes wrote:
Thanks a lot for the fast response.  That sounds great and I'd be happy to contribute whenever you're ready.  Do you have any idea what you're thinking in terms of timing?
Well, I have other non-zephyr related stuff to carry on.
I guess I can start working on it in a couple of weeks from now.

Is this req related to any particular project?

Thanks,
Armando

1 - 400 of 2659