&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!

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:

"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

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

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.

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

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.

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

Some of these issues might be resolved by:

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

- k

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>

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

I've had a quick look and am confused as there is reference to a file:

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

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

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.

Martí