Date   

Re: Problem running samples/sensor/sht3xd #driver #sensor

Bolivar, Marti
 

Hi,

This email list is for upstream zephyr, not NCS, but since the sample is
available in upstream zephyr I will respond here.

"ilkka.virtanen via lists.zephyrproject.org"
<ilkka.virtanen=sensoan.com@...> writes:

Hi,

I've tried to run the sht3xd sample using nRF52840DK, which is one of the boards with sample configuration overlay file, but all I get out in the logs is this:
*** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
Could not get SHT3XD device

What I get from this log is that for some reason the system fails to
load the device driver for the sensor.
Be careful here. There is a difference between a device and a device
driver.

The device driver can be compiled into your binary correctly, but the
individual devices can fail to initialize, which is almost definitely
what is happening here.

In general, device_get_binding() returns NULL if the device
initialization function fails, or if there is no such device.


I'm relatively new to Zephyr
and I have trouble understanding how to debug the problem. Can anyone
give me pointers where to look?
Other than the driver model documentation and the driver source code,
I've been plugging my recent device model talk a lot lately:

https://www.youtube.com/watch?v=sWaxQyIgEBY

It may be useful. YMMV :)


I've built the sample using NordicConnectSDK 1.6.1 which uses Zephyr 2.6.0-rc1-ncs1
...NordicConnectSDK/1.6.1/zephyr/samples/sensor/sht3xd$ west build -b
nrf52840dk_nrf52840
Since, as you say, there is a devicetree overlay for the board you are
using here:

https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/sensor/sht3xd/boards/nrf52840dk_nrf52840.overlay

The device structure should be allocated. So I am assuming it just
failed to initialize correctly in your environment. Did you connect the
pins as described in the comments in the overlay file?

Try stepping through sht3xd_init() in your debugger to see where it
fails, or enable more verbose logs in the sensor driver using Kconfig to
see what went wrong.

Hope this helps,
Marti




Thanks.



Initialization and usage of device drivers in user code

akrckn <alexander@...>
 

Hello everyone,

I'm pretty new to the Zephyr Project as we (our company) are evaluating it to use it as our base for the upcoming projects.

It didn't take long to get our own application running on our hardware, but a
s we are developing battery powered modules we just activate and use devices when they really are needed.

Is there a way to define devices (e.g. BME280 below) in the device tree file and trigger the initialization and start / stop in the application code and how can we do that?

I'm assuming there is a solution and I didn't get or find it, yet - could you please help me?

&i2c1 {
pinctrl-0 = <&i2c1_scl_pb8 &i2c1_sda_pb9>;
status = "okay";
clock-frequency = <I2C_BITRATE_FAST>;
bme280@77 {
compatible = "bosch,bme280";
status = "okay";
reg = <0x77>;
label = "BME280";
};
};

Thank you in advance and best regards!


Problem running samples/sensor/sht3xd #driver #sensor

@Hidastelija
 

Hi,

I've tried to run the sht3xd sample using nRF52840DK, which is one of the boards with sample configuration overlay file, but all I get out in the logs is this:
*** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
Could not get SHT3XD device

What I get from this log is that for some reason the system fails to load the device driver for the sensor. I'm relatively new to Zephyr and I have trouble understanding how to debug the problem. Can anyone give me pointers where to look?

I've built the sample using NordicConnectSDK 1.6.1 which uses Zephyr 2.6.0-rc1-ncs1
...NordicConnectSDK/1.6.1/zephyr/samples/sensor/sht3xd$ west build -b nrf52840dk_nrf52840

Thanks.


Re: nRF9160 custom board dynamic GPIO #nrf9160

Bolivar, Marti
 

"DKaplan via lists.zephyrproject.org"
<DKaplan=amiglobal.com@...> writes:

Shalom!
Hello!


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.
Since you're using NCS, if you haven't figured this out yet, I'd
recommend asking on DevZone. This mailing list is for where you can get
community support for "vanilla" zephyr; DevZone is where you can get
official support for NCS from Nordic.

Good luck!
Marti


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



Defining preprocessor directives through #west

Diogo Correia
 

Hi everyone,

I'm trying to automate the building of a set of LoRaWAN boards by using preprocessor directives to set their keys. Is it possible to define the directives using west? I was only able to change compiling options (-D).

Kind regards,
Diogo Correia


SDK 0.13.0 Release

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.13.0

Please download and try things out and report any issues.

• general:
• Added support for ARC64. NOTE: GDB isn't currently supported for ARC64.
• CI/go.sh changes to make building MacOS and CI building easier.
• Various fixes for building/packaging on MacOS
• Added GitHub CI workflow to build MacOS x86_64 packages

• qemu:
• Updated to QEMU 6.0.0
• Added arc64 support. NOTE: this update ARC support replaces the machine (-M simhs) with (-M virt). This change will require updates to boards/arc/qemu_arc/board.cmake in Zephyr to match.
• Pull in fix from upstream for TFM: target/arm: Use correct SP in M-profile exception
• Pull in fixes from upstream for: hw/arm: Fix modelling of SSE-300 TCMs and SRAM

• gcc:

• Update to gcc 10.3 release
• Added support for ARC64
• Removed libgcc transactional memory clone registry support
• Fixed incorrect build specs for libstdc++ nano variant. The libstdc++ nano
variant, which is used with newlib-nano, is now built with -fno-exceptions to reduce compiled binary size.

• binutils:
• Updated to add support for ARC64

• newlib:
• Updated to add support for ARC64
• Added multithreading support
• Fix nano.spec file to pull in nano libraries.
• Set -mthumb-interwork for nano newlib builds to workaround at crosstool issue.

• crosstool-ng:
• sync with upstream. Upstream now supports newlib-nano so we drop our Zephyr specific updates. This also pulls in gcc-10.3 and initial support for ARC64.
• Fix stripping of newlib-nano libs

• yocto:
• Update to yocto 3.2.3 baseline. This is in prep to support building qemu-6.0.0

• openocd:
• Update to upstream 20210630 snapshot

Thanks to all that contributed fixes and enhancements to this version of the SDK.


Networking Forum Agenda

Lubos, Robert
 

Hi all,

 

There is a networking forum tomorrow Tue 3 August at 8AM PST / 17.00 CEST.

 

The current agenda is empty, please let me know if there are any topics you’d like to discuss. Otherwise, I’ll cancel the meeting.

 

Meeting notes:

https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0

 

Shared Folder:

https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

 

Teams meeting:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

 

Regards,
ROBERT LUBOS | Senior Firmware Engineer
M +48 504 088 482 | Krakow, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 


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

David Kaplan
 

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

danwin354@...
 

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

421 - 440 of 3086