Date   

Application build from multiple libs.

tomasz.sleboda@...
 

Hi,
I'm trying to port our application to run under Zephyr.
Application itself is build as a set of different libraries (e.g. libComm, libMeasurements...and libapp).
All libs are compiled and linked together with build success, but.. application crashes.

Digging deeper into compile process sims that objects under libapp target has proper includes, defines and compile options.
Rest of objects are wrongly compiled.

Is there way to populate build options from 'app' target to other libs (subcomponents) and objects via cmake functions?

-Tomasz S.


NetworkING Forum Agenda

Lubos, Robert
 

Hi all,

 

There is a networking forum tomorrow Tue 6 July at 8AM PST / 17.00 CEST.

 

Currently there are no major topics on the agenda. We’re going to briefly discuss networking stack maintenance transition from Jukka to me. Please let me know if there is any other topic that you would like to add to the agenda for tomorrow.

 

Meeting notes:

https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0

 

Shared Folder:

https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

 

Teams meeting:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

 

Regards,
ROBERT LUBOS | Senior Firmware Engineer
M +48 504 088 482 | Krakow, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 


Zephyr SDK 0.13.0-rc1 available

Kumar Gala
 

Hi all,

We’ve release the first release candidate for the SDK 0.13.0. The main changes in these release are support for ARC64, Qemu 6.0.0, OpenOCD, and some newlib updates/fixes.

SDK 0.13.0-rc1 can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.13.0-rc1

Please download and try things out and report any issues.

Changes since the last release:

• general:
- Added support for ARC64. NOTE: GDB isn't currently supported for ARC64.

• qemu:
- Updated to QEMU 6.0.0
- Added arc64 support. NOTE: this update ARC support replaces the machine (-M simhs) with (-M virt). This change will require updates to boards/arc/qemu_arc/board.cmake in Zephyr to match.
- Pull in fixes from upstream for:
hw/arm: Fix modelling of SSE-300 TCMs and SRAM

• gcc:
- Update to gcc 10.3 release
- Added support for ARC64
- Removed libgcc transactional memory clone registry support
- Fixed incorrect build specs for libstdc++ nano variant. The libstdc++ nano variant, which is used with newlib-nano, is now built with -fno-exceptions to reduce compiled binary size.

• binutils:
- Updated to add support for ARC64

• newlib:
- Updated to add support for ARC64
- Added multithreading support

• openocd:
- Update to upstream 20210630 snapshot

• crosstool-ng:
- sync with upstream. Upstream now supports newlib-nano so we drop our Zephyr specific updates. This also pulls in gcc-10.3 and initial support for ARC64.

• yocto:
- Update to yocto 3.2.3 baseline. This is in prep to support building qemu-6.0.0

- k


Re: Slack Invite

Kumar Gala
 

On Jul 2, 2021, at 5:21 AM, Daniel O <dsoliveira@criticalsoftware.com> wrote:

Hi there,

I'm with the same problem I have also tried with Google login.
It seems the public link is unavailable


Adafruit feather sense Internal Clock

Dimitrios Kosyvas <kosyvas14828@...>
 

Hello 

I also have the adafruit feather sense board  with the nrf52840 processor and i am using zephyr to program it .The only way to work is for me to enable the  32k internal RC Oscillator by writing 

# 32kHz clock source - necessary for Adafruit Sense (Internal Clock!)
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y


I was wondering if the reason for not working is that zephyr RTOS needs the RTC .

Could you explain why the initialization  of the internal 32k clock  is necessary ?


Thanks 

Dimitris Kosyvas



Re: Slack Invite

alohre@...
 

The slack invite is mentioned in the documentation here:
https://docs.zephyrproject.org/latest/introduction/index.html .
search for slack and you will find this tinyurl slack invite link: https://tinyurl.com/2vue8666


Re: Slack Invite

Daniel O <dsoliveira@...>
 

Hi there,

I'm with the same problem I have also tried with Google login.
It seems the public link is unavailable


Re: Slack Invite

Nashif, Anas
 

Hi,
Using existing domain from the list is an option, did you try to use some other way or do you have an account on slack already?



On 1 Jul 2021, at 06:01, Davide Pollarolo <dpollarolo@...> wrote:

Hello,

asking if anyone knows how to request an invite for the Zephyr Slack Workspace...?

My work email is not part of any of the below domains:
<image.png>

Thanks!

D


Slack Invite

Davide Pollarolo
 

Hello,

asking if anyone knows how to request an invite for the Zephyr Slack Workspace...?

My work email is not part of any of the below domains:
image.png

Thanks!

D


Re: options for missing driver functions

Jeff Haynes <feedyurhed@...>
 


Thanks a lot for the fast response.  That sounds great and I'd be happy to contribute whenever you're ready.  Do you have any idea what you're thinking in terms of timing?

Thanks!

Jeff


On Wed, Jun 30, 2021 at 8:50 AM Armando VISCONTI <armando.visconti@...> wrote:
Hi Jeff,

I have in plan to improve the lis2ds12 with
following stuff:

1. Adding stmemsc HAL i/f support
2. Support multi-instance
3. Use common i2c/spi routines
4. Move FS and ODR properties from Kconfig to DTS
5. others minor things?

After that I'm not planning to add other features like wake-up.
So, if you want to do this part (after my improvements) I'll
be more than happy to review your work.

How does it sound to you?

Arm

On 6/30/21 2:44 PM, Erwan Gouriou wrote:
> Adding Armando as codeowner of this driver.
>
> On Tue, 29 Jun 2021 at 17:31, Jeff Haynes <feedyurhed@...
> <mailto:feedyurhed@...>> wrote:
>
>
>     Relatively new Zephyr user here.  We have a custom board with
>     a LIS2DS12 IMU on it.  I've been somewhat ignoring it up to now as
>     it serves a secondary function and we sort of just threw it on there
>     thinking we would get to it later.  Now that I'm ready to tackle it
>     it looks like the built-in functionality in the driver is pretty
>     limited and doesn't cover the wake-up scenarios we need.  What are
>     our options at this point?  Should we add to the existing driver?
>     Attempt to do everything in the app or "side-load" a driver?
>     Attempt to include the ST HAL?
>
>     Thanks,
>
>     Jeff
>
>
>
>     --
>     If you want to build a ship, don't drum up people together to
>     collect wood and don't assign them tasks and work, but rather teach
>     them to long for the endless immensity of the sea.
>
>     Antoine de Saint-Exupery >


--
If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Antoine de Saint-Exupery


stm32: DMA: driver bindings new packaging

Francois RAMU
 

Hi all,

 

I'd like to inform STM32   DMA  users  that I'm pushing a change [1] to simplify the definition of the <dma—cells> properties for dma peripherals of the stm32 MCUs.

This change now proposes 3 versions of the dma plus the dmamux in the dts and selects the nb of elements for the <dma-cells>

It depends on the type of DMA instance of the stm32 MCU (from Ref. Man). With this :

 

DMA V1 : DMA with FIFO control

à the <dma-cells>   has 4 elements : ‘channel’, ‘slot’, ‘channel-config’, ‘feature’

for example on stm32F4 or stm32F2 MCUs

 

DMA V2 : DMA without FIFO control and selectable request for each channel

à  the <dma-cells>   has 3 elements : : ‘channel’, ‘slot’, ‘channel-config’

for example on stm32L4xx or stm32L0xx MCUs

 

DMA  V2bis : DMA without FIFO control and fixed request (slot) for each channel

à the <dma-cells>   has 2 elements : : ‘channel’,  ‘channel-config’

 For stm32L1 and stm32F1   MCUs

 

DMAMUX   multiplexing DMA channels : like a DMA V2

à does not require ‘feature’ parameter

For example on stm32G4 or stm32WB   MCUs

 

 

Benefit is to remove unused parameters in the DTS and simply the structure of the dma peripherals.

 

To declare a new peripheral client of the DMA, the version of the DMA must be first identify, according to the stm32  Ref Manual.

Then the <dma-cells> properties is filled with :

‘channel’ to select a free DMA channel for transfer

‘slot’ to select the peripheral request in DMA V1 or DMA V2 or DMAMUX versions

‘channel-config’,  to configure the dma channel

‘feature’  for configuring the FIFO in DMA V1 versions

 

This change will be hopefully integrated in the next Zephyr DV that will be released in October ‘21.

 

 

Cheers

FRASTM

 

[1] https://github.com/zephyrproject-rtos/zephyr/pull/34666

 


Re: Issue flashing and running openthread rcp example samples/net/openthread/coprocessor on Arduino Nano 33 BLE #nrf52480

Lubos, Robert
 

Hi Nagesh,

 

USB device re-enumeration is a known issue for RCP and OTBR. The topic is still quite fresh in terms of Zephyr, as we do not implement “software” reset OTBR required so far.

 

There’ve been some activity in this area however in OT, specifically to properly support device re-enumertion after reset (https://github.com/zephyrproject-rtos/zephyr/issues/30429#issuecomment-870493619). The USB support for RCP running on Nordic devices is currently being added to the Nordic’s coprocessor sample (along with documentation) so it might be a good reference for your case as well (note however that NCS has out-of-the-box support only for official Nordic DKs) – see https://github.com/nrfconnect/sdk-nrf/pull/4121/files.

 

Regards,

Robert

 

From: users@... <users@...> On Behalf Of nagesh.shamnur via lists.zephyrproject.org
Sent: środa, 30 czerwca 2021 16:53
To: users@...
Subject: [Zephyr-users] Issue flashing and running openthread rcp example samples/net/openthread/coprocessor on Arduino Nano 33 BLE #nrf52480 #nrf52480

 

Hi All,

Issue Description:  I am trying to flash and run openthread rcp sample as explained in the link: https://docs.zephyrproject.org/latest/samples/net/openthread/coprocessor/README.html. I am able to flash the image successfully, but port for spinel to connect to board seems to be off and thus ot-daemon is failing since it cannot find the socket on which it exchanges the HDLC frames and thus ot-daemon init is failing.
     With further analysis, i found that, the /dev/ttyACM0 is allocated for openthread coprocessor but that seems to get disconnected and then again /dev/ttyACM1 is created which apparently doesn't looks like belonging to RCP.

my config as below:
i am using boards/arm/arduino_nano_33_ble/arduino_nano_33_ble_defconfig from upstream master without any changes.

but changing config under samples/net/openthread/coprocessor as below:
prj.conf: commented CONFIG_UART_CONSOLE_ON_DEV_NAME to avoid shell/console which might conflict with spinel.
added a new file overlay-usb-arduino-coprocessor.conf with values as below: (Without this overlay file, once flashed, /dev/ttyACMx was not showing up in dmesg and thus board was not accessible for spinel)
```
# Arduino  NCP/RCP USB CDC-ACM

# Use USB-CDC-ACM for Co-Processor
CONFIG_OPENTHREAD_COPROCESSOR_SPINEL_ON_UART_ACM=y
CONFIG_OPENTHREAD_COPROCESSOR_SPINEL_ON_UART_DEV_NAME="CDC_ACM_0"
CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="OpenThread CoProcessor NRF"
CONFIG_USB_CDC_ACM=y
CONFIG_UART_LINE_CTRL=y
CONFIG_USB_REQUEST_BUFFER_SIZE=2048

CONFIG_ISR_STACK_SIZE=4096

## added for testing
CONFIG_STDOUT_CONSOLE=y
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
```
command to build and flash:
west build -p auto -b arduino_nano_33_ble samples/net/openthread/coprocessor -- -DCONF_FILE="prj.conf overlay-rcp.conf overlay-usb-arduino-rcp.conf"
west flash --bossac="path to arudino bossac"

once flashing is done, dmesg shows as below:
```
$ sudo dmesg
[92443.138797] usb 1-2: USB disconnect, device number 100
[92445.514950] usb 1-2: new full-speed USB device number 101 using xhci_hcd
[92445.668022] usb 1-2: New USB device found, idVendor=2341, idProduct=005a, bcdDevice= 0.11
[92445.668036] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[92445.668042] usb 1-2: Product: Arduino Nano 33 BLE
[92445.668047] usb 1-2: Manufacturer: Arduino
[92445.668051] usb 1-2: SerialNumber: 0000000000000000768275C7726D618B
[92445.671199] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[92445.750532] usb 1-2: USB disconnect, device number 101
[92446.058962] usb 1-2: new full-speed USB device number 102 using xhci_hcd
[92446.210705] usb 1-2: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 2.06
[92446.210718] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[92446.210724] usb 1-2: Product: OpenThread CoProcessor NRF
[92446.210729] usb 1-2: Manufacturer: ZEPHYR
[92446.210733] usb 1-2: SerialNumber: 53235D59E996F2DD
[92446.213710] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[92446.965464] usb 1-2: USB disconnect, device number 102
[92447.286888] usb 1-2: new full-speed USB device number 103 using xhci_hcd
[92447.437855] usb 1-2: New USB device found, idVendor=2341, idProduct=005a, bcdDevice= 0.11
[92447.437858] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[92447.437859] usb 1-2: Product: Arduino Nano 33 BLE
[92447.437860] usb 1-2: Manufacturer: Arduino
[92447.437861] usb 1-2: SerialNumber: 0000000000000000768275C7726D618B
[92447.440050] cdc_acm 1-2:1.0: ttyACM1: USB ACM device
[92447.476098] usb 1-2: USB disconnect, device number 103
[92447.786887] usb 1-2: new full-speed USB device number 104 using xhci_hcd
```
i see that it allocates the port /dev/ttyACM0 for OpenThread CoProcessor NRF but immediately it is disconnected and activates /dev/ttyACM1 for Arduino Nano 33 BLE which might not be the right port to which spinel can connect.

in ot-deamon, if i try to connect to this port, ot-daemon init fails since it is unable to find the socket to which it connects to the board. So, effectively port is not available for spinel to communicate with the board.
```
$ sudo ./build/posix/src/posix/ot-daemon -v 'spinel+hdlc+uart:///dev/ttyACM1?uart-baudrate=115200'
[sudo] password for ohos-bld:
./build/posix/src/posix/ot-daemon[297929]: Running OPENTHREAD/thread-reference-20200818-1035-g3a7e836dd-dirty; POSIX; Jun 30 2021 18:40:07
./build/posix/src/posix/ot-daemon[297929]: Thread version: 3
./build/posix/src/posix/ot-daemon[297929]: [CRIT]-PLAT----: Init() at ../../src/lib/spinel/radio_spinel_impl.hpp:274: Failure
```

I am stuck here, any help or pointers will be very useful.

Thanks,
Nagesh.


Issue flashing and running openthread rcp example samples/net/openthread/coprocessor on Arduino Nano 33 BLE #nrf52480

nagesh shamnur
 

Hi All,

Issue Description:  I am trying to flash and run openthread rcp sample as explained in the link: https://docs.zephyrproject.org/latest/samples/net/openthread/coprocessor/README.html. I am able to flash the image successfully, but port for spinel to connect to board seems to be off and thus ot-daemon is failing since it cannot find the socket on which it exchanges the HDLC frames and thus ot-daemon init is failing.
     With further analysis, i found that, the /dev/ttyACM0 is allocated for openthread coprocessor but that seems to get disconnected and then again /dev/ttyACM1 is created which apparently doesn't looks like belonging to RCP.

my config as below:
i am using boards/arm/arduino_nano_33_ble/arduino_nano_33_ble_defconfig from upstream master without any changes.

but changing config under samples/net/openthread/coprocessor as below:
prj.conf: commented CONFIG_UART_CONSOLE_ON_DEV_NAME to avoid shell/console which might conflict with spinel.
added a new file overlay-usb-arduino-coprocessor.conf with values as below: (Without this overlay file, once flashed, /dev/ttyACMx was not showing up in dmesg and thus board was not accessible for spinel)
```
# Arduino  NCP/RCP USB CDC-ACM

# Use USB-CDC-ACM for Co-Processor
CONFIG_OPENTHREAD_COPROCESSOR_SPINEL_ON_UART_ACM=y
CONFIG_OPENTHREAD_COPROCESSOR_SPINEL_ON_UART_DEV_NAME="CDC_ACM_0"
CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="OpenThread CoProcessor NRF"
CONFIG_USB_CDC_ACM=y
CONFIG_UART_LINE_CTRL=y
CONFIG_USB_REQUEST_BUFFER_SIZE=2048

CONFIG_ISR_STACK_SIZE=4096

## added for testing
CONFIG_STDOUT_CONSOLE=y
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
```
command to build and flash:
west build -p auto -b arduino_nano_33_ble samples/net/openthread/coprocessor -- -DCONF_FILE="prj.conf overlay-rcp.conf overlay-usb-arduino-rcp.conf"
west flash --bossac="path to arudino bossac"

once flashing is done, dmesg shows as below:
```
$ sudo dmesg
[92443.138797] usb 1-2: USB disconnect, device number 100
[92445.514950] usb 1-2: new full-speed USB device number 101 using xhci_hcd
[92445.668022] usb 1-2: New USB device found, idVendor=2341, idProduct=005a, bcdDevice= 0.11
[92445.668036] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[92445.668042] usb 1-2: Product: Arduino Nano 33 BLE
[92445.668047] usb 1-2: Manufacturer: Arduino
[92445.668051] usb 1-2: SerialNumber: 0000000000000000768275C7726D618B
[92445.671199] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[92445.750532] usb 1-2: USB disconnect, device number 101
[92446.058962] usb 1-2: new full-speed USB device number 102 using xhci_hcd
[92446.210705] usb 1-2: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 2.06
[92446.210718] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[92446.210724] usb 1-2: Product: OpenThread CoProcessor NRF
[92446.210729] usb 1-2: Manufacturer: ZEPHYR
[92446.210733] usb 1-2: SerialNumber: 53235D59E996F2DD
[92446.213710] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[92446.965464] usb 1-2: USB disconnect, device number 102
[92447.286888] usb 1-2: new full-speed USB device number 103 using xhci_hcd
[92447.437855] usb 1-2: New USB device found, idVendor=2341, idProduct=005a, bcdDevice= 0.11
[92447.437858] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[92447.437859] usb 1-2: Product: Arduino Nano 33 BLE
[92447.437860] usb 1-2: Manufacturer: Arduino
[92447.437861] usb 1-2: SerialNumber: 0000000000000000768275C7726D618B
[92447.440050] cdc_acm 1-2:1.0: ttyACM1: USB ACM device
[92447.476098] usb 1-2: USB disconnect, device number 103
[92447.786887] usb 1-2: new full-speed USB device number 104 using xhci_hcd
```
i see that it allocates the port /dev/ttyACM0 for OpenThread CoProcessor NRF but immediately it is disconnected and activates /dev/ttyACM1 for Arduino Nano 33 BLE which might not be the right port to which spinel can connect.

in ot-deamon, if i try to connect to this port, ot-daemon init fails since it is unable to find the socket to which it connects to the board. So, effectively port is not available for spinel to communicate with the board.
```
$ sudo ./build/posix/src/posix/ot-daemon -v 'spinel+hdlc+uart:///dev/ttyACM1?uart-baudrate=115200'
[sudo] password for ohos-bld:
./build/posix/src/posix/ot-daemon[297929]: Running OPENTHREAD/thread-reference-20200818-1035-g3a7e836dd-dirty; POSIX; Jun 30 2021 18:40:07
./build/posix/src/posix/ot-daemon[297929]: Thread version: 3
./build/posix/src/posix/ot-daemon[297929]: [CRIT]-PLAT----: Init() at ../../src/lib/spinel/radio_spinel_impl.hpp:274: Failure
```

I am stuck here, any help or pointers will be very useful.

Thanks,
Nagesh.


Re: options for missing driver functions

Armando VISCONTI <armando.visconti@...>
 

Hi Jeff,

I have in plan to improve the lis2ds12 with
following stuff:

1. Adding stmemsc HAL i/f support
2. Support multi-instance
3. Use common i2c/spi routines
4. Move FS and ODR properties from Kconfig to DTS
5. others minor things?

After that I'm not planning to add other features like wake-up.
So, if you want to do this part (after my improvements) I'll
be more than happy to review your work.

How does it sound to you?

Arm

On 6/30/21 2:44 PM, Erwan Gouriou wrote:
Adding Armando as codeowner of this driver.
On Tue, 29 Jun 2021 at 17:31, Jeff Haynes <feedyurhed@gmail.com <mailto:feedyurhed@gmail.com>> wrote:
Relatively new Zephyr user here.  We have a custom board with
a LIS2DS12 IMU on it.  I've been somewhat ignoring it up to now as
it serves a secondary function and we sort of just threw it on there
thinking we would get to it later.  Now that I'm ready to tackle it
it looks like the built-in functionality in the driver is pretty
limited and doesn't cover the wake-up scenarios we need.  What are
our options at this point?  Should we add to the existing driver? Attempt to do everything in the app or "side-load" a driver? Attempt to include the ST HAL?
Thanks,
Jeff
--
If you want to build a ship, don't drum up people together to
collect wood and don't assign them tasks and work, but rather teach
them to long for the endless immensity of the sea.
Antoine de Saint-Exupery


Re: Zephyr on Hexiwear and integrated Display Support

Maureen Helm
 

Hi Marvin,
The Hexiwear board can use the same SPI driver as the FRDM-K64 board, but you need to configure the SPI pinmuxes. Check the schematic to determine which SPI instance and pins to use. They may not be the same as FRDM-K64F, but should look something like this:
https://github.com/zephyrproject-rtos/zephyr/blob/a9b1c42f403737a2abfeae31e6b5fd43f1d7869f/boards/arm/frdm_k64f/pinmux.c#L61-L67

Maureen

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Marvin Beckmann via lists.zephyrproject.org
Sent: Tuesday, June 29, 2021 9:22 AM
To: users@lists.zephyrproject.org
Subject: [Zephyr-users] Zephyr on Hexiwear and integrated Display Support

Hi guys,

I am using Zephyr on the Hexiwear Board. I accomplished to use the hearrate sensor and some other sensors on the board.

But I am still having trouble with the integrated Display (SSD1351 OLED Display with SPI)

I didn't find drivers for this display. So i decided to use the SSD1306 Drivers.

It seems to work, because the functions for the display return zero, but display is not showing anything.

Is there any chance to support SPI on the Hexiwear Board and using the integrated display.

Here is the link for my code:
https://gitlab.com/MarvB19/hexiwear_display
<https://gitlab.com/MarvB19/hexiwear_display>

I hope you can help me :)

Have a nice day.


Kind regards

Marvin Beckmann


Re: options for missing driver functions

Erwan Gouriou
 

Adding Armando as codeowner of this driver.


On Tue, 29 Jun 2021 at 17:31, Jeff Haynes <feedyurhed@...> wrote:

Relatively new Zephyr user here.  We have a custom board with a LIS2DS12 IMU on it.  I've been somewhat ignoring it up to now as it serves a secondary function and we sort of just threw it on there thinking we would get to it later.  Now that I'm ready to tackle it it looks like the built-in functionality in the driver is pretty limited and doesn't cover the wake-up scenarios we need.  What are our options at this point?  Should we add to the existing driver?  Attempt to do everything in the app or "side-load" a driver?  Attempt to include the ST HAL?

Thanks,

Jeff



--
If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Antoine de Saint-Exupery


Re: [EXTERNAL] Re: [Zephyr-users] Errors while using west flash

Pandey, Mithun
 

HI Erwan,

 

Thanks for the reply,

 

The second option worked for me, although the build is still showing as using openocd (its already installed ),

One more option is working for me

 

#board_runner_args(openocd "--use-elf")

board_runner_args(pyocd "--device=STM32F429ZI")

 

include(${ZEPHYR_BASE}/boards/common/openocd.board.cmake)

include(${ZEPHYR_BASE}/boards/common/pyocd.board.cmake)

 

earlier the board_runner_args is using jlink, maybe that’s the reason its not working.

 

Thanks and Regards

Mithun

 

 

From: users@... <users@...> On Behalf Of Erwan Gouriou
Sent: Wednesday, June 30, 2021 2:10 PM
To: Pandey, Mithun <MithunPandey@...>
Cc: users@...; Brezovec, Mark A <MarkABrezovec@...>
Subject: [EXTERNAL] Re: [Zephyr-users] Errors while using west flash

 

Hi Mithun,

 

Seeing this:

  File "C:\Users\username\zephyrproject\zephyr\scripts/west_commands\runners\openocd.py", line 114, in do_run
    self.require(self.openocd_cmd[0])

 

It seems that west is attempting to flash using openocd which might not be installed in your environment.

You have two options:

 

- Install openocd 

- [Not tested] Set pyocd as the default runner for this board, by adding the following lines in board/arm/nucleo_f429zi/board.cmake

board_runner_args(pyocd "--target=stm32f429xi")

include(${ZEPHYR_BASE}/boards/common/pyocd.board.cmake)

 

 

HIH

 

 

On Wed, 30 Jun 2021 at 06:19, Pandey, Mithun <mithunpandey@...> wrote:

HI,

 

I am following the setup steps in given in https://docs.zephyrproject.org/latest/getting_started/index.html

Using a Python (3.6) Virtual environment.

I was able to build the Blinky example, trying to flash it in Nucleo F429zi board. West build Log file attached.

Tool chain used is “GNU_Arm_Embedded_Toolchain”

 

I have two Nucleo boards (One 429 and one F767), output of “pyocd list” command shows that

  #   Probe          Unique ID

-----------------------------------------------

  0   STM32 STLink   066CFF363336485043072710

  1   STM32 STLink   0674FF535155878281133844

 

Problem:

When doing the flashing using “west flash” command I am getting python related error, log file attached.

 

Kindly help in resolving this, is it happening because two probes are attached ?, I tried to find a way to specify the board number in the west command but didn’t find any.

 

Kindly help.

 

Thanks and Regards

Mithun

 

 

 

 

 


Re: Errors while using west flash

Erwan Gouriou
 

Hi Mithun,

Seeing this:
  File "C:\Users\username\zephyrproject\zephyr\scripts/west_commands\runners\openocd.py", line 114, in do_run
    self.require(self.openocd_cmd[0])

It seems that west is attempting to flash using openocd which might not be installed in your environment.
You have two options:

- Install openocd 
- [Not tested] Set pyocd as the default runner for this board, by adding the following lines in board/arm/nucleo_f429zi/board.cmake
board_runner_args(pyocd "--target=stm32f429xi")
include(${ZEPHYR_BASE}/boards/common/pyocd.board.cmake)


HIH


On Wed, 30 Jun 2021 at 06:19, Pandey, Mithun <mithunpandey@...> wrote:

HI,

 

I am following the setup steps in given in https://docs.zephyrproject.org/latest/getting_started/index.html

Using a Python (3.6) Virtual environment.

I was able to build the Blinky example, trying to flash it in Nucleo F429zi board. West build Log file attached.

Tool chain used is “GNU_Arm_Embedded_Toolchain”

 

I have two Nucleo boards (One 429 and one F767), output of “pyocd list” command shows that

  #   Probe          Unique ID

-----------------------------------------------

  0   STM32 STLink   066CFF363336485043072710

  1   STM32 STLink   0674FF535155878281133844

 

Problem:

When doing the flashing using “west flash” command I am getting python related error, log file attached.

 

Kindly help in resolving this, is it happening because two probes are attached ?, I tried to find a way to specify the board number in the west command but didn’t find any.

 

Kindly help.

 

Thanks and Regards

Mithun

 

 

 

 

 


Errors while using west flash

Pandey, Mithun
 

HI,

 

I am following the setup steps in given in https://docs.zephyrproject.org/latest/getting_started/index.html

Using a Python (3.6) Virtual environment.

I was able to build the Blinky example, trying to flash it in Nucleo F429zi board. West build Log file attached.

Tool chain used is “GNU_Arm_Embedded_Toolchain”

 

I have two Nucleo boards (One 429 and one F767), output of “pyocd list” command shows that

  #   Probe          Unique ID

-----------------------------------------------

  0   STM32 STLink   066CFF363336485043072710

  1   STM32 STLink   0674FF535155878281133844

 

Problem:

When doing the flashing using “west flash” command I am getting python related error, log file attached.

 

Kindly help in resolving this, is it happening because two probes are attached ?, I tried to find a way to specify the board number in the west command but didn’t find any.

 

Kindly help.

 

Thanks and Regards

Mithun

 

 

 

 

 


options for missing driver functions

Jeff Haynes <feedyurhed@...>
 


Relatively new Zephyr user here.  We have a custom board with a LIS2DS12 IMU on it.  I've been somewhat ignoring it up to now as it serves a secondary function and we sort of just threw it on there thinking we would get to it later.  Now that I'm ready to tackle it it looks like the built-in functionality in the driver is pretty limited and doesn't cover the wake-up scenarios we need.  What are our options at this point?  Should we add to the existing driver?  Attempt to do everything in the app or "side-load" a driver?  Attempt to include the ST HAL?

Thanks,

Jeff



--
If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Antoine de Saint-Exupery

101 - 120 of 2737