Date   

Re: Hardware acceleration using cryptocell engine in #nrf52840 #crypto

Carles Cufi
 

Hi Nikos,

 

The Cryptocell requires proprietary software that is not part of Zephyr. If you’d like to use the Cryptocell I recommend you take a look at Nordic’s Zephyr-based SDK, the nRF Connect SDK:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/index.html

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: 02 October 2020 16:59
To: users@...
Subject: [Zephyr-users] Hardware acceleration using cryptocell engine in #nrf52840 #crypto

 

Hello, I am going to use mbedtls library in order for sha256 hash calculation and ECDSA verify using nrf52840-dk. I can not find any configuration parameter for hardware acceleration. The device supports the cryptocell 310 engine. Is this enabled/supported by zephyr's mbedtls? If yes, is there any parameter to enable it or disable it?
Also, has anybody idea what is it "better" to use tinycrypt or mbedtls? I already use mbedtls as transport layer security for the LWM2M for this reason I am considering to use it for hashing etc (is already imported).


Hardware acceleration using cryptocell engine in #nrf52840 #crypto

Nikos Karamolegkos
 

Hello, I am going to use mbedtls library in order for sha256 hash calculation and ECDSA verify using nrf52840-dk. I can not find any configuration parameter for hardware acceleration. The device supports the cryptocell 310 engine. Is this enabled/supported by zephyr's mbedtls? If yes, is there any parameter to enable it or disable it?
Also, has anybody idea what is it "better" to use tinycrypt or mbedtls? I already use mbedtls as transport layer security for the LWM2M for this reason I am considering to use it for hashing etc (is already imported).


Re: STM32: Ethernet Driver not working on F7 and H7 with 2.4.0 #networking #driver #ethernet #stm32

Lawrence King
 

Dejavu, I think I have seen this question before. I don’t have a H7 or F7, but I remember a similar question was posted in April. Here is what it said, unfortunately there was no follow up to say if this helped or not.:

 

Hi Erik,

 

you are running out of RX network buffers. Try to increase the value of CONFIG_NET_BUF_RX_COUNT and optionally CONFIG_NET_PKT_RX_COUNT options.

 

Cheers,

Jukka

 

 

On Sun, 2020-04-19 at 23:58 -0700, erik.samyn@... wrote:

> Hi,

>

> I'm implementing mqtt on an nucleo stm32 board (stm32f767zi). The

> communication from the broker seemed to work OK at first, however when

> stressing the communication a bit the next error appears multiple

> times in the log:

> ==> "<err> eth_stm32_hal: Failed to obtain RX buffer".

>

> What can be the cause of this?

>

> Kind regards

>

> Erik Samyn

>

 

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of andreas.eberhart@...
Sent: Friday, October 2, 2020 3:12 AM
To: users@...
Subject: [Zephyr-users] STM32: Ethernet Driver not working on F7 and H7 with 2.4.0 #driver #ethernet #stm32 #networking

 

Dear all,

We try to run the net/sockets/packet sample on both, the Nucleo F746ZG and the H747I Discovery Board an run into the following issue with version 2.4.0 (works fine with 2.3.0 on F7):

*** Booting Zephyr OS build zephyr-v2.4.0-41-gcc0244bdd7d6  ***

[00:00:03.736,000] <inf> net_pkt_sock_sample: Packet socket sample is running

[00:00:03.736,000] <inf> net_pkt_sock_sample: Waiting for packets ...

[00:00:03.737,000] <dbg> net_pkt_sock_sample.send_packet_socket: Sent 100 bytes

[00:00:03.737,000] <wrn> net_if: iface 0x20010b04 is down

[00:00:04.001,000] <err> eth_stm32_hal: Failed to enqueue frame into RX queue: -62

[00:00:04.196,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 62 bytes

[00:00:04.197,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 110 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 91 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 89 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 95 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 71 bytes

[00:00:04.233,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 75 bytes

[00:00:04.233,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 69 bytes

[00:00:04.697,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 60 bytes

[00:00:04.715,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 82 bytes

[00:00:04.715,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 102 bytes

[00:00:04.716,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 82 bytes

[00:00:04.716,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 102 bytes

[00:00:05.001,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 60 bytes

[00:00:05.696,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 60 bytes

[00:00:08.112,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:08.112,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:08.112,000] <err> eth_stm32_hal: Failed to obtain RX buffer
.
.
.

[00:00:09.615,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.625,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.626,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.627,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.629,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.737,000] <err> net_pkt_sock_sample: Failed to send, errno 55

[00:00:09.737,000] <inf> net_pkt_sock_sample: Stopping...

[00:00:09.737,000] <err> os: ***** USAGE FAULT *****

[00:00:09.737,000] <err> os:   Illegal use of the EPSR

[00:00:09.737,000] <err> os: r0/a1:  0x20011ce4  r1/a2:  0x20014a4c  r2/a3:  0x20011788

[00:00:09.737,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x0800c293

[00:00:09.737,000] <err> os:  xpsr:  0x60000000

[00:00:09.737,000] <err> os: Faulting instruction address (r15/pc): 0x00000000

[00:00:09.737,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:00:09.737,000] <err> os: Current thread: 0x200110d8 (main)

[00:00:09.850,000] <err> os: Halting system

Has anyone encountered this behavior with the Ethernet driver on the STM32? It seems like the ethernet driver (eth_stm_32_hal.c) is not able to pass on the received packets to the buffer using net_pkt_rx_alloc_with_buffer().

Regards,

Andreas


STM32: Ethernet Driver not working on F7 and H7 with 2.4.0 #networking #driver #ethernet #stm32

andreas.eberhart@...
 

Dear all,

We try to run the net/sockets/packet sample on both, the Nucleo F746ZG and the H747I Discovery Board an run into the following issue with version 2.4.0 (works fine with 2.3.0 on F7):

*** Booting Zephyr OS build zephyr-v2.4.0-41-gcc0244bdd7d6  ***

[00:00:03.736,000] <inf> net_pkt_sock_sample: Packet socket sample is running

[00:00:03.736,000] <inf> net_pkt_sock_sample: Waiting for packets ...

[00:00:03.737,000] <dbg> net_pkt_sock_sample.send_packet_socket: Sent 100 bytes

[00:00:03.737,000] <wrn> net_if: iface 0x20010b04 is down

[00:00:04.001,000] <err> eth_stm32_hal: Failed to enqueue frame into RX queue: -62

[00:00:04.196,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 62 bytes

[00:00:04.197,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 110 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 91 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 89 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 95 bytes

[00:00:04.232,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 71 bytes

[00:00:04.233,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 75 bytes

[00:00:04.233,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 69 bytes

[00:00:04.697,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 60 bytes

[00:00:04.715,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 82 bytes

[00:00:04.715,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 102 bytes

[00:00:04.716,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 82 bytes

[00:00:04.716,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 102 bytes

[00:00:05.001,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 60 bytes

[00:00:05.696,000] <dbg> net_pkt_sock_sample.recv_packet_socket: Received 60 bytes

[00:00:08.112,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:08.112,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:08.112,000] <err> eth_stm32_hal: Failed to obtain RX buffer
.
.
.

[00:00:09.615,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.625,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.626,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.627,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.629,000] <err> eth_stm32_hal: Failed to obtain RX buffer

[00:00:09.737,000] <err> net_pkt_sock_sample: Failed to send, errno 55

[00:00:09.737,000] <inf> net_pkt_sock_sample: Stopping...

[00:00:09.737,000] <err> os: ***** USAGE FAULT *****

[00:00:09.737,000] <err> os:   Illegal use of the EPSR

[00:00:09.737,000] <err> os: r0/a1:  0x20011ce4  r1/a2:  0x20014a4c  r2/a3:  0x20011788

[00:00:09.737,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x0800c293

[00:00:09.737,000] <err> os:  xpsr:  0x60000000

[00:00:09.737,000] <err> os: Faulting instruction address (r15/pc): 0x00000000

[00:00:09.737,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

[00:00:09.737,000] <err> os: Current thread: 0x200110d8 (main)

[00:00:09.850,000] <err> os: Halting system

Has anyone encountered this behavior with the Ethernet driver on the STM32? It seems like the ethernet driver (eth_stm_32_hal.c) is not able to pass on the received packets to the buffer using net_pkt_rx_alloc_with_buffer().

Regards,

Andreas


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

Hi all,

I would like to ask you if I can change the lwm2m observer period. There is enough delay (some seconds), after calling lwm2m_engine_set_u8("5/0/3", STATE_IDLE) until the server get informed.


STM32: Moving devices pin configuration to device tree

Erwan Gouriou
 

TL;DR:
- Upcoming device tree based pin configuration for STM32 based boards
- Script generated, SoC package specific *-pinctrl.dtsi files are available in hal_stm32 modules
- Each *.pcintrl.dtsi file provides a complete set of valid pin configurations for targeted STM32
package
- Generation script is provided and can be used to generate new pin configuration variants (low
power, ...)
- One driver (STM32 serial) and two boards converted today as proof of concept
- Contributions are welcome to achieve deprecation of existing pinmux.c files within V2.5.0 
merge window


To all STM32 users and developers,

We're in the final step of reviewing PR #25996 "stm32: devices signals configuration from dt
This PR introduces the required material to enable device pin configuration using device tree.

With this method, device pin configuration should no longer be done in pinmux.c board file, but
in .dts file. For instance, to enable PB6 as TX and PB7 as RX on USART1, the following lines
should be added in .dts board file, in usart1 node:

 &usart1 {
        current-speed = <115200>;
+      pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>;
+      pinctrl-names = "default";
        status = "okay";
 };

As a consequence, pin configuration can now be done at device driver level, opening the way
to dynamic pin configuration, which could be useful in various fields such as low power
management. Also, it provides flexibility in application configuration as pin configurations could
then be modified in using overlays.

Pin control nodes are defined using Linux pinctrl bindings. For instance, usart1_tx_pb6 is
defined as
+usart1_tx_pb6: usart1_tx_pb6 {
+       pinmux = <STM32_PINMUX('B', 6, AF7)>;
+       bias-pull-up;
+};

Definition of nodes usart1_tx_pb6 and usart1_rx_pb7 could be provided manually but to assist
in board configuration, SoC variant package specific -pinctrl.dtsi files are provided and should
be included in the board dts files.

For instance, for board disco_l475_iot1:
 #include <st/l4/stm32l475Xg.dtsi>
+#include <st/l4/stm32l475r(c-e-g)tx-pinctrl.dtsi>
 #include "arduino_r3_connector.dtsi"

*-pinctrl.dtsi files provide known working pin configurations which could be overwritten at
board level to fit a specific need. These files are hosted in hal_stm32 module (under dts/st/),
one for each STM32 SoC package. These files are generated from STM32 .xml description files
(currently delivered in ST STM32CubeMx tool). Using the appropriate -pinctrl.dtsi file allows
benefiting from the full list of valid pinctrl nodes for a SoC package that is used on a board,
reducing the risk of pin misconfiguration.
The -pinctrl.dtsi generation script is also provided and could be used to add or modify pinctrl
node variants, or to provide a new set of -pinctrl.dtsi files if a new STM32 SoC shows up.

This new method could coexist with current pinmux.c configuration (beware of the pin conflicts
as usual, though). 

For now, PR #25996 only provides the tooling for dts based pin configuration. Only one driver
(STM32 serial) and 2 boards have been modified as proof of concept (cf PR for more details).
Next step is to extend its usage to existing STM32 boards and drivers. Target is to get rid of in
tree pinmux.c files for V2.5.0, so their usage could be deprecated.
I invite STM32 codeowners and contributors to help us in this task. Out of tree users are also
encouraged to perform this change on their respective boards.

Big thanks to Gerard Marull-Paretas (@gmarull) who helped me with this PR and provided the
pinctrl.dtsi files generation script.

Cheers
Erwan


RFC: API Change: k_work

Peter A. Bigot
 

In accordance with policy your attention is drawn to #28794 which summarizes and outlines the motivation for a change to the k_work infrastructure, specifically with how k_delayed_work functions behave.  These changes are motivated by #27356.

Please raise high level concerns in that issue, and the specific changes in #28589.

Peter


BLE data rate with IPSP #ble #nrf52480

Stefan Hristozov
 

Hi all,

I have a set up consisting of nRF52840 and Raspberry Pi4 communicating over IPSP. The nRF52840 application needs to send data with 6,4KByte/s. My nRF52840 prj.conf is:

# Thread Priorities
CONFIG_NUM_COOP_PRIORITIES=2
CONFIG_NUM_PREEMPT_PRIORITIES=3

# Timer
CONFIG_COUNTER=y

# PWM
CONFIG_PWM=y

# SPI
CONFIG_SPI=y

# Generic networking options
CONFIG_NETWORKING=y
CONFIG_NET_UDP=y
CONFIG_NEWLIB_LIBC=y

# Socket
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_SOCKETS_POLL_MAX=4

# CoAP
CONFIG_COAP=y
CONFIG_COAP_WELL_KNOWN_BLOCK_WISE=n

# Kernel options
CONFIG_ENTROPY_GENERATOR=y
CONFIG_TEST_RANDOM_GENERATOR=y

# Logging
CONFIG_PRINTK=y
CONFIG_NET_LOG=y

# # Network Shell
CONFIG_NET_SHELL=y

# Configuration
CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_BT_NODE=y
CONFIG_NET_MAX_CONTEXTS=6
CONFIG_NET_PKT_RX_COUNT=10
CONFIG_NET_PKT_TX_COUNT=10
CONFIG_NET_BUF_RX_COUNT=20
CONFIG_NET_BUF_TX_COUNT=20
CONFIG_NET_L2_BT=y

# IPv6 Support
CONFIG_NET_IPV4=n
CONFIG_NET_IPV6=y
CONFIG_NET_CONFIG_MY_IPV6_ADDR="2001:db8::1"
CONFIG_NET_CONFIG_PEER_IPV6_ADDR="2001:db8::2"

# RAM configuration
CONFIG_INIT_STACKS=y
CONFIG_MAIN_STACK_SIZE=10240
CONFIG_HEAP_MEM_POOL_SIZE=10240

# Configure Bluetooth LE
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=n
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CTLR_DATA_LENGTH_CLEAR=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_DEVICE_NAME="medisec-dev"

CONFIG_BT_DATA_LEN_UPDATE=y
CONFIG_BT_AUTO_DATA_LEN_UPDATE=y

CONFIG_BT_PERIPHERAL_PREF_MAX_INT=7
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=6
CONFIG_BT_L2CAP_TX_MTU=2000
CONFIG_BT_CTLR_PHY_2M=y


Unfortunately I get the following warning:
[00:00:20.695,800] <wrn> bt_l2cap: No credits to transmit packet

How to get rid of that?


BR
Stefan


ninja: error: loading 'build.ninja' - Windows

Kashyap Gada <gada.kashyap@...>
 

Dear All,

I tried to install basic zephyr installation from the getting started page on windows.

Everything installed fine. When I am trying to build sample blink project by calling -

west build -p auto -b nucleo_l053r8 samples\basic\blinky

I get the following error.

ninja: error: loading 'build.ninja': The system cannot find the file specified.

FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build 'D:\Software\zephyr\zephyrproject\zephyr\build'

Environment variables are set as per the toolchain tutorial

D:\Software\zephyr\zephyrproject\zephyr>echo %ZEPHYR_TOOLCHAIN_VARIANT%
gnuarmemb

D:\Software\zephyr\zephyrproject\zephyr>echo %GNUARMEMB_TOOLCHAIN_PATH%
C:\gnu_arm_embedded

I don't how to go ahead please help.

Regards
Kashyap


ninja: error when build in the share fold of VM #west

mfinmuch@...
 

I execute ubuntu18 in VM and test zephyr project is successful
However, since the program cannot be transferred under win, do zephyr project in the shared folder
But, west cannot create the build.ninja file in the build folder

I command on ubuntu 18 is successful
/zephyrproject/zephyr/samples/hello_world$ west build -p auto -b nrf52840dk_nrf52840

I command in share fold(/mnt/hgfs/..)
/mnt/hgfs/ble/zephyrproject/zephyr/samples/hello_world$ west build -p auto -b nrf52840dk_nrf52840
ninja: error: loading 'build.ninja': No such file or directory
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /mnt/hgfs/ble/zephyrproject/zephyr/samples/hello_world/build
 
and I check where two folds different, under /build it doesn't have build.ninja
How to solve the problem that make me can run the zephyr project in vm share fold


Read out channels on ADC3 #stm32 #api

robin@...
 

I'm running Zephyr OS on a stm32f429i-eval (similar to the stm32f429-disc1 except for the crystal). 

I've enabled &adc1 in my dts overlay. I would have expected a &adc2 and &adc3 for the other adc peripherals, but it seems like the adc1 device is also used to access those
It works OK if I, for example, read out channel 1 for adc1, or channel 14 on adc2.

But how do I read out channel 8 on ADC3 ( STM32F4_PINMUX_FUNC_PF10_ADC3_IN8 )

Is this not implemented or is there a naming convention I don't understand?

Sincerely,
Robin


Re: Problem with the NVS filesystem on #nrf52840 #nvs

Arnaud Mouiche
 

Are you in interruption context when trying to read/write in the callback ?
I doubt this is a good idea to access a filesystem from such place... (may sleep, may block...)
You should defer the read/write

see https://docs.zephyrproject.org/latest/reference/kernel/threads/workqueue.html#system-workqueue & co

Arnaud

Le 22/09/2020 à 14:26, Nikos Karamolegkos a écrit :
Update: if I write and read in a function without some condition (i.e button is pressed) works fine. The problem is when the write/read process is taking place to button_pressed callback function.


Re: Problem with the NVS filesystem on #nrf52840 #nvs

Nikos Karamolegkos
 

Update: if I write and read in a function without some condition (i.e button is pressed) works fine. The problem is when the write/read process is taking place to button_pressed callback function.


Problem with the NVS filesystem on #nrf52840 #nvs

Nikos Karamolegkos
 

Hello again,
I am following the NVS sample to create my own code in order to write to the NVS filesystem. The idea is to change a uint8 variable in the NVS when the button is pressed. Therefore, when the button is pressed I use the nvs_write function to change the variable value and the function returns 1(which means that one byte was written) . If I read the variable value after the write function I see the previous value of the variable. Is there any bug?


API meeting cancelled today

Carles Cufi
 

Hi all,

In order to focus on the release itself I have cancelled the API meeting today.

Next week it will take place as usual.

Regards,

Carles


Re: #ble #hci #usb #ble #hci #usb

Chettimada, Vinayak Kariappa
 

Hi,

 

  1. Zephyr open source controller does not support long range. The feature is under development by our contributors.
  2. The missing supported commands may be a bug, but on quick review I could find them to all implemented, you can review the implementation, create a GH issue and if possible contribute a Fix PR.
  3. The code, and the conditional configurations: https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L555

 

Regards,

Vinayak

 

From: users@... <users@...> On Behalf Of valens.dsilva via lists.zephyrproject.org
Sent: 22 September 2020 02:29
To: users@...
Subject: [Zephyr-users] #ble #hci #usb

 

Hi,

I am new to Zephyr and I'm trying to expose the LE PHY setting to a RPI Linux Host system. The controller is an nrf52840 dongle acting as a HCI USB device. The dongle will interact with the BLuez stack on the Pi (Bluez 5.55)

I have the following prj.conf setting which I took from this person https://devzone.nordicsemi.com/f/nordic-q-a/65679/zephyr-os---nrf52840-dongle-with-long-range?ReplySortBy=CreatedDate&ReplySortOrder=Descending

CONFIG_STDOUT_CONSOLE=y

CONFIG_GPIO=y

CONFIG_SERIAL=y

CONFIG_UART_INTERRUPT_DRIVEN=y

 

CONFIG_BT=y

CONFIG_BT_H4=y

CONFIG_BT_CTLR=y

CONFIG_BT_HCI=y

 

CONFIG_USB=y

CONFIG_USB_DEVICE_STACK=y

CONFIG_USB_DEVICE_BLUETOOTH=y

CONFIG_USB_DEVICE_BLUETOOTH_VS_H4=y

 

CONFIG_MAIN_STACK_SIZE=1024

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1024

 

CONFIG_BT_CTLR_RX_BUFFERS=18

CONFIG_BT_CTLR_TX_BUFFERS=19

CONFIG_BT_CTLR_TX_BUFFER_SIZE=251

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_HCI_CMD_COUNT=20

CONFIG_BT_RX_BUF_COUNT=20

CONFIG_BT_RX_BUF_LEN=258

CONFIG_BT_DISCARDABLE_BUF_SIZE=257

CONFIG_BT_MAX_CONN=24

 

CONFIG_BT_CTLR_PHY_CODED=y

CONFIG_BT_PHY_UPDATE=y

CONFIG_BT_AUTO_PHY_UPDATE=y

CONFIG_BT_LLL_VENDOR_NORDIC=y

CONFIG_BT_LL_SW_SPLIT=y

 

When I use btmon to list the supported commands of the adapter I do not see commands such as:

LE Read Maximum Data Length (Octet 35 - Bit 3)

LE Read PHY (Octet 35 - Bit 4)

LE Set Default PHY (Octet 35 - Bit 5)

LE Set PHY (Octet 35 - Bit 6)

LE Read Transmit Power (Octet 38 - Bit 7)

LE Set Privacy Mode (Octet 39 - Bit 2)


Can someone point me to missing CONFIG values I need?
Thanks


#ble #hci #usb #ble #hci #usb

valens.dsilva@...
 

Hi,

I am new to Zephyr and I'm trying to expose the LE PHY setting to a RPI Linux Host system. The controller is an nrf52840 dongle acting as a HCI USB device. The dongle will interact with the BLuez stack on the Pi (Bluez 5.55)

I have the following prj.conf setting which I took from this person https://devzone.nordicsemi.com/f/nordic-q-a/65679/zephyr-os---nrf52840-dongle-with-long-range?ReplySortBy=CreatedDate&ReplySortOrder=Descending
CONFIG_STDOUT_CONSOLE=y
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
 
CONFIG_BT=y
CONFIG_BT_H4=y
CONFIG_BT_CTLR=y
CONFIG_BT_HCI=y
 
CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_BLUETOOTH=y
CONFIG_USB_DEVICE_BLUETOOTH_VS_H4=y
 
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1024
 
CONFIG_BT_CTLR_RX_BUFFERS=18
CONFIG_BT_CTLR_TX_BUFFERS=19
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_HCI_CMD_COUNT=20
CONFIG_BT_RX_BUF_COUNT=20
CONFIG_BT_RX_BUF_LEN=258
CONFIG_BT_DISCARDABLE_BUF_SIZE=257
CONFIG_BT_MAX_CONN=24
 
CONFIG_BT_CTLR_PHY_CODED=y
CONFIG_BT_PHY_UPDATE=y
CONFIG_BT_AUTO_PHY_UPDATE=y
CONFIG_BT_LLL_VENDOR_NORDIC=y
CONFIG_BT_LL_SW_SPLIT=y
 
When I use btmon to list the supported commands of the adapter I do not see commands such as:
LE Read Maximum Data Length (Octet 35 - Bit 3)
LE Read PHY (Octet 35 - Bit 4)
LE Set Default PHY (Octet 35 - Bit 5)
LE Set PHY (Octet 35 - Bit 6)
LE Read Transmit Power (Octet 38 - Bit 7)
LE Set Privacy Mode (Octet 39 - Bit 2)

Can someone point me to missing CONFIG values I need?
Thanks


LIS2DW12 over SPI on nRF9160 #driver #sensor #spi #lis2dw12 #nrf9160

p.swenson@...
 
Edited

Using: Windows 10, nRF Connect v3.5.0, SES v4.52, ncs v1.3.0, zephyr v2.3.0

I have a custom board based on the Nordic Thingy91 and the Asset Tracker application. There is also an LIS2DW12 present on SPI.  In "prj.conf", I added these lines:

 
CONFIG_SENSOR=y
CONFIG_TEMP_USE_EXTERNAL=y
CONFIG_TEMP_USE_SIM=n
CONFIG_SENSOR_SIM=n
CONFIG_SPI=y
CONFIG_SPI_NRFX=y
CONFIG_SPI_3=y
CONFIG_ACCEL_USE_EXTERNAL=y
CONFIG_LIS2DW12=y
CONFIG_ACCEL_DEV_NAME="LIS2DW12"
CONFIG_LIS2DW12_ODR_1_6=y
CONFIG_LIS2DW12_ACCEL_RANGE_2G=y

I modified the Thingy91 board devicetree file "thingy91_nrf9160_common.dts":

&spi3 {
compatible = "nordic,nrf-spim";
status = "okay";
sck-pin = <16>;
mosi-pin = <13>;
miso-pin = <14>;
cs-gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
 
lis2dw12 {
compatible = "stm,lis2dw12";
label = "LIS2DW12";
spi-max-frequency = <10000000>;
int1-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
};
};
 
In "lis2dw12.c", I added these lines to the top:

#define DT_DRV_COMPAT stm_lis2dw12
#define LIS2DW12 DT_INST(0, stm_lis2dw12)

In SES, it builds quite far, but I get an error:

C:/engr/ncs/v1.3.0/zephyr/drivers/sensor/lis2dw12/lis2dw12.c:227: undefined reference to `lis2dw12_spi_init'

In "lis2dw12.c", this section is grayed out:

#if DT_ANY_INST_ON_BUS_STATUS_OKAY(spi)
#include <drivers/spi.h>
#elif DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c)
#include <drivers/i2c.h>
#endif
 

Which means it never includes the spi.h file.  What am I missing?  I can force the issue, but it just shifts the problem and doesn't solve it.


Re: FIFO is not empty after getting all data items; reference pointer still points to another item

Carles Cufi
 

The reason that Zephyr does not copy the items to the list is that it offers primitives that copy them (message queues) and primitives that do not (FIFOs). Then you can use FIFOs if you have your own allocation scheme that is optimized for your usecase, and message queues if you want the kernel to handle that for you.

 

Carles

 

From: users@... <users@...> On Behalf Of Weber, Dominik via lists.zephyrproject.org
Sent: 17 September 2020 16:57
To: Cufi, Carles <Carles.Cufi@...>; users@...
Subject: Re: [Zephyr-users] FIFO is not empty after getting all data items; reference pointer still points to another item

 

Hi Carles,

 

thanks for your reply. This solved my problem.

 

But why does Zephyr not copy the items to the list? For me, there’s absolutely no reason to NOT copy data items to a queue . It runs the risk to…  

  • … put data items to the queue which are on the stack of a function or an ISR. Thus, these elements would be not valid anymore when the function returns. This is a major security issue, since you won’t be able to recognize the error until it will be overwritten randomly in memory…
  • … put the same data item several times to the queue which has the same memory address but different content (which was actually my problem)

Furthermore I would need a separate buffer to store my queue items, if I only put pointers to the queue. So one of the main features of a queue would be obsolete.

 

(The way FreeRTOS does it, is way more intuitive for me: https://www.freertos.org/Embedded-RTOS-Queues.html)

 

Best Regards,

Dominik

 

Von: Cufi, Carles <Carles.Cufi@...>
Gesendet: Freitag, 28. August 2020 16:29
An: Weber, Dominik <dominik.weber@iis.fraunhofer.de
>; users@...
Betreff: RE: FIFO is not empty after getting all data items; reference pointer still points to another item

 

Hi Dominik,

 

>. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

 

FIFOs do not copy the contents of the message, they only store the pointer in a linked list. Maybe this is not clear enough in the documentation, please consider sending a Pull Request enhancing the doc.

 

If you need the kernel to copy the contents of your message for you, you can use Message Queues:

https://docs.zephyrproject.org/latest/reference/kernel/data_passing/message_queues.html

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Weber, Dominik via lists.zephyrproject.org
Sent: 28 August 2020 13:22
To: users@...
Subject: [Zephyr-users] FIFO is not empty after getting all data items; reference pointer still points to another item

 

Hey everyone,

 

I’m currently having problems when putting items to a FIFO. As long as I put data items to my FIFO queue, everything is ok and works as expected. If I stop putting data to the queue, the reading thread continues reading the last data item out of the queue over and over again, although the queue should be empty but is not (k_fifo_is_empty() says it’s not empty).

 

There’s a writing and a reading thread in my software project.

 

I have the following data item, defined in the header file of the reading thread:

 

typedef struct

{

    void *fifoReserved;     ///< 1st word reserved for use by fifo

    int data1;               

    int data2;              

 

s_data_item_fifo_ecg_t;

 

 

 

 

The writing thread is like:

 

(This is a static variable in the software module)

static s_data_item_fifo_ecg_t ecgDataStruct;  ///< This data item contains the ecg information to put to the data fifo.

 

(Inside the thread)

while (1)

    {

        /* Thread will be unready until signal was raised, signal will be raised when data ready interrupt comes */

        k_poll(daEvents1, K_FOREVER);

 

        /* Reset signal */

        daEvents[0].signal->signaled = 0;

        daEvents[0].state = K_POLL_STATE_NOT_READY;

 

        /* …get data from hardware chip here… */

 

        ecgDataStruct.data1 = ;

        ecgDataStruct.data2 = ;

 

        dataProcessingPutFifoECG(&ecgDataStruct);

    }

 

The last function is part of the reading thread software module and just puts the item to the queue with k_fifo_put().

 

 

 

The reading thread is like:

 

(This is a static variable in the software module)

static struct k_fifo dpFifoECG;      ///< FIFO structure for handling incoming ECG data

 

There is an init function, where this is called:

k_fifo_init(&dpFifoECG);

 

 

s_data_item_fifo_ecg_t *fifoDataECG;

 

    while (1

    {

        /* Get data from queue. */

        fifoDataECG = k_fifo_get(&dpFifoECG, K_FOREVER);

 

        printk("%d,%d\n"fifoDataECG->data1fifoDataECG->data2);

 

    }

 

I checked the print outputs with a terminal program and realized that the data is still printed, even if I stop the measurement and stop putting data to the queue, which means that the program is not waiting at k_fifo_get() as expected. It just continues reading the last item which should be removed from the queue.

 

When I have a look at the fifoReserved pointer for these unwanted items, I see that the pointer is always the same and not NULL. Shouldn’t the pointer be NULL if there are no more items in the list?

 

This is really driving me crazy.

 

Both threads do have a maximum memory thread stack size of 8kB.

 

The priorities are -2 for the writing thread (implements SPI communication) and 1 for the reading thread. (There are three threads running on the system, excluding main thread and idle thread).

 

A general question:

 

For me, it is not really clear, if a data item is passed by copy or by reference to the fifo queue. I assume, the items are passed by reference, since I faced some serious problems when passing data items from an ISR, which are lying on the ISR stack. The content of the data item was sometimes different after reading the item compared to when the item was putted to the queue. The solution to this problem was to define a static data item on the memory heap of the software module and to only adjust the data of the same item and put it again to the queue. This seems very unintuitive to me, since I put the same item to the queue over and over again, only with different content. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

 

My setup:

  • Zephyr 2.3 Build 99
  • Nordic nRF52840 DK
  • Segger J-Link OB-SAM3U128-V2-NordicSemi
  • Eclipse 2019-09
  • Python 3.8.3
  • West 0.7.2
  • C compiler GNU 9.2.1

 

Thanks for your help!

 


Re: FIFO is not empty after getting all data items; reference pointer still points to another item

Weber, Dominik <dominik.weber@...>
 

Hi Carles,

 

thanks for your reply. This solved my problem.

 

But why does Zephyr not copy the items to the list? For me, there’s absolutely no reason to NOT copy data items to a queue . It runs the risk to…  

·         … put data items to the queue which are on the stack of a function or an ISR. Thus, these elements would be not valid anymore when the function returns. This is a major security issue, since you won’t be able to recognize the error until it will be overwritten randomly in memory…

·         … put the same data item several times to the queue which has the same memory address but different content (which was actually my problem)

Furthermore I would need a separate buffer to store my queue items, if I only put pointers to the queue. So one of the main features of a queue would be obsolete.

 

(The way FreeRTOS does it, is way more intuitive for me: https://www.freertos.org/Embedded-RTOS-Queues.html)

 

Best Regards,

Dominik

 

Von: Cufi, Carles <Carles.Cufi@...>
Gesendet: Freitag, 28. August 2020 16:29
An: Weber, Dominik <dominik.weber@iis
.fraunhofer.de>; users@...
Betreff: RE: FIFO is not empty after getting all data items; reference pointer still points to another item

 

Hi Dominik,

 

>. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

 

FIFOs do not copy the contents of the message, they only store the pointer in a linked list. Maybe this is not clear enough in the documentation, please consider sending a Pull Request enhancing the doc.

 

If you need the kernel to copy the contents of your message for you, you can use Message Queues:

https://docs.zephyrproject.org/latest/reference/kernel/data_passing/message_queues.html

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Weber, Dominik via lists.zephyrproject.org
Sent: 28 August 2020 13:22
To: users@...
Subject: [Zephyr-users] FIFO is not empty after getting all data items; reference pointer still points to another item

 

Hey everyone,

 

I’m currently having problems when putting items to a FIFO. As long as I put data items to my FIFO queue, everything is ok and works as expected. If I stop putting data to the queue, the reading thread continues reading the last data item out of the queue over and over again, although the queue should be empty but is not (k_fifo_is_empty() says it’s not empty).

 

There’s a writing and a reading thread in my software project.

 

I have the following data item, defined in the header file of the reading thread:

 

typedef struct

{

    void *fifoReserved;     ///< 1st word reserved for use by fifo

    int data1;               

    int data2;              

 

s_data_item_fifo_ecg_t;

 

 

 

 

The writing thread is like:

 

(This is a static variable in the software module)

static s_data_item_fifo_ecg_t ecgDataStruct;  ///< This data item contains the ecg information to put to the data fifo.

 

(Inside the thread)

while (1)

    {

        /* Thread will be unready until signal was raised, signal will be raised when data ready interrupt comes */

        k_poll(daEvents1, K_FOREVER);

 

        /* Reset signal */

        daEvents[0].signal->signaled = 0;

        daEvents[0].state = K_POLL_STATE_NOT_READY;

 

        /* …get data from hardware chip here… */

 

        ecgDataStruct.data1 = ;

        ecgDataStruct.data2 = ;

 

        dataProcessingPutFifoECG(&ecgDataStruct);

    }

 

The last function is part of the reading thread software module and just puts the item to the queue with k_fifo_put().

 

 

 

The reading thread is like:

 

(This is a static variable in the software module)

static struct k_fifo dpFifoECG;      ///< FIFO structure for handling incoming ECG data

 

There is an init function, where this is called:

k_fifo_init(&dpFifoECG);

 

 

s_data_item_fifo_ecg_t *fifoDataECG;

 

    while (1

    {

        /* Get data from queue. */

        fifoDataECG = k_fifo_get(&dpFifoECG, K_FOREVER);

 

        printk("%d,%d\n"fifoDataECG->data1fifoDataECG->data2);

 

    }

 

I checked the print outputs with a terminal program and realized that the data is still printed, even if I stop the measurement and stop putting data to the queue, which means that the program is not waiting at k_fifo_get() as expected. It just continues reading the last item which should be removed from the queue.

 

When I have a look at the fifoReserved pointer for these unwanted items, I see that the pointer is always the same and not NULL. Shouldn’t the pointer be NULL if there are no more items in the list?

 

This is really driving me crazy.

 

Both threads do have a maximum memory thread stack size of 8kB.

 

The priorities are -2 for the writing thread (implements SPI communication) and 1 for the reading thread. (There are three threads running on the system, excluding main thread and idle thread).

 

A general question:

 

For me, it is not really clear, if a data item is passed by copy or by reference to the fifo queue. I assume, the items are passed by reference, since I faced some serious problems when passing data items from an ISR, which are lying on the ISR stack. The content of the data item was sometimes different after reading the item compared to when the item was putted to the queue. The solution to this problem was to define a static data item on the memory heap of the software module and to only adjust the data of the same item and put it again to the queue. This seems very unintuitive to me, since I put the same item to the queue over and over again, only with different content. Is there a reason why Zephyr does not copy the items to the queue like FreeRTOS does it? The Zephyr documentation lacks this kind of information!

 

My setup:

  • Zephyr 2.3 Build 99
  • Nordic nRF52840 DK
  • Segger J-Link OB-SAM3U128-V2-NordicSemi
  • Eclipse 2019-09
  • Python 3.8.3
  • West 0.7.2
  • C compiler GNU 9.2.1

 

Thanks for your help!

 

461 - 480 of 2705