Date   

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


Zephyr on Hexiwear and integrated Display Support

Marvin Beckmann <marvin@...>
 

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: Not understanding how to enable peripherals in devicetree

Jason Bens
 

Thanks Armand,

 

I think I‘ve got that working, now, and referenced properly in the CMakeList.  A devicetree binding somewhere requires a couple pin definitions, but I can handle that.

 

I did come across a bit more documentation at \zephyr\boards\arm\nrf5340dk_nrf5340\doc\index.rst , which lists the supported features for this SoC.  I2S is not on that list.  I’m not sure if that documentation is coming from the Zephyr community or Nordic, but should I interpret that to mean that any I2S driver functionality is accidental at best?

 

  • Jason

 

From: users@... <users@...> On Behalf Of Armand C.
Sent: June 29, 2021 2:22 PM
To: users@...
Subject: Re: [Zephyr-users] Not understanding how to enable peripherals in devicetree

 

External Email:

Hi Jason,

You have to enable the peripheral in the board devicetree overlay (see below).

&i2s0 {
    status = "okay";
};

Armand


Re: Not understanding how to enable peripherals in devicetree

Armand C. <rnx.lab@...>
 

Hi Jason,

You have to enable the peripheral in the board devicetree overlay (see below).

&i2s0 {
    status = "okay";
};

Armand


Not understanding how to enable peripherals in devicetree

Jason Bens
 

Hi,

 

I’m a complete newcomer to zephyr and devicetree, and I’m running into some trouble trying to enable the I2S peripheral on the nRF5340dk board.  I’ve enabled both the I2S driver (Modules->hal_nordic->nrfx_drivers) and the I2S bus drivers (Device Drivers) in menuconfig.  I’ve also added “CONFIG_I2S=y” to my top-level prj.conf.  Despite this, when I check zephyr.dts in my build directory, the i2s0 device is disabled.

 

Zephyr.dts excerpt:

i2s0: i2s@28000 {

compatible = "nordic,nrf-i2s";

     #address-cells = < 0x1 >;

     #size-cells = < 0x0 >;

     reg = < 0x28000 0x1000 >;

     interrupts = < 0x28 0x1 >;

     status = "disabled";

     label = "I2S_0";

};

 

I’ve checked the i2s litex sample and read through the docs, but I’m not finding a solution.  Am I missing a step somewhere to enable this device? Do I need a devicetree overlay to explicitly enable i2s?  If it’s relevant, I’ve been using the Nordic edition of SEGGER Embedded studio to build the project, as per Nordic’s nRF Connect toolchain documentation.

 

Thanks,

 

  • Jason


nRF9160 custom board Re-running CMake #nrf9160

David Kaplan
 
Edited

We have created a custom nRF9160 board which arrived in Las Vegas which I debug by Teams. The hardware engineer has the same version of Nordic nRF Connect SDK v1.51 (SES) as on my computer.
We both use Windows 10.

I update the following files
 1) c:\ncs\v1.5.1\zephyr\drivers\sensor\lsm6dsl\lsm6dsl.c
       Changes made in the sensor driver for retrieving the raw accelerometer X,Y,z int16 readings and for writing and reading raw chip byte setup registers.
 2) c:\ncs\v1.5.1\zephyr\include\drivers\sensor\lsm6dsl_drv.h
       Added a new raw channel and new raw register attributes defines
 3) c:\ncs\v1.5.1\zephyr\boards\arm\nrf9160axion_nrf9160
      Copied nrf9160dk_nrf9160 folder with a few adjustments for our custom board.
 4) D:\Projects\ami_axion
      Our project

For two days I sent updated files and the hardware engineer reran the nRF Connect SDK script from the SES File menu to rerun the scripts which act on the new files and then he performs a clean and a rebuild.
This morning, the rebuilt took such a long time and then returned with an error.
On my computer everything works. I resent the files and verified that he updated them in the correct places.
After several hours trying, I looked at the build window and saw that there was an endless loop of "Re-running CMake...".
In the log, it also showed one warning:
  warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
This does not occur on my setup and when building the project for the original nrf9160dk_nrf9160(ns) board in Las Vegas, all compiled well.
Both the nrf9160dk_nrf9160ns.overlay and the nrf9160axion_nrf9160ns.overlay files have the has-be32k setting for the external memory.
I removed the has-be32k setting from the custom board's overlay but we just got to another problem.

I send the project folder compressed without the build_nrf9160axion_nrf9160ns or build_nrf9160dk_nrf9160ns directories since they are created with the nRF Connect SDK script from the SES File menu.

How I can I understand the exact reason for my problems?

Is there a different way to do things?

Thanks David


  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-mkdir’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-mkdir’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-download’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-download’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-update’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-update’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-patch’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-patch’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-configure’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-configure’
  • Rebuilding ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-build’ from solution ‘build’ in configuration ‘Common’
  • 1> Combining ‘modules/nrf/samples/spm_subimage-prefix/src/spm_subimage-stamp/spm_subimage-build’
  • 1> [0/1] Re-running CMake...
  • 1> Including boilerplate (Zephyr base (cached)): C:/Users/Omer_Z/ncs/v1.5.1/zephyr/cmake/app/boilerplate.cmake
  • 1> -- Application: C:/Users/Omer_Z/ncs/v1.5.1/nrf/samples/spm
  • 1> -- Using NCS Toolchain 1.5.1 for building. (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/cmake)
  • 1> -- Zephyr version: 2.4.99 (C:/Users/Omer_Z/ncs/v1.5.1/zephyr)
  • 1> -- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
  • 1> -- Board: nrf9160axion_nrf9160, Revision: 0.7.0
  • 1> -- Cache files will be written to: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/.cache
  • 1> -- Found dtc: C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
  • 1> -- Found toolchain: gnuarmemb (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt)
  • 1> -- Found BOARD.dts: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/boards/arm/nrf9160axion_nrf9160/nrf9160axion_nrf9160.dts
  • 1> -- Found devicetree overlay: D:/Projects/ami_axion/nrf9160axion_nrf9160ns.overlay
  • 1> warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
  • 1> -- Generated zephyr.dts: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/zephyr.dts
  • 1> -- Generated devicetree_unfixed.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/devicetree_unfixed.h
  • 1> -- Generated device_extern.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/device_extern.h
  • 1> Parsing C:/Users/Omer_Z/ncs/v1.5.1/zephyr/Kconfig
  • 1> Loaded configuration 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to configuration in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to Kconfig header in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/autoconf.h'
  • 1> -- Configuring done
  • 1> -- Generating done
  • 1> -- Build files have been written to: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm
  • 1> [0/1] Re-running CMake...
  • 1> Including boilerplate (Zephyr base (cached)): C:/Users/Omer_Z/ncs/v1.5.1/zephyr/cmake/app/boilerplate.cmake
  • 1> -- Application: C:/Users/Omer_Z/ncs/v1.5.1/nrf/samples/spm
  • 1> -- Using NCS Toolchain 1.5.1 for building. (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/cmake)
  • 1> -- Zephyr version: 2.4.99 (C:/Users/Omer_Z/ncs/v1.5.1/zephyr)
  • 1> -- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
  • 1> -- Board: nrf9160axion_nrf9160, Revision: 0.7.0
  • 1> -- Cache files will be written to: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/.cache
  • 1> -- Found dtc: C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
  • 1> -- Found toolchain: gnuarmemb (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt)
  • 1> -- Found BOARD.dts: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/boards/arm/nrf9160axion_nrf9160/nrf9160axion_nrf9160.dts
  • 1> -- Found devicetree overlay: D:/Projects/ami_axion/nrf9160axion_nrf9160ns.overlay
  • 1> warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
  • 1> -- Generated zephyr.dts: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/zephyr.dts
  • 1> -- Generated devicetree_unfixed.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/devicetree_unfixed.h
  • 1> -- Generated device_extern.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/device_extern.h
  • 1> Parsing C:/Users/Omer_Z/ncs/v1.5.1/zephyr/Kconfig
  • 1> Loaded configuration 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to configuration in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to Kconfig header in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/autoconf.h'
  • 1> -- Configuring done
  • 1> -- Generating done
  • 1> -- Build files have been written to: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm
  • 1> [0/1] Re-running CMake...
  • 1> Including boilerplate (Zephyr base (cached)): C:/Users/Omer_Z/ncs/v1.5.1/zephyr/cmake/app/boilerplate.cmake
  • 1> -- Application: C:/Users/Omer_Z/ncs/v1.5.1/nrf/samples/spm
  • 1> -- Using NCS Toolchain 1.5.1 for building. (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/cmake)
  • 1> -- Zephyr version: 2.4.99 (C:/Users/Omer_Z/ncs/v1.5.1/zephyr)
  • 1> -- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
  • 1> -- Board: nrf9160axion_nrf9160, Revision: 0.7.0
  • 1> -- Cache files will be written to: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/.cache
  • 1> -- Found dtc: C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
  • 1> -- Found toolchain: gnuarmemb (C:/Users/Omer_Z/ncs/v1.5.1/toolchain/opt)
  • 1> -- Found BOARD.dts: C:/Users/Omer_Z/ncs/v1.5.1/zephyr/boards/arm/nrf9160axion_nrf9160/nrf9160axion_nrf9160.dts
  • 1> -- Found devicetree overlay: D:/Projects/ami_axion/nrf9160axion_nrf9160ns.overlay
  • 1> warning: 'has-be32k' is marked as deprecated in 'properties:' in C:/Users/Omer_Z/ncs/v1.5.1/zephyr/dts/bindings\mtd\jedec,spi-nor.yaml for node /soc/peripheral@50000000/spi@b000/mx25r6435f@0.
  • 1> -- Generated zephyr.dts: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/zephyr.dts
  • 1> -- Generated devicetree_unfixed.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/devicetree_unfixed.h
  • 1> -- Generated device_extern.h: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/device_extern.h
  • 1> Parsing C:/Users/Omer_Z/ncs/v1.5.1/zephyr/Kconfig
  • 1> Loaded configuration 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to configuration in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/.config'
  • 1> No change to Kconfig header in 'D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm/zephyr/include/generated/autoconf.h'
  • 1> -- Configuring done
  • 1> -- Generating done
  • 1> -- Build files have been written to: D:/Projects/ami_axion/build_nrf9160axion_nrf9160ns/spm
  • 1> [0/1] Re-running CMake...


Re: Questions regarding Zephyr's testing framework

Kumar Gala
 

On Jun 25, 2021, at 4:16 AM, Harald Böhm <harald.boehm@fau.de> wrote:

Hello,

I am trying to get a better understanding of Zephyr's testing framework.
I have read the documentation, but I still have two questions:

1. Is there a meaniningful difference between the terms "board" and
"platform" or are these used interchangeably?
They are used interchangeably. Its unfortunate we haven’t cleaned up platform to be board.


2. Do there exist fixture names that are deduced from the board's
configuration or are only those considered that are defined in
the hardware map / provided via command line?

As an example, if the respective YAML file in /boards defines:

...
supported:
- gpio
...

does this already fulfil some of the fixtures mentioned in the
documentation with the prefix gpio_?
Fixtures are different from what is listed in ’supported’ in the board YAML. The board YAML is meant to convey what features a board supports between hardware on the board & software in zephyr. A fixture is describing some test hardware requirement.

- k


Questions regarding Zephyr's testing framework

Harald Böhm
 

Hello,

I am trying to get a better understanding of Zephyr's testing framework.
I have read the documentation, but I still have two questions:

1. Is there a meaniningful difference between the terms "board" and
"platform" or are these used interchangeably?

2. Do there exist fixture names that are deduced from the board's
configuration or are only those considered that are defined in
the hardware map / provided via command line?

As an example, if the respective YAML file in /boards defines:

...
supported:
- gpio
...

does this already fulfil some of the fixtures mentioned in the
documentation with the prefix gpio_?


Best regards,
Harald


how to turn off echo on USB serial port

Holger Schurig
 

Hi,

I use a CDC_ACM serial port with Zephyr (from git), and using IRQ driven. Here is my ISR:

static void usb_serial_irq(const struct device *usb_dev, void *user_data)
{
    while (uart_irq_update(usb_dev) && uart_irq_is_pending(usb_dev)) {
        if (uart_irq_rx_ready(usb_dev)) {
            usb_rx_buf_len = uart_fifo_read(usb_dev, usb_rx_buf, sizeof(usb_rx_buf));
            // we disable the interrupt here and send an event
            // main.c will receive the event, parses what we received, and turn
            // on the receive interrupts again.
            uart_irq_rx_disable(usb_dev);
            LOG_HEXDUMP_ERR(&usb_rx_buf, usb_rx_buf_len, "USB RX");
            event_send(USB_INCOMING_DATA);
        }

        if (uart_irq_tx_ready(usb_dev)) {
            uint8_t buffer[64];
            int rb_len;
            int send_len;

            rb_len = ring_buf_get(&usb_tx_ring, buffer, sizeof(buffer));
            if (!rb_len) {
                uart_irq_tx_disable(usb_dev);
                continue;
            }

            send_len = uart_fifo_fill(usb_dev, buffer, rb_len);
            if (send_len < rb_len) {
                LOG_ERR("dropped tx %d byte", rb_len - send_len);
            }
        }
    }
}

I can receive nicely with this.

However, when I sent characters this way:

int usb_serial_putc(char c)
{
    if (!usb_dev)
        return 0;
    int count = 0;
    while (ring_buf_space_get(&usb_tx_ring) < 1) {
        if (++count > 500)
            return -1;
        k_sleep(K_MSEC(2));
    }
    ring_buf_put(&usb_tx_ring, &c, 1);
    uart_irq_tx_enable(usb_dev);
    return 0;
}

I will *ALSO* receive them, as the LOG_HEXDUMP_ERR in the ISR showed me.

My applicaton is currently compiled for POSIX native (real hardware isn't ready yet). In Linux, I use "usbip attach -r localhost -b 1-1". And even a "cat </dev/ttyACM0" makes my ISR receive sent data ... despite the fact that cat cannot send at all. This also doesn't happen with normal USB dongles, so it must be some behavior of Zephyr.

How can I prevent the reception of the data that I sent by myself?

161 - 180 of 2789