users@lists.zephyrproject.org

Re: unable to build #west

Bolivar, Marti

#1927

You appear to be using Python 3.5. Zephyr requires Python 3.6.

I am surprised the build got this far along. You should have seen an
error about this earlier.

"Stefan Hristozov via Lists.Zephyrproject.Org"
<stefan.hristozov=aisec.fraunhofer.de@lists.zephyrproject.org> writes:

Show quoted text

When I try to build my project I get the following error:

$ west build -b native_posix
Traceback (most recent call last):
File "/home/stefan/.local/bin/west", line 11, in <module>
sys.exit(main())
File "/home/stefan/.local/lib/python3.5/site-packages/west/main.py", line 583, in main
args.handler(args, unknown)
File "/home/stefan/.local/lib/python3.5/site-packages/west/main.py", line 324, in ext_command_handler
command = spec.factory()
File "/home/stefan/.local/lib/python3.5/site-packages/west/commands/__init__.py", line 365, in __call__
mod = _commands_module_from_file(self.py_file)
File "/home/stefan/.local/lib/python3.5/site-packages/west/commands/__init__.py", line 333, in _commands_module_from_file
mod = _import_mod_from(mod_name, file)
File "/home/stefan/.local/lib/python3.5/site-packages/west/commands/__init__.py", line 330, in _import_mod_from
spec.loader.exec_module(mod)
File "<frozen importlib._bootstrap_external>", line 673, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/build.py", line 16, in <module>
from zephyr_ext_common import Forceable
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/zephyr_ext_common.py", line 17, in <module>
from runners.core import RunnerConfig
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/runners/__init__.py", line 24, in <module>
from runners import nrfjprog
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/runners/nrfjprog.py", line 86
f'refusing to guess which of {len(snrs)} '

It appears to be something with nrfjprog.py. Any ideas what can be wrong?

unable to build #west

Stefan Hristozov

#1926

When I try to build my project I get the following error:

$ west build -b native_posix
Traceback (most recent call last):
File "/home/stefan/.local/bin/west", line 11, in <module>
    sys.exit(main())
File "/home/stefan/.local/lib/python3.5/site-packages/west/main.py", line 583, in main
    args.handler(args, unknown)
File "/home/stefan/.local/lib/python3.5/site-packages/west/main.py", line 324, in ext_command_handler
    command = spec.factory()
File "/home/stefan/.local/lib/python3.5/site-packages/west/commands/__init__.py", line 365, in __call__
    mod = _commands_module_from_file(self.py_file)
File "/home/stefan/.local/lib/python3.5/site-packages/west/commands/__init__.py", line 333, in _commands_module_from_file
    mod = _import_mod_from(mod_name, file)
File "/home/stefan/.local/lib/python3.5/site-packages/west/commands/__init__.py", line 330, in _import_mod_from
    spec.loader.exec_module(mod)
File "<frozen importlib._bootstrap_external>", line 673, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/build.py", line 16, in <module>
    from zephyr_ext_common import Forceable
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/zephyr_ext_common.py", line 17, in <module>
    from runners.core import RunnerConfig
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/runners/__init__.py", line 24, in <module>
    from runners import nrfjprog
File "/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/scripts/west_commands/runners/nrfjprog.py", line 86
    f'refusing to guess which of {len(snrs)} '

It appears to be something with nrfjprog.py. Any ideas what can be wrong?

Re: Enable traces on Serial Wire Output #debugging

David K

#1925

And I forgot to include the FreeRTOS part:

#define configCPU_CLOCK_HZ                      ( SystemCoreClock )
#define configTICK_RATE_HZ                      ( 1000 )

Where SystemCoreClock is set to 16000000 by default.

Re: Enable traces on Serial Wire Output #debugging

David K

#1924

Hi there,

Thanks for the feedback and sorry for the delay. Here is my function that initializes the clock, it is called right after HAL_Init():

    // Configure the main internal regulator output voltage
    __IO uint32_t tmpreg;
    SET_BIT(RCC->APB1ENR, RCC_APB1ENR_PWREN);

    // Delay after an RCC peripheral clock enabling
    tmpreg = READ_BIT(RCC->APB1ENR, RCC_APB1ENR_PWREN);
    tmpreg = tmpreg;

    MODIFY_REG(PWR->CR1, PWR_CR1_VOS, (PWR_REGULATOR_VOLTAGE_SCALE3));

    // Delay after an RCC peripheral clock enabling
    tmpreg = READ_BIT(PWR->CR1, PWR_CR1_VOS);
    tmpreg = tmpreg;

    // Initializes the CPU, AHB and APB busses clocks
    RCC_OscInitTypeDef RCC_OscInitStruct = {0};
    RCC_OscInitStruct.OscillatorType      = RCC_OSCILLATORTYPE_HSI | RCC_OSCILLATORTYPE_HSE;
    RCC_OscInitStruct.HSEState            = RCC_HSE_ON;
    RCC_OscInitStruct.HSIState            = RCC_HSI_ON;
    RCC_OscInitStruct.HSICalibrationValue = 16;
    RCC_OscInitStruct.PLL.PLLState        = RCC_PLL_ON;
    RCC_OscInitStruct.PLL.PLLSource       = RCC_PLLSOURCE_HSE;
    RCC_OscInitStruct.PLL.PLLM            = 8;
    RCC_OscInitStruct.PLL.PLLN            = 144;
    RCC_OscInitStruct.PLL.PLLP            = RCC_PLLP_DIV2;
    RCC_OscInitStruct.PLL.PLLQ            = 6;
    HAL_StatusTypeDef hal_ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);
    if (hal_ret != HAL_OK)
    {
        return -ENOTSUP;
    }

    // Initializes the CPU, AHB and APB busses clocks
    RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
    RCC_ClkInitStruct.ClockType      = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2;
    RCC_ClkInitStruct.SYSCLKSource   = RCC_SYSCLKSOURCE_PLLCLK;
    RCC_ClkInitStruct.AHBCLKDivider  = RCC_SYSCLK_DIV1;
    RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
    RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
    // HAL_RCC_ClockConfig() ultimately calls HAL_InitTick()
    hal_ret = HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4);
    if (hal_ret != HAL_OK)
    {
        return -ENOTSUP;
    }

    // Initializes the peripherals clocks
    RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
    PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USART6 | RCC_PERIPHCLK_SDMMC1 | RCC_PERIPHCLK_CLK48;
    PeriphClkInitStruct.Usart6ClockSelection = RCC_USART6CLKSOURCE_HSI;
    PeriphClkInitStruct.Clk48ClockSelection  = RCC_CLK48SOURCE_PLL;
    PeriphClkInitStruct.Sdmmc1ClockSelection = RCC_SDMMC1CLKSOURCE_CLK48;
    hal_ret = HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);
    if (hal_ret != HAL_OK)
    {
        return -ENOTSUP;
    }

    // Configure the Systick IRQ for FreeRTOS timebase
    HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq() / 1000);
    // Configure the Systick
    HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

    // SysTick_IRQn interrupt configuration done in HAL_MspInit()

    SCB_EnableICache();
    SCB_EnableDCache();

    return 0;

Also, not sure if it is related but I have 2 Time bases:

STM32 uses timers (TIM6) to generate interruptions for HAL
FreeRTOS uses SysTick for OS functions

Thanks for your help, in parallel I will look into RTT alternative.

Re: when using zephyr with wolfssl -> error: 'CONFIG_NET_BUF_USER_DATA_SIZE' undeclared here

Johan Hedberg

#1923

Hi Stefan,

On 18. Mar 2020, at 11.08, Stefan Hristozov <stefan.hristozov@...> wrote:

In file included from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/net_l2.h:15,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/net_if.h:29,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/net_context.h:27,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/dns_resolve.h:17,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/socket.h:27,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/ext/lib/crypto/wolfssl/include/wolfssl/wolfcrypt/settings.h:1480,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/ext/lib/crypto/wolfssl/library/wolfcrypt/src/cpuid.c:27:
/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/buf.h:528:17: error: 'CONFIG_NET_BUF_USER_DATA_SIZE' undeclared here (not in a function); did you mean 'CONFIG_HEAP_MEM_POOL_SIZE'?
u8_t user_data[CONFIG_NET_BUF_USER_DATA_SIZE] __net_buf_align;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_HEAP_MEM_POOL_SIZE
[49/203] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/prep_c.c.obj

I already have contacted the wolfssl support. According to them it is an zephyr issue.

Have you enabled CONFIG_NET_BUF=y? That’s the only dependency for CONFIG_NET_BUF_USER_DATA_SIZE being defined.

Johan

when using zephyr with wolfssl -> error: 'CONFIG_NET_BUF_USER_DATA_SIZE' undeclared here

Stefan Hristozov

#1922

Hi
I want to use wolfssl in my zephyr project. My proj.conf looks like that:

CONFIG_ENTROPY_GENERATOR=y
CONFIG_TEST_RANDOM_GENERATOR=y

CONFIG_TINYCBOR=y
CONFIG_WOLFSSL=y


Unfortunately I get this error:

In file included from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/net_l2.h:15,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/net_if.h:29,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/net_context.h:27,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/dns_resolve.h:17,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/socket.h:27,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/ext/lib/crypto/wolfssl/include/wolfssl/wolfcrypt/settings.h:1480,
from /home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/ext/lib/crypto/wolfssl/library/wolfcrypt/src/cpuid.c:27:
/home/stefan/workspaces/zephyrproject/zephyrproject/zephyr/include/net/buf.h:528:17: error: 'CONFIG_NET_BUF_USER_DATA_SIZE' undeclared here (not in a function); did you mean 'CONFIG_HEAP_MEM_POOL_SIZE'?
u8_t user_data[CONFIG_NET_BUF_USER_DATA_SIZE] __net_buf_align;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_HEAP_MEM_POOL_SIZE
[49/203] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/prep_c.c.obj

I already have contacted the wolfssl support. According to them it is an zephyr issue. 

Best regards
Stefan

Question about the QSPI flash memory in the nrf52840 PCA10056 board #flash #nrf52840 #spi

henrique.guimaraes@...

#1921

Good afternoon, I'm a zephyr newbie, trying to implement it into an IoT project!

I'm aware that there is already a driver for the MX25 flash memory device in the nrf's dev kit, but I wasn't able to import it successfully to my code nor was I able to use it properly. I checked in the Menuconfig application and marked every box that had anything to do with QSPI and the NRF's flash drivers, but was still unsuccessful.

How to use the flash device driver properly? I know this is a very newbie question, but I want to do it the right way, not by brute forcing it.

Thanks.
Regards, Henrique Nascimento Guimarães. Electrical Engineer at VIRTURIAN.

Re: API meeting: agenda

Carles Cufi

#1920

Hi all,

A reminder that this week's API meeting is at 9AM PDT or 17h CET, so in 30 min from now.

Added items to the agenda:

- API stability documentation:
  - PR: https://github.com/zephyrproject-rtos/zephyr/pull/23527

- Devicetree generated files path
  - include/devicetree/gpio.h vs include/device/gpio.h

Carles

Show quoted text

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 16 March 2020 16:33
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Tomorrow's topics:

- RFC: Require system clock stability on startup:
  - https://github.com/zephyrproject-rtos/zephyr/issues/22758

- RFC: API change: Add I2C bus recovery API:
  - https://github.com/zephyrproject-rtos/zephyr/issues/23441

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

API meeting: agenda

Carles Cufi

#1919

Hi all,

Tomorrow's topics:

- RFC: Require system clock stability on startup:
  - https://github.com/zephyrproject-rtos/zephyr/issues/22758

- RFC: API change: Add I2C bus recovery API:
  - https://github.com/zephyrproject-rtos/zephyr/issues/23441

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

trying to add support for STM32F334 discovery

Daniel McBrearty <danielmcbrearty@...>

#1918

hello all,

I am new to Zephyr, just want to give it a try. I don't have any of the supported boards, but I have a STM32F334 Discovery which is close to several supported ones. I thought I'd see if I could add support by making a copy of STM32F3 Discovery. I also used some settings from Nucleo STM32F334R8 which seems to have a very similar chip.

I can build and flashing seems to work, but no blinking LED (the red user LED should be assigned to led0).

My build / flash output:

============

daniel@daniel-dev-laptop:~/work/zephyrproject/zephyr$ west build -p auto -b stm32f334_disco samples/basic/blinky/
[0/1] Re-running CMake...
-- Application: /home/daniel/work/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.2.99
-- Board: stm32f334_disco
-- Found west: /home/daniel/.local/bin/west (found suitable version "0.7.2", minimum required is "0.6.0")
-- Found toolchain: zephyr (/home/daniel/zephyr-sdk-0.11.2)
-- Loading /home/daniel/work/zephyrproject/zephyr/boards/arm/stm32f334_disco/stm32f334_disco.dts as base
Devicetree header saved to '/home/daniel/work/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h'
Parsing /home/daniel/work/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/daniel/work/zephyrproject/zephyr/build/zephyr/.config'
No change to configuration in '/home/daniel/work/zephyrproject/zephyr/build/zephyr/.config'
No change to Kconfig header in '/home/daniel/work/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h'
-- Cache files will be written to: /home/daniel/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: /home/daniel/work/zephyrproject/zephyr/build
[52/82] Building C object zephyr/drivers...les/drivers__serial.dir/uart_stm32.c.obj
/home/daniel/work/zephyrproject/zephyr/drivers/serial/uart_stm32.c:653:12: warning: 'uart_stm32_init' defined but not used [-Wunused-function]
653 | static int uart_stm32_init(struct device *dev)
| ^~~~~~~~~~~~~~~
/home/daniel/work/zephyrproject/zephyr/drivers/serial/uart_stm32.c:619:37: warning: 'uart_stm32_driver_api' defined but not used [-Wunused-const-variable=]
619 | static const struct uart_driver_api uart_stm32_driver_api = {
| ^~~~~~~~~~~~~~~~~~~~~
[78/82] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region Used Size Region Size %age Used
FLASH: 11160 B 64 KB 17.03%
SRAM: 4100 B 12 KB 33.37%
IDT_LIST: 120 B 2 KB 5.86%
[82/82] Linking C executable zephyr/zephyr.elf

daniel@daniel-dev-laptop:~/work/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/daniel/work/zephyrproject/zephyr/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-01340-ga0e8edc4e-dirty (2020-02-14-05:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J25M13 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.221011
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f3x.cpu hla_target little stm32f3x.cpu running

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800100c msp: 0x200005f8
Info : device id = 0x10016438
Info : flash size = 64kbytes
auto erase enabled
wrote 12288 bytes from file /home/daniel/work/zephyrproject/zephyr/build/zephyr/zephyr.hex in 0.750689s (15.985 KiB/s)

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800100c msp: 0x200005f8
verified 11160 bytes in 0.215123s (50.661 KiB/s)

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
shutdown command invoked

================

A few warnings but I think it is progrming the board OK - I see the interface LED flash and from the above, OCD seems to verify the code.

The only thing I wonder about is which include file to use in my dts file. At the moment I have:

==========

/*
* Copyright (c) 2017 I-SENSE group of ICCS
*
* SPDX-License-Identifier: Apache-2.0
*/

/dts-v1/;
#include <st/f3/stm32f334X8.dtsi>

/ {
model = "STMicroelectronics STM32F334DISCOVERY board";
compatible = "st,stm32f334discovery", "st,stm32f334";

chosen {
zephyr,console = &usart2;
zephyr,shell-uart = &usart2;
zephyr,sram = &sram0;
zephyr,flash = &flash0;
};

leds {
compatible = "gpio-leds";
red_led_U: led_3 {
gpios = <&gpiob 6 GPIO_ACTIVE_HIGH>;
label = "User LD3";
};
blue_led_D: led_6 {
gpios = <&gpiob 7 GPIO_ACTIVE_HIGH>;
label = "User LD6";
};
orange_led_L: led_4 {
gpios = <&gpiob 8 GPIO_ACTIVE_HIGH>;
label = "User LD4";
};
green_led_R: led_5 {
gpios = <&gpiob 9 GPIO_ACTIVE_HIGH>;
label = "User LD5";
};
};

gpio_keys {
compatible = "gpio-keys";
user_button: button {
label = "User";
gpios = <&gpioa 0 GPIO_ACTIVE_LOW>;
};
};

aliases {
led0 = &red_led_U;
sw0 = &user_button;
can-primary = &can1;
};
};

.

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

/* Set 6Kb of storage at the end of the 64Kb of flash */
storage_partition: partition@e800 {
label = "storage";
reg = <0x0000e800 0x00001800>;
};
};
};

==========

If I change the include file:

#include <st/f3/stm32f334.dtsi>

I now get a build error:

daniel@daniel-dev-laptop:~/work/zephyrproject/zephyr$ west build -p auto -b stm32f334_disco samples/basic/blinky/
[0/1] Re-running CMake...
-- Application: /home/daniel/work/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.2.99
-- Board: stm32f334_disco
-- Found west: /home/daniel/.local/bin/west (found suitable version "0.7.2", minimum required is "0.6.0")
-- Found toolchain: zephyr (/home/daniel/zephyr-sdk-0.11.2)
-- Loading /home/daniel/work/zephyrproject/zephyr/boards/arm/stm32f334_disco/stm32f334_disco.dts as base
stm32f334_disco.dts.pre.tmp:49.26-54.6: ERROR (unit_address_vs_reg): /soc/flash-controller@40022000/flash@8000000: node has a unit name, but no reg property
also defined at stm32f334_disco.dts.pre.tmp:409.9-419.3
stm32f334_disco.dts.pre.tmp:38.25-40.4: ERROR (unit_address_vs_reg): /memory@20000000: node has a unit name, but no reg property
ERROR: Input tree has errors, aborting (use -f to force output)
CMake Error at /home/daniel/work/zephyrproject/zephyr/cmake/dts.cmake:188 (message):
command failed with return code: 2
Call Stack (most recent call first):
/home/daniel/work/zephyrproject/zephyr/cmake/app/boilerplate.cmake:465 (include)
CMakeLists.txt:4 (include)

-- Configuring incomplete, errors occurred!

=====

and the CMakeError is:

/home/daniel/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: /home/daniel/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/lib/libc.a(lib_a-exit.o): in function `exit':
exit.c:(.text.exit+0x60): undefined reference to `_exit'
collect2: error: ld returned 1 exit status

====

I'm not sure if this the rason that I cannot seem to get blnky running on this board. Ideas? Thank you.

Daniel

Re: Enable traces on Serial Wire Output #debugging

Erwan Gouriou

#1917

Hi David,

I'm not a SWO user myself but I'm suspecting a clock set up issue.

On FreeRTOS, what was the clock configuration you were using ?

Cheers

Show quoted text

On Wed, 11 Mar 2020 at 12:13, Cufi, Carles <Carles.Cufi@...> wrote:

+ Erwan, Simen, Krzysztof, Andrzej

As mentioned in an earlier email (to which you replied without context so I had to start a new thread), RTT does work across reboots without problems, at least on Nordic platforms.

You wrote:

> Hi, thanks for your feedback ! I have a STM32F746ZE-based board and using west with jlink runner to flash it. I have the same issue when I reset the target via JLink Commander.

I do not know whether Zephyr does anything at all to the SWO pin connected to the debugger chip, and especially not on an STM32 platform (I copied Erwan who maintains these boards), but I might be wrong.

Carles

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks

Re: Enable traces on Serial Wire Output #debugging

William Fish

#1916
Edited

Hi all,
I use segger ozone to do debugging via RTT it's free download which may be helpful.
It does have swo trace and STM32 JTAG configuration inbuilt it may be something to consider.

But I work with Nordic silicon so not sure about the STM chips.

Billy..

Zephyr+BLE dongle: Maping a USB port and full stack inside

Imóveis Nacionais

#1915

Hi

This is my first contact with Zephyr project. My question is about good or wrong direction:

I need a BLE 5 "autonomous" dongle similar to BLED112 BLE 4 one. It maps a USB PORT on the computer and 100% hides BLE stack inside (no need for BLE stack on the host computer).

I have already a nRF52840 dongle. I am aware of the Zephyr HCI_USB sample but that sample warns reader that it needs BLUEZ on the host computer (sure because it needs to "speak HCI with the dongle"). So its seems not the right sample on the one handle but the interesting one in order to change it to reach my objective.

I am asking to experienced Zephyr users and programmers about the good direction, tips...

Thanks you

Alex

Re: Enable traces on Serial Wire Output #debugging

Carles Cufi

#1914

+ Erwan, Simen, Krzysztof, Andrzej

As mentioned in an earlier email (to which you replied without context so I had to start a new thread), RTT does work across reboots without problems, at least on Nordic platforms.

You wrote:

> Hi, thanks for your feedback ! I have a STM32F746ZE-based board and using west with jlink runner to flash it. I have the same issue when I reset the target via JLink Commander.

I do not know whether Zephyr does anything at all to the SWO pin connected to the debugger chip, and especially not on an STM32 platform (I copied Erwan who maintains these boards), but I might be wrong.

Carles

Show quoted text

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks

Re: Enable traces on Serial Wire Output #debugging

David K

#1913

Hi, thanks for your feedback ! I have a STM32F746ZE-based board and using west with jlink runner to flash it. I have the same issue when I reset the target via JLink Commander.

Re: Enable traces on Serial Wire Output #debugging

Carles Cufi

#1912

Hi there,

We don’t use SWO but RTT (also from Segger) and we don’t need to reset the JLinkRTTViewer/Logger when we reset the target.

Could it be that the way Zephr flashes and then resets the target (pin reset vs software reset) is different from FreeRTOS?

In theory this is all handled by the on-board debugger chip so it should make no difference.

Which board are you using?

Carles

Show quoted text

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks

Re: Enable traces on Serial Wire Output #debugging

David K

#1911

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks

Re: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Carles Cufi

#1910

Hi all,

Due to the switch to summer time in the US, the meeting today is at 17h CET/8AM PDT, so in 15min.

Regards,

Carles

Show quoted text

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 10 March 2020 15:36
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Just a friendly reminder that today's API meeting will be dedicated to
watchdog handling in Zephyr.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 05 March 2020 09:51
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to
watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a
temporary solution to what is ultimately a wider problem that requires
a discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the
CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and
document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and
- Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles

Re: API meeting next week: Focusing on watchdogs

Carles Cufi

#1909

Hi all,

Just a friendly reminder that today's API meeting will be dedicated to watchdog handling in Zephyr.

Thanks,

Carles

Show quoted text

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 05 March 2020 09:51
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to
watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a
temporary solution to what is ultimately a wider problem that requires a
discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the
CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and
document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles

Re: Opinions / experiences requested regarding choosing the right IoT embedded OS

Carles Cufi

#1908

Hi Noëlle,

Since I have participated in similar comparison efforts in the past, I thought I may post my two cents here.

Please do bear in mind the following disclaimers:

I work for a company that contributes to Zephyr
I have been involved with Zephyr for a number of years
My knowledge of other open source RTOS is limited to very basic use and examination of the codebase, as well as feedback from experience users
ThreadX is currently (still) proprietary and, AFAIK, there’s no way to inspect its source code

Trying to reply to your questions here:

Yes, there is quite a big difference. Without any hard numbers to support that statement (though those should be easy to collect from commit logs), I believe the situation is quite different for both projects

Contributions to Zephyr tend to come from silicon vendors (Intel, NXP, Nordic and others), from organizations that work closely with silicon vendors (Linaro) or from companies that use Zephyr as an RTOS in their products
Contributions to RIOT seem to come more often from Universities (FU Berlin, INRIA and HAW Hamburg mainly)
The Zephyr contributor base seems to be about 3x the one in RIOT (as per GitHub)
When it comes to advantages and disadvantages, I think the obvious advantage for Zephyr is that silicon vendors tend to know their ICs very well, which makes optimizing for their hardware is more easily achieved. I assume the advantage with more research-oriented contributions (i.e. for RIOT) is the possibility to get access to more innovative (proven or unproven) technologies in some cases

Well, the license is completely different. Zephyr uses the Apache v2.0 license, which is much more permissive than RIOT’s LGPLv2. IANAL, but with RIOT any changes you make to the RTOS codebase you will be obliged to contribute back to the community. With Zephyr anyone can take the codebase at any point in time and modify it at will without any obligations (except for attribution)
Don’t really know RIOT’s model today, but Zephyr uses proven technologies (Devicetree and Kconfig) to describe the hardware and configure the software. RIOT is actually currently working on integrating support for those very technologies in the RTOS, following Zephyr’s steps. Zephyr uses vendor-provided HAL libraries to implement drivers in most cases, which benefit from additional testing and maturity since those HALs are typically used in several other software products, not only Zephyr
I am not sure if there’s a clear, stated goal in terms of using the RTOS, but from experience the goal of the different companies using it seems to be to use it in actual, real-world products. In our case we use it as a building block for our SDK, which is the provided to our customers. Those customers end up making end-products which, by extension, run Zephyr
Yes, power management in particular is under heavy development. I cannot compare to RIOT since I don’t know how much it supports. There are also upcoming changes identified as important by the community such as better timeout handling in the kernel, multiple improvements to the various driver APIs and more.
Likely a few in some areas, but again, without an in-depth comparison it is difficult to share. There are likely some technical advantages to RIOT as well (especially in the area of networking, since RIOT seems to focus more on that). Typically things like userspace support, multiple architecture support (including Xtensa and now Cortex-A), TEE support are features that are not common in other RTOS outside Zephyr.

Thanks,

Carles

Show quoted text

From: users@... <users@...> On Behalf Of Noëlle Clement via Lists.Zephyrproject.Org
Sent: 09 March 2020 13:21
To: users@...
Cc: users@...
Subject: [Zephyr-users] Opinions / experiences requested regarding choosing the right IoT embedded OS

Hi users part of the Zephyr project!

My team is looking into the possibility to transition from a bare-metal application to an OS for our embedded controllers. We develop IoT and wireless sensors solutions, for which we have also developed our own controller and platform. A lot of in-house development and maintenance!

Would some of you be willing to answer some questions about why Zephyr OS would be a good choice for us? (The main comparison right now is between Zephyr Project, RIOT-OS and ThreadX)

To give a summary of the reasons for even looking into a more advanced architecture: there are a few features common in embedded (IoT) OS' that would be very convenient for future development of the controller. Things like hardware abstraction and task scheduling are very welcome. In general we want to make it easier to maintain the code (pre- and post release) and decrease time-to-market for new controller versions (with new/upgraded hardware modules). A common requirement that also applies to us are the resource constraints and the ultra low power features (we need to be able to use the low power modes for the STM32L151CC, but that can be added in the port). Real-time isn’t a priority for us at all, although the priority (pre-emptive)-based scheduling would be very useful.

The controller is part of the in-house developed IoT system, which currently is mostly used for Smart Waste and Smart Silo products (detecting fill rates in both).

A few questions that popped up during my own research on this (mostly about Zephyr vs RIOT):

1) Are there advantages / disadvantages to the different kinds of groups supporting and contributing to Zephyr vs RIOT (US/Europe, industry/academic, ?/?)

2) Are there advantages / disadvantages I should be aware of for using the OS commercially (compared to RIOT)

3) Are there advantages / disadvantages to the hardware abstraction method Zephyr OS uses (DTS vs HAL?)

4) What is the goal of the development of the OS (use by industry, academic, educational use, hobby projects)?

5) Any technical limitations I should be aware of?

6) Any technical advantages (over RIOT)?

Any help is really appreciated!

All the best,

Noelle