Date   

Re: HCI SPI - how to use

Bolivar, Marti
 

Hi,

The hci_spi sample was originally upstreamed for use on the nRF51 chip
on the 96Boards Carbon board.

Please refer to the documentation for that board for more information.
You can refer to 96b_carbon and 96b_carbon_nrf51 board configurations as
a starting point for your own application.

Marti

"Piotr Barszczewski via lists.zephyrproject.org"
<piotr=1am.pl@lists.zephyrproject.org> writes:

Hello,

I’ve found that Zephyr HCI stack supports SPI as transport and there is an
implementation available
https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html
I’m wondering how could this actually be tested - just by sending raw HCI
bytes to the board flashed with
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi
?

My interest is in somehow making it possible for embedded Linux
distribution be able to use SPI transport for HCI. With all the chip
shortages of recent months and unsure about future I’m looking for a way to
get rid of relying on USB. Uart would be good but is already used + I need
more than 1, so besides USB I’ve only got SPI left but not sure how it’s
supposed to be tested. Guess I’m missing what the host should do, with USB
it’s clear.

Is there anybody who has prior experience with running the HCI SPI
implementation?

Best regards



HCI SPI - how to use

Piotr Barszczewski <piotr@...>
 

Hello,

I’ve found that Zephyr HCI stack supports SPI as transport and there is an implementation available https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html 
I’m wondering how could this actually be tested - just by sending raw HCI bytes to the board flashed with https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi ?

My interest is in somehow making it possible for embedded Linux distribution be able to use SPI transport for HCI. With all the chip shortages of recent months and unsure about future I’m looking for a way to get rid of relying on USB. Uart would be good but is already used + I need more than 1, so besides USB I’ve only got SPI left but not sure how it’s supposed to be tested. Guess I’m missing what the host should do, with USB it’s clear.

Is there anybody who has prior experience with running the HCI SPI implementation?

Best regards
 


Re: Edge connectors and pin numbers

Bolivar, Marti
 

Hi,

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

I'm working with the BBC Microbit V2 and can use the peripherals using the NRF port pin numbers etc.  These port pins are brought to an edge connector which numbers them completely differently.  There seems to be some support for this in the bbc_microbit_v2 dts file in the following form:
edge_connector: connector {
compatible = "microbit,edge-connector";
#gpio-cells = <2>;
gpio-map-mask = <0xffffffff 0xffffffc0>;
gpio-map-pass-thru = <0 0x3f>;
gpio-map = <0 0 &gpio0 2 0>, /* P0 */
<1 0 &gpio0 3 0>, /* P1 */
<2 0 &gpio0 4 0>, /* P2 */
<3 0 &gpio0 31 0>, /* P3 */
<4 0 &gpio0 28 0>, /* P4 */
<5 0 &gpio0 14 0>, /* P5 */
<6 0 &gpio1 5 0>, /* P6 */
<7 0 &gpio0 11 0>, /* P7 */
<8 0 &gpio0 10 0>, /* P8 */
<9 0 &gpio0 9 0>, /* P9 */
<10 0 &gpio0 30 0>, /* P10 */
<11 0 &gpio0 23 0>, /* P11 */
<12 0 &gpio0 12 0>, /* P12 */
<13 0 &gpio0 17 0>, /* P13 */
<14 0 &gpio0 1 0>, /* P14 */
<15 0 &gpio0 13 0>, /* P15 */
<16 0 &gpio1 2 0>, /* P16 */
<19 0 &gpio0 26 0>, /* P19 */
<20 0 &gpio1 0 0>; /* P20 */
};
};
Yes, this is a GPIO nexus node. For details on these, see "2.5 Nexus
Nodes and Specifier Mapping" in the DT spec v0.3:

https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

Nexus nodes are weird and can be confusing to deal with at first.

I've been meaning to improve the documentation for these for a while,
but hopefully the following reply will help, with extra details for the
sake of the list archives.

My question is: how do I get a binding to one/all of these i/o pins.  I've tried many many combinations of DT_ macros.  The following returns a non null value for "edge" but I can't figure out how to access the pins on that edge connector using the connector pin  numbering scheme.
struct device *edge; edge=DEVICE_DT_GET(DT_NODELABEL(edge_connector));
Right, this doesn't work because there is no driver which allocates
struct devices for the "microbit,edge-connector" compatible.

I'm going to shamelessly keep plugging my recent talk which explains how
all this works in more detail:

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

Since it's not a GPIO controller node, but a nexus node, there isn't a
single GPIO device in C which corresponds to it. All you can really do
with it is specify GPIOs in other properties, which will map to the
underlying GPIO controller/pin/flags/etc according to the gpio-map and
other properties.

I said it was confusing at first, right?

It's not a show stopper as I can revert to nordic pin numbering but it
would be nice if the numbers in the C code corresponded to the label
on the board.
Here is a simple example of how you can use this from C with
/zephyr,user and struct gpio_dt_spec, with error handling omitted for
brevity. (See the DT bindings guide for more on /zephyr,user.)

app.overlay:

/ {
zephyr,user {
/* P1, active high */
foo-gpios = <&edge_connector 1 GPIO_ACTIVE_HIGH>;
};
};

main.c:

#include <zephyr.h>
#include <sys/printk.h>
#include <devicetree.h>
#include <drivers/gpio.h>

static struct gpio_dt_spec foo =
GPIO_DT_SPEC_GET(DT_PATH(zephyr_user), foo_gpios);

void main(void)
{
printk("Using device %s pin %d\n",
foo.port->name, foo.pin);

gpio_pin_configure_dt(&foo, GPIO_OUTPUT);
while (1) {
gpio_pin_set_dt(&foo, 0);
k_msleep(10);
gpio_pin_set_dt(&foo, 1);
k_msleep(10);
}
}

This should print "Using device GPIO_0 pin 3", and toggle that GPIO
forever. I don't have your hardware, so I can't test, but something
similar works on nRF52-DK with the arduino_header nexus node.

Notice how a full specification of a pin requires GPIO flags in addition
to the controller/pin number. See include/dt-bindings/gpio/gpio.h for
other flags you can use besides GPIO_ACTIVE_HIGH.

This is another case of the devicetree "vanishing" like I described in
my talk -- the edge_connector node itself has no representation as a
device, but you can use it at compile time to find the "real" devices
(foo.port in this case) that are broken out onto the connector.

If you want to get fancy with multiple pins, you can do something like
this:

foo-gpios = <&edge_connector 0 GPIO_ACTIVE_HIGH>, /* P0 */
<&edge_connector 1 GPIO_ACTIVE_LOW>, /* P1, opposite polarity */
...;

and then:

#define GET_PIN_N(node_id, prop, n) GPIO_DT_SPEC_GET_BY_IDX(node_id, prop, n),

static struct gpio_dt_spec foos[] = {
DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), foo_gpios, GET_PIN_N)
};

for (int i = 0; i < ARRAY_SIZE(foos); i++) {
printk("device %s pin %d\n", foos[i].port->name, foos[i].pin);
gpio_pin_configure_dt(&foos[i], GPIO_OUTPUT);
}

etc.

HTH,
Marti


Edge connectors and pin numbers

Frank Duignan
 

I'm working with the BBC Microbit V2 and can use the peripherals using the NRF port pin numbers etc.  These port pins are brought to an edge connector which numbers them completely differently.  There seems to be some support for this in the bbc_microbit_v2 dts file in the following form:
  edge_connector: connector {
compatible = "microbit,edge-connector";
#gpio-cells = <2>;
gpio-map-mask = <0xffffffff 0xffffffc0>;
gpio-map-pass-thru = <0 0x3f>;
gpio-map = <0 0 &gpio0 2 0>, /* P0 */
   <1 0 &gpio0 3 0>, /* P1 */
   <2 0 &gpio0 4 0>, /* P2 */
   <3 0 &gpio0 31 0>, /* P3 */
   <4 0 &gpio0 28 0>, /* P4 */
   <5 0 &gpio0 14 0>, /* P5 */
   <6 0 &gpio1 5 0>, /* P6 */
   <7 0 &gpio0 11 0>, /* P7 */
   <8 0 &gpio0 10 0>, /* P8 */
   <9 0 &gpio0 9 0>, /* P9 */
   <10 0 &gpio0 30 0>, /* P10 */
   <11 0 &gpio0 23 0>, /* P11 */
   <12 0 &gpio0 12 0>, /* P12 */
   <13 0 &gpio0 17 0>, /* P13 */
   <14 0 &gpio0 1 0>, /* P14 */
   <15 0 &gpio0 13 0>, /* P15 */
   <16 0 &gpio1 2 0>, /* P16 */
   <19 0 &gpio0 26 0>, /* P19 */
   <20 0 &gpio1 0 0>; /* P20 */
};
};

My question is: how do I get a binding to one/all of these i/o pins.  I've tried many many combinations of DT_ macros.  The following returns a non null value for "edge" but I can't figure out how to access the pins on that edge connector using the connector pin  numbering scheme.
struct device *edge; edge=DEVICE_DT_GET(DT_NODELABEL(edge_connector));
It's not a show stopper as I can revert to nordic pin numbering but it would be nice if the numbers in the C code corresponded to the label on the board.


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

Bolivar, Marti
 

Hi again Ilkka,

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

Thank you Marti for the reply.

The problem was indeed in the connection between the nRF52840DK and the external sensor. I watched your video, it was very good and informative.
I'm glad; thanks!

As I learned that the device will be initialized before execution is in application code, I realize we will have a problem with the driver in our own product. Our own board will have a sht31 sensor but it is behind a TCA9548A I2C switch, which means a device tree configuration like this:
&i2c0 {
tca9548a@71 ( TCA9548A@71 ) {
sht3xd@44 {
};
};
};

Can I stack the drivers like this?
Yes, you can, you just need to make sure the initialization priorities
are managed correctly so the init functions run in the following order:

i2c0 -> tca9548a -> sht3xd

You can control the initialization priorities with Kconfig options, but
the defaults should be OK for your use case.

See CONFIG_I2C_INIT_PRIORITY and CONFIG_SENSOR_INIT_PRIORITY
respectively for i2c0 and sht3xd.

If yes, to be able to use the available device drivers for the sensors
that are behind the I2C switch, I will need to implement the tca9548a
functionality to a device driver to make this work. Do you know are
there any example to use as a starting point?
I recently reviewed a TCA9546A driver, which seems similar to your
TCA9548A.

https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/i2c/i2c_tca9546a.c

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/i2c/ti%2Ctca9546a.html#dtbinding-ti-tca9546a

If the differences are superficial you may be able to extend the driver
to support "TCA954xA", i.e. both devices.

You may wish to contact the driver author if you want to collaborate.


Thanks again,
Ilkka
HTH,
Marti


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

@Hidastelija
 

Thank you Marti for the reply.

The problem was indeed in the connection between the nRF52840DK and the external sensor. I watched your video, it was very good and informative.

As I learned that the device will be initialized before execution is in application code, I realize we will have a problem with the driver in our own product. Our own board will have a sht31 sensor but it is behind a TCA9548A I2C switch, which means a device tree configuration like this:
&i2c0 {
  tca9548a@71 {
    sht3xd@44 {
    };
  };
};

Can I stack the drivers like this? If yes, to be able to use the available device drivers for the sensors that are behind the I2C switch, I will need to implement the tca9548a functionality to a device driver to make this work. Do you know are there any example to use as a starting point?

Thanks again,
Ilkka


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@lists.zephyrproject.org> 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
 

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@lists.zephyrproject.org> 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@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>


41 - 60 of 2712