|
Zephyr networking testing in LAVA, was: Re: Network forum agenda
Paul Sokolovsky
Hello,
On Mon, 6 Apr 2020 21:44:27 +0300 "Paul Sokolovsky via lists.zephyrproject.org" <paul.sokolovsky=linaro.org@...> wrote: [] If there is time, I'd like to share some progress on setting up CII appreciate being able to present my work quickly and the discussion of testing matters which followed. As it was just a quick spoken presentation, I'd like to share a few links showing more details, with the idea to keep wider community in loop of testing efforts around Zephyr. So, in this work Linaro LITE team uses the LAVA system (Linaro Automation and Validation Architecture), which is an open source project at https://www.lavasoftware.org/ (we run a particular deployment at https://lite.validation.linaro.org/). How it works is that we build Zephyr tests/samples in Jenkins (using the standard Zephyr "sanitycheck" tool), then submit binaries to LAVA, accompanied by a "test job definition", which is a YAML file like https://lite.validation.linaro.org/scheduler/job/960800/multinode_definition#defline1 . The job is then being run, with log of interaction recorded and analyzed for success/failure. In this case it's a networking test which involves 2 "nodes": a DUT (device under test) per se (FRDM-K64F board): https://lite.validation.linaro.org/scheduler/job/960800.0 and a docker container representing "a host": https://lite.validation.linaro.org/scheduler/job/960800.1#L56 . Here, the actual test interaction happens on the host, which starts with easy-pinging a device, then pings more with full Ethernet frames, then does a "poorman's flood ping" of pinging 1000 times with full packets and 10ms interval. All these actions are encoded in the YAML definition and are easily reconfigurable. LAVA checks that individual actions outcome satisfies success criteria and records overall results, e.g. https://lite.validation.linaro.org/results/960801/0_ping . The biggest value of such a system would come from early notifications of failures, and ability to compare results over time. The best ways to achieve that is so far under investigation (the whole work is largely a prototype at this stage). As discussed yesterday, we all by now should be aware that "Zephyr testing" bastion is being stormed by multiple stakeholders in different ways, and I just wanted to share Linaro's approach and progress with wider community. While the primary drivers for this works are requirements of our members interested in Zephyr, who already adopted the LAVA system, the work itself is open-source, results are public, and hopefully useful for a wider Zephyr community. (And different teams working on testing definitely should reuse results of each other's work, and further the best practices for making Zephyr more testable and quality-assured). Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|||||||||||||
|
|
|||||||||||||
|
API meeting cancelled today
Carles Cufi
Hi all,
Due to several people being away and needing a bit more time to discuss some of the items offline I am cancelling this week's API meeting. Next week the meeting will take place as usual. Thanks, Carles
|
|||||||||||||
|
|
|||||||||||||
|
Re: Network forum agenda
Paul Sokolovsky
Hello,
On Mon, 06 Apr 2020 15:01:40 +0300 "Jukka Rissanen" <jukka.rissanen@...> wrote: Hi all,Thanks for the reminder, appreciated! Preliminary agenda:Will there be any status update on TCP2? I see recently there're multiple patches from different developers, so would be nice to hear a summary of where it stands and if it's ready to be explored by wider community. If there is time, I'd like to share some progress on setting up CI for network testing with real hardware, on which I've been working last time. Cheers, -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|||||||||||||
|
|
|||||||||||||
|
Network forum agenda
Jukka Rissanen
Hi all,
There is a network forum meeting tomorrow 7 Apr at 8AM PDT / 17.00 CET https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#networking-forum Preliminary agenda: * Network stack status * k_timeout_t changes in networking stack. Initial PR can be found at https://github.com/zephyrproject-rtos/zephyr/pull/24071 * Review help needed for GSM 07.10 mux PR at https://github.com/zephyrproject-rtos/zephyr/pull/23422 If you have anything you want to discuss, please let me know. Cheers, Jukka
|
|||||||||||||
|
|
|||||||||||||
|
Re: Assert in sched.c
Boie, Andrew P
Check for stack overflows, enable CONFIG_STACK_SENTINEL if you don't have an MPU.
From: users@... <users@...>
On Behalf Of erik.johnson@...
I'm running v2.1.99-ncs1, which is a downstream minimal fork provided by Nordic Semiconductor. For the purposes of this bug, I can't find any difference between their code and the upstream Zephyr source.
Anyway, I'm having an assertion in the tick sleep code. It seems that the assert is trying to make sure the resuming context isn't marked as "suspended", but somehow that assertion is getting hit...
I'm unfortunately just not familiar enough with the kernel yet to know what's going on, so I was hoping to get some help on it. In particular, if there are any kind of known "gotcha" cases that would cause this assertion.
I'm happy to provide as much information as I can, with the caveat that part of the source code impacted by this is not available: we're using a binary library from Nordic Semiconductor that runs code inside of a thread we're creating in
our own source code.
Here's the assertion in the debug log: ASSERTION FAIL [!z_is_thread_state_set(_kernel.current, ((1UL << (4))))] @ ZEPHYR_BASE/kernel/sched.c:1096
[00:05:05.932,373] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000457 r2/a3: 0x00000001 [00:05:05.941,314] <err> os: r3/a4: 0x00063757 r12/ip: 0x00000030 r14/lr: 0x00054c2b [00:05:05.950,256] <err> os: xpsr: 0x61040000 [00:05:05.955,657] <err> os: s[ 0]: 0x00000001 s[ 1]: 0x00000001 s[ 2]: 0x00000001 s[ 3]: 0x00000001 [00:05:05.966,400] <err> os: s[ 4]: 0x00000001 s[ 5]: 0x00000001 s[ 6]: 0x00000001 s[ 7]: 0x00000001 [00:05:05.977,172] <err> os: s[ 8]: 0x00000001 s[ 9]: 0x00000001 s[10]: 0x00000001 s[11]: 0x00000001 [00:05:05.987,915] <err> os: s[12]: 0x00000001 s[13]: 0x00000001 s[14]: 0x00000001 s[15]: 0x00000001 [00:05:05.998,657] <err> os: fpscr: 0x00000000 [00:05:06.004,028] <err> os: Faulting instruction address (r15/pc): 0x00058806 [00:05:06.012,176] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0 [00:05:06.020,111] <err> os: Current thread: 0x200276c4 (unknown) [00:05:06.027,099] <err> fatal_error: Resetting system
|
|||||||||||||
|
|
|||||||||||||
|
Assert in sched.c
erik.johnson@...
I'm running v2.1.99-ncs1, which is a downstream minimal fork provided by Nordic Semiconductor. For the purposes of this bug, I can't find any difference between their code and the upstream Zephyr source.
There's no tag for it, but we're using the nRF9160 from Nordic. Anyway, I'm having an assertion in the tick sleep code. It seems that the assert is trying to make sure the resuming context isn't marked as "suspended", but somehow that assertion is getting hit...
I'm unfortunately just not familiar enough with the kernel yet to know what's going on, so I was hoping to get some help on it. In particular, if there are any kind of known "gotcha" cases that would cause this assertion.
I'm happy to provide as much information as I can, with the caveat that part of the source code impacted by this is not available: we're using a binary library from Nordic Semiconductor that runs code inside of a thread we're creating in our own source code.
The function being used is k_sleep(), and the function is successfully used a number of times. But, as soon as I do a particular other thing with a download client, I suddenly get the assert. Running the additional code will successfully do its stuff without issues a few times, but eventually the condition gets hit. As far as I can tell, it's not a race condition but rather based on some sort of state in the Nordic library. Here's the assertion in the debug log:
ASSERTION FAIL [!z_is_thread_state_set(_kernel.current, ((1UL << (4))))] @ ZEPHYR_BASE/kernel/sched.c:1096
[00:05:05.932,373] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000457 r2/a3: 0x00000001
[00:05:05.941,314] <err> os: r3/a4: 0x00063757 r12/ip: 0x00000030 r14/lr: 0x00054c2b
[00:05:05.950,256] <err> os: xpsr: 0x61040000
[00:05:05.955,657] <err> os: s[ 0]: 0x00000001 s[ 1]: 0x00000001 s[ 2]: 0x00000001 s[ 3]: 0x00000001
[00:05:05.966,400] <err> os: s[ 4]: 0x00000001 s[ 5]: 0x00000001 s[ 6]: 0x00000001 s[ 7]: 0x00000001
[00:05:05.977,172] <err> os: s[ 8]: 0x00000001 s[ 9]: 0x00000001 s[10]: 0x00000001 s[11]: 0x00000001
[00:05:05.987,915] <err> os: s[12]: 0x00000001 s[13]: 0x00000001 s[14]: 0x00000001 s[15]: 0x00000001
[00:05:05.998,657] <err> os: fpscr: 0x00000000
[00:05:06.004,028] <err> os: Faulting instruction address (r15/pc): 0x00058806
[00:05:06.012,176] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:05:06.020,111] <err> os: Current thread: 0x200276c4 (unknown)
[00:05:06.027,099] <err> fatal_error: Resetting system
|
|||||||||||||
|
|
|||||||||||||
|
API meeting: agenda
Carles Cufi
Hi all,
Note: Today we go back to our usual 9AM PDT / 18h CET. Today's topics: - Template to document a driver implementation: discussion as to what it should include - API Terminology refinements - PR https://github.com/zephyrproject-rtos/zephyr/pull/23867 - onoff service refactor conclusion - PR https://github.com/zephyrproject-rtos/zephyr/pull/23601 - async notify service redesign conclusion - PR https://github.com/zephyrproject-rtos/zephyr/pull/23898 Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit Regards, Carles
|
|||||||||||||
|
|
|||||||||||||
|
FW: Zephyr CMake package / find_package(Zephyr)
Carles Cufi
From: announce@... <announce@...>
On Behalf Of Rasmussen, Torsten via Lists.Zephyrproject.Org
Hi All,
A new way of including boilerplate code has been introduced with this PR https://github.com/zephyrproject-rtos/zephyr/pull/23054
This means a simple Zephyr application now looks as: # Find Zephyr. This also loads Zephyr's build system.
cmake_minimum_required(VERSION 3.13.1) find_package(Zephyr HINTS $ENV{ZEPHYR_BASE}) project(my_zephyr_app)
This means that developers no longer need to set ZEPHYR_BASE in their environment, but can let CMake find the Zephyr base using find_package().
For this to work, it is necessary to execute a new west command: `west zephyr-export` This command only needs to be executed once, for example after a `west init`
All samples in Zephyr repository has been updated to use: find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})
To all downstream user having own Zephyr-based applications, you may switch to the new find_package() method.
Note: this new feature is fully compatible with the old `include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake)` design, but if you keep using the old design, then it is still required to `source zephyr-env.sh` or execute `zephyr-env.cmd`.
Using the new `find_package()` remove the need to `source zephyr-env.sh`.
It is still possible to set the environment variable ZEPHYR_BASE, and doing so will overwrite the CMake package search functionality in Zephyr.
For more information on the new desgin, re-read the getting started guide (as the latest docs has not yet been build, this is a ): https://docs.zephyrproject.org/latest/getting_started/index.html https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html
Best regards
Torsten
|
|||||||||||||
|
|
|||||||||||||
|
Re: Changing partitions in a DTS overlay
Hi Martin:
Excellent, thank you. The bit I missed was the correct syntax for /delete-node/
I put the following 3 lines just before &flash0
/delete-node/ &slot0_partition; /delete-node/ &slot1_partition; /delete-node/ &scratch_partition;
After this the other changes work correctly.
Lawrence King Principal Developer +1(416)627-7302
From: Martin Kozusky <news@...>
Hi,
/delete-node/ &storage_partition;
Martin
Dne 27.03.2020 v 22:33 Lawrence King napsal(a):
|
|||||||||||||
|
|
|||||||||||||
|
The question of nRF52810 support in HCI_UART
Hsu, Hanyu <Hanyu.Hsu@...>
Hi Sir,
We design the nRF52810 in our system, and plans to use BlueZ to control the BLE device. So, we implement the HCI_UART in nRF52810, but we got link fail when tried to link the peripheral.
We download the zephyr version 2.0.0
Two questions.
Does it mean the nrf52810 not support in HCI_UART example?
But we can link fail w/ peripheral device. For get precision 32K, we modified the 32K setting to synthesized, but we got the hci0 down. We tried to use nRF52-DK to verify it and we got the same result when 32K setting to synthesized. The question is does 32K synthesized setting work?
|
|||||||||||||
|
|
|||||||||||||
|
Jan Van Winkel <jan.van_winkel@...>
Hi Lucas, You can use native_posix with NVS, the NVS sample (samples/subsys/nvs) almost works out of the box. So I would have a look at the sample code and use it as a base line. Steps (tested against latest master (b173c177db7f) on a Ubuntu host):
Jan zephyr/build$ ./zephyr/zephyr.elf *** Booting Zephyr OS build zephyr-v2.2.0-829-gb173c177db7f *** [00:00:00.000,000] <inf> fs_nvs: 3 Sectors of 4096 bytes [00:00:00.000,000] <inf> fs_nvs: alloc wra: 0, ff0 [00:00:00.000,000] <inf> fs_nvs: data wra: 0, 0 No address found, adding 192.168.1.1 at id 1 No key found, adding it at id 2 No Reboot counter found, adding it at id 3 Id: 4 not found, adding it Longarray not found, adding it as id 5 Reboot counter history: ...0 Oldest reboot counter: 0 Rebooting in ...5...4...3...2...1 Failed to reboot: spinning endlessly... ^C Stopped at 3.490s zephyr/build$ ./zephyr/zephyr.elf *** Booting Zephyr OS build zephyr-v2.2.0-829-gb173c177db7f *** [00:00:00.000,000] <inf> fs_nvs: 3 Sectors of 4096 bytes [00:00:00.000,000] <inf> fs_nvs: alloc wra: 0, fc0 [00:00:00.000,000] <inf> fs_nvs: data wra: 0, a1 Id: 1, Address: 192.168.1.1 Id: 2, Key: ff fe fd fc fb fa f9 f8 Id: 3, Reboot_counter: 1 Id: 4, Data: DATA Id: 5, Longarray: 0 1 2 3 4 5 6 7 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f Reboot counter history: ...1...0 Oldest reboot counter: 0 Rebooting in ...5...4...3...2...1 Failed to reboot: spinning endlessly... ^C Stopped at 1.980s
On Fri, Mar 27, 2020 at 6:29 PM Lucas Peixoto <lucaspeixotoac@...> wrote: Another option would be to use NVS with QEMU, but I think that in QEMU doesn't work too. What steps I would follow to try to make native_posix or qemu_x86 support nvs?
|
|||||||||||||
|
|
|||||||||||||
|
Re: Changing partitions in a DTS overlay
Martin Kozusky
Hi,
this is how my overlay looks like (and it's working) - I wanted to make storage partition smaller and add 2 more partitions. Since I didn't change image0,1 and scratch size, I didn't have to use overlay when compiling mcuboot. Changing slot0 and 1 size should be similar, but I think this time you will have to use the overlay also when compiling mcuboot. /delete-node/
&storage_partition;
&flash0 { partitions { compatible = "fixed-partitions"; info_partition: partition@7a000 { label = "info"; reg = <0x0007a000 0x00001000>; }; nvs_partition: partition@7b000 { label = "nvs"; reg = <0x0007b000 0x00002000>; }; storage_partition: partition@7d000 { label = "storage"; reg = <0x0007d000 0x00003000>; }; }; }; Martin
Dne 27.03.2020 v 22:33 Lawrence King
napsal(a):
|
|||||||||||||
|
|
|||||||||||||
|
Changing partitions in a DTS overlay
Dear all:
I am trying to change the partition table from the default as defined in the board file inside Zephyr to a slightly different configuration. Obviously I could do this by editing the file in the zephyr tree but this has the disadvantage that I have to redo the change each time I upgrade the kernel. Hence I would like to make the change in the overlay. Here is what I did in the overlay:
&flash0 { /* * For more information, see: * http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions */ partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>;
boot_partition: partition@0 { label = "mcuboot"; reg = <0x000000000 0x0000C000>; }; /* slot0_partition: partition@c000 { label = "image-0"; reg = <0x0000C000 0x000067000>; }; slot1_partition: partition@73000 { label = "image-1"; reg = <0x00073000 0x000067000>; }; scratch_partition: partition@da000 { label = "image-scratch"; reg = <0x000da000 0x0001c000>; }; */ slot0_partition: partition@c000 { label = "image-0"; reg = <0x0000C000 0x000075800>; }; slot1_partition: partition@81800 { label = "image-1"; reg = <0x00081800 0x000075800>; };
/* * The flash starting at 0x000f8000 and ending at (32kB) * 0x000fffff is reserved for use by the application. */
/* Storage partition will be used by FCB/NFFS/NVS if enabled. */ storage_partition: partition@f8000 { label = "storage"; reg = <0x000f8000 0x00008000>; }; }; };
As you can see I commented out the definitions of slot0, slot1 and scratch, then I added in new definitions for slot0 and slot1. When I attempt to compile this I get a fatal error:
nrf52840_mdk.dts.pre.tmp:546.50-549.19: ERROR (duplicate_label): /soc/flash-controller@4001e000/flash@0/partitions/partition@81800: Duplicate label 'slot1_partition' on /soc/flash-controller@4001e000/flash@0/partitions/partition@81800 and /soc/flash-controller@4001e000/flash@0/partitions/partition@73000 ERROR: Input tree has errors, aborting (use -f to force output)
The device tree compile didn’t mind changing the size of the slot0 partition, but it hated changing the base address of the slot1 partition.
I tried leaving the partition address at 73000, it compiles, but the device tree compiler complains “warning: unit-address and first reg (0x81800) don't match for partition@73000” and mcuboot complains “<wrn> mcuboot: Cannot upgrade: slots don't have same amount of sectors”. I also tried many variations on adding /delete-node/ and /delete-property/ in front of the definitions but this just gave me other errors.
Obviously I am going about this incorrectly. What is the right way to change the partition table in a device tree overlay?
Lawrence King Principal Developer Connected Transport Market Unit +1(416)627-7302
CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.
|
|||||||||||||
|
|
|||||||||||||
|
Re: tracing using HW support (ETM, ARM CoreSight)
Kevin Townsend
Hi Roman, My request is - If someone has any info regarding this matter, namely - how to do this, examples, info, - please share it. It isn't something I've used myself, but you can access TRACE functionality from JLinkExe on the command-line with an appropriate J-Trace debugger. Checking the list of commands from the tool, I can see: ---- TRACE ----------- TClear TRACE - Clear buffer TSetSize TRACE - Set Size of trace buffer TSetFormat TRACE - SetFormat TSR TRACE - Show Regions (and analyze trace buffer) TStart TRACE - Start TStop TRACE - Stop Another platform-neutral option is the free (if you have a supported debugger, which the J-Trace is) Ozone graphical debug tool from Segger, which you can use to point to a Zephyr image, and then access the trace features from the Tools > Trace Settings menu item, setting the source to Trace Pins. Best regards, Kevin
|
|||||||||||||
|
|
|||||||||||||
|
tracing using HW support (ETM, ARM CoreSight)
roman.fedoryak@...
Hello all,
We are developing SW for medical devices. Obviously we have specific requirements for code certification - we need to do detailed unit tests, gather Code Coverage, etc. We do this with instruction trace features supported by ETM (embedded trace macrocell) from ARM CoreSight Architecture of Cortex microcontrollers, and TraceData pins for data transmission. This feature is supported by Segger HW debuggers and also by "major" IDEs like Keil's MDK-ARM. But I have not found any notes about such sort of tracing in Zephyr's docs. Averything I see is discussions about Segger SystemView, RTT console - yes, these are tracing tools, but only SW tracing, with no ETM involvement. My request is - If someone has any info regarding this matter, namely - how to do this, examples, info, - please share it. Best Regards, Roman Fedoryak.
|
|||||||||||||
|
|
|||||||||||||
|
Re: for board nucleo_f302r8, where "stm32f3xx.h" header file needs to be?
#stm32
MaxMn
Bingo! Thanks, Erwan I'm watching now how "west update" is fetching repositories. stm32f3xx.h (and a lot more) are in https://github.com/zephyrproject-rtos/hal_stm32/tree/master/stm32cube/stm32f3xx/soc Am Di., 24. März 2020 um 22:52 Uhr schrieb Erwan Gouriou <erwan.gouriou@...>:
|
|||||||||||||
|
|
|||||||||||||
|
Re: for board nucleo_f302r8, where "stm32f3xx.h" header file needs to be?
#stm32
Erwan Gouriou
You might just miss a "west update".
Le mar. 24 mars 2020 à 19:19, Yannis Damigos <giannis.damigos@...> a écrit : Hi,
|
|||||||||||||
|
|
|||||||||||||
|
Re: for board nucleo_f302r8, where "stm32f3xx.h" header file needs to be?
#stm32
Yannis Damigos
Hi,
toggle quoted messageShow quoted text
just tried it and it works fine on my system. are the modules installed? You could check using: west list | grep hal_stm32 Best regards, Yannis
On 3/24/20 5:41 PM, MaxMn via Lists.Zephyrproject.Org wrote:
I'm running
|
|||||||||||||
|
|
|||||||||||||
|
for board nucleo_f302r8, where "stm32f3xx.h" header file needs to be?
#stm32
MaxMn
I'm running ~/zephyrproject/zephyr$ west build -p auto -b nucleo_f302r8 samples/basic/blinky What is the proper location of stm32f3xx.h? I got it within so called "STM32Cube MCU Package for STM32F3 Series" STM32CubeF3 (https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubef3.html) -- west build: building application [1/115] Preparing syscall dependency handling[7/115] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj FAILED: zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj ccache /home/user/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=zephyr-v2.2.0-561-g67e4ccbc5161 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../kernel/include -I../arch/arm/include -I../include -Izephyr/include/generated -I../soc/arm/st_stm32/stm32f3 -I../drivers -isystem ../lib/libc/minimal/include -isystem /home/user/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/include -isystem /home/user/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/include-fixed -Os -imacros/home/user/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -imacros/home/user/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-address-of-packed-member -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/user/zephyrproject/zephyr/samples/basic/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/user/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/user/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -c /home/user/zephyrproject/zephyr/arch/arm/core/offsets/offsets.c In file included from ../include/arch/arm/aarch32/cortex_m/cmsis.h:17, from ../arch/arm/include/aarch32/cortex_m/stack.h:23, from ../arch/arm/include/kernel_arch_data.h:33, from /home/user/zephyrproject/zephyr/arch/arm/core/offsets/offsets_aarch32.c:26, from /home/user/zephyrproject/zephyr/arch/arm/core/offsets/offsets.c:12: ../soc/arm/st_stm32/stm32f3/soc.h:24:10: fatal error: stm32f3xx.h: No such file or directory 24 | #include <stm32f3xx.h> | ^~~~~~~~~~~~~ compilation terminated. ninja: build stopped: subcommand failed.
|
|||||||||||||
|
|
|||||||||||||
|
python tools when conda virtual environments are used
MaxMn
I'm using conda virtual environments (conda 4.8.0rc0, installed within miniconda in my case). To get west build working, I had to activate the intended conda environment prior to (re-)installing west and tools from requirements.txt. conda create --clone base --name zephyr source activate zephyr pip install west pip install -r ~/zephyrproject/zephyr/scripts/requirements.txt I also had to edit ~/zephyrproject/zephyr/build/CMakeCache.txt and point PYTHON_EXECUTABLE:FILEPATH and WEST:FILEPATH to respective executables under in the right conda env. Maybe it wouldn't be necessary if didn't forget to activate the conda env before installing west and requirements first time. I wonder if conda virtual envs are worth mentioning in Getting Started. And I can move on to troubleshooting missing stm32f3xx.h for board nucleo_f302r8 ../soc/arm/st_stm32/stm32f3/soc.h:24:10: fatal error: stm32f3xx.h: No such file or directory 24 | #include <stm32f3xx.h>
|
|||||||||||||
|
|
