Date   

Re: is using of arm toolchain from developer.arm.com feasible?

Kumar Gala
 

No need to worry about dirty, its just because we have our own patches to crosstool-ng.

You can use developer.arm.com if you want, take a look here for the instructions on 'GNU ARM Embedded':

https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html?highlight=toolchain

On Mar 24, 2020, at 6:29 AM, MaxMn via Lists.Zephyrproject.Org <anzeigen.21423+zephyr=googlemail.com@lists.zephyrproject.org> wrote:

After installing zephyr-sdk-0.11.2, I checked arm g++ version:
arm-zephyr-eabi-g++ (crosstool-NG 1.24.0.37-3f461da-dirty) 9.2.0
Why "dirty"? Should I worry?

How feasible is it to use the a toolchain direct from developer.arm.com (1) when buliding zephyr projects?

More general, why vendors tend to supply their own toolchain builds? (My target is STM32. ST goes way "further" and supplies with their STM32CubeIDE old GNU Tools for STM32 7-2018-q2-update.20190328-1800 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907])

(1) https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads


is using of arm toolchain from developer.arm.com feasible?

MaxMn
 

After installing zephyr-sdk-0.11.2, I checked arm g++ version:
arm-zephyr-eabi-g++ (crosstool-NG 1.24.0.37-3f461da-dirty) 9.2.0
Why "dirty"? Should I worry?

How feasible is it to use the a toolchain direct from developer.arm.com (1) when buliding zephyr projects?

More general, why vendors tend to supply their own toolchain builds? (My target is STM32. ST goes way "further" and supplies with their STM32CubeIDE old GNU Tools for STM32 7-2018-q2-update.20190328-1800 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907])


is using of arm toolchain from developer.arm.com feasible?

MaxMn
 

After installing zephyr-sdk-0.11.2, I checked arm g++ version:
arm-zephyr-eabi-g++ (crosstool-NG 1.24.0.37-3f461da-dirty) 9.2.0
Why "dirty"? Should I worry?

How feasible is it to use the a toolchain direct from developer.arm.com (1) when buliding zephyr projects?

More general, why vendors tend to supply their own toolchain builds? (My target is STM32. ST goes way "further" and supplies with their STM32CubeIDE old GNU Tools for STM32 7-2018-q2-update.20190328-1800 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907])


API meeting: agenda

Carles Cufi
 

Hi all,

Note: This is the last week where the meeting takes place at 17h CET. Next week we go back to 18h CET.

Today's topics:

- How to document standalone drivers like the enc28j60 (Piotr)

- Upgrade the hwinfo API to stable
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23661

- RTC API proposal
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526/commits/2880ee02b0f2fd91d897d8a11a4cbdefe87a19b0

- Naming in the async_notify module
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23601

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


Re: unable to build #west

Bolivar, Marti
 

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:

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
 

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
 

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
 

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
 

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
 

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

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
 

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

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

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

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
 

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


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

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
 

+ 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

David K
 

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
 

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

 

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

781 - 800 of 2707