Date   

Re: Bluetooth services/features

Tamra <tamrako@...>
 

Thanks Carles. I’ll look into that now.


On Wed, Jun 20, 2018 at 9:19 PM Cufi, Carles <Carles.Cufi@...> wrote:

GATT is the profile and ATT the protocol. That’s what you use in BLE to discover services and interact with values.

 

Carles

 

From: Tamra Oyama <tamrako@...>
Sent: 21 June 2018 09:00
To: Cufi, Carles <carles.cufi@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Bluetooth services/features

 

Low energy. What would be that function/protocol?

 

On Wed, Jun 20, 2018 at 8:59 PM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Tamra,

 

Are you looking to use classical Bluetooth or Bluetooth Low Energy? SDP is a classical Bluetooth protocol.

 

Carles

 

From: <devel@...> on behalf of Tamra <tamrako@...>
Date: Thursday, 21 June 2018 at 03:14
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Bluetooth services/features

 

Hi Zephyr Team,

 

I'm trying to find out what services bluetooth devices have just by scanning without making a connection with the device, similarly to the scan_cb function and print these services/features. Is there a function that does this? I've looked at the bt_sdp_get_features function but got stuck when I couldn't find where the struct, bt_sdp_client_result was defined.

 

Any help or advice would be greatly appreciated!

 

Thank you,

Tamra


Re: Bluetooth services/features

Carles Cufi
 

GATT is the profile and ATT the protocol. That’s what you use in BLE to discover services and interact with values.

 

Carles

 

From: Tamra Oyama <tamrako@...>
Sent: 21 June 2018 09:00
To: Cufi, Carles <carles.cufi@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Bluetooth services/features

 

Low energy. What would be that function/protocol?

 

On Wed, Jun 20, 2018 at 8:59 PM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Tamra,

 

Are you looking to use classical Bluetooth or Bluetooth Low Energy? SDP is a classical Bluetooth protocol.

 

Carles

 

From: <devel@...> on behalf of Tamra <tamrako@...>
Date: Thursday, 21 June 2018 at 03:14
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Bluetooth services/features

 

Hi Zephyr Team,

 

I'm trying to find out what services bluetooth devices have just by scanning without making a connection with the device, similarly to the scan_cb function and print these services/features. Is there a function that does this? I've looked at the bt_sdp_get_features function but got stuck when I couldn't find where the struct, bt_sdp_client_result was defined.

 

Any help or advice would be greatly appreciated!

 

Thank you,

Tamra


Re: Memory Optimization for Nordic Boards

Kai Ren
 

Hi Ryan,

As I know, Thingy uses nrf52832, the RAM is 32/64KB and the flash is 256 or 512KB. https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.rds%2Fdita%2Frds%2Fdesigns%2Fthingy%2Fintro%2Ffrontpage.html 


I had ever optimized RAM usage on Zephyr to nRF51, I think you need to review the prj.conf file to disable the functions you won't use, maybe you need to review the code in ./subsys/, just my humble opinion. 

Kai


Bluetooth services/features

Tamra <tamrako@...>
 

Hi Zephyr Team,

I'm trying to find out what services bluetooth devices have just by scanning without making a connection with the device, similarly to the scan_cb function and print these services/features. Is there a function that does this? I've looked at the bt_sdp_get_features function but got stuck when I couldn't find where the struct, bt_sdp_client_result was defined.

Any help or advice would be greatly appreciated!

Thank you,
Tamra


Zephyr development news, 19 June 2018

Marti Bolivar
 

Hello,

This is the 19 June 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

An HTML version is available here:

https://opensourcefoundries.com/blog/2018/06/19/zephyr-news-20180619/

As usual, content is broken down as follows:

- Highlights
- Important changes: ABI/API breaks and some features
- New features: non-exhaustive descriptions of new features
- Bug fixes: non-exhaustive list of fixed bugs
- Individual changes: a complete list of patches, sorted
chronologically and categorized into areas, like:
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

The floodgates are open with the beginning of the v1.13 merge
window. This newsletter covers the following inclusive commit range:

- 0f9a6426 ("release: Post-release patch level update"), merged
11 June 2018
- fb6f9b78 ("ext: Kconfig: Remove redundant 'default n' properties"),
merged 18 June 2018

Important Changes
-----------------

CONF_FILE can now be a CMake list:

Most Zephyr users will likely recognize the CMake variable CONF_FILE,
which can be used to set the path to the top-level application Kconfig
fragment. (Normally, this defaults to prj.conf.)

A longstanding but lesser-known feature is that CONF_FILE can also
be a whitespace-separated list of fragments; these will all be merged
into the final configuration. Some samples use this feature to add
board-specific "mix-ins" to the top-level prj.conf; see the
led_ws2812 CMakeLists.txt for an example:

https://github.com/zephyrproject-rtos/zephyr/blob/fb6f9b78c9094ca9ae7cc16aa43eb1988ba18440/samples/drivers/led_ws2812/CMakeLists.txt

The "whitespace-separated" part of this feature is a holdover from
when Zephyr used the Linux kernel's Makefile build system,
Kbuild. Since moving to CMake, the whitespace separation has been a
little bit less convenient, as CMake uses semicolon-separated strings
as its internal "list" data type.

To make this feature cleaner in the new world order, CONF_FILE now
also supports separation via semicolons. The old whitespace separation
behavior is not affected to keep backwards compatibility. For example,
setting the following at the CMake command line would merge the three
fragments hello.conf, world.conf, and zephyr.conf into the final
.config:

-DCONF_FILE="hello.conf;world.conf zephyr.conf"

PWM on STM32:

Device tree bindings were added for timers and PWM devices on STM32
targets. A large variety of STM32 targets (F0, F1, F3, F4, and L4
families) now have such nodes added on a per-SoC basis. Many of the
official boards produced by STMicroelectronics now have PWM enabled.

The old Kconfig options (CONFIG_PWM_STM32_x_DEV_NAME, etc.) have
been removed. Applications using PWM on STM32 may need updates to
reflect this switch to device tree.

UART on nRF:

The UART driver for nRF devices has been refactored to use the vendor
HAL. This change was followed by a large tree-wide rename of the
Kconfig options: CONFIG_UART_NRF5 was renamed to CONFIG_UART_NRFX,
and CONFIG_UART_NRF5_xxx options were renamed to
CONFIG_UART_0_NRF_xxx.

Applications using this driver may need updates.

Many Kconfig warnings are now errors:

The tree-wide cleanups and improvements to Zephyr's usage of Kconfig
continues as Kconfiglib grows more features. Notably, many warnings
are now errors, improving the rate at which CI catches Kconfig
issues.

Features
--------

Arches:

The work to enable Arm v8-M SoCs, some of which include support for
"secure" and "non-secure" execution states, continues. There is a new
CONFIG_ARM_NONSECURE_FIRMWARE option, which signals that the
application being built is targeting the non-secure execution
state. This depends on a new hidden CONFIG_ARMV8_M_SE option, which
SoCs can select to signal that hardware support for this feature is
present. This was followed with infrastructure APIs related to address
accessibility and interrupt management in secure and non-secure
contexts.

The native POSIX "architecture" now supports -rt and -no-rt
command line options, which allow deferring the decision for whether
execution should be slowed down to real time to runtime. (The option
CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME now determines the default
value.) More information on using Zephyr's POSIX target is here:

http://docs.zephyrproject.org/boards/posix/native_posix/doc/board.html

Bluetooth:

There is a new choice option for controlling the transmit power:

http://docs.zephyrproject.org/reference/kconfig/choice_149.html

On Linux hosts, the native POSIX target can now access the kernel
Bluetooth stack via a new HCI driver, which can be enabled with
CONFIG_BT_USERCHAN.

The Bluetooth mesh sample application
samples/boards/nrf52/mesh/onoff-app now supports the persistent
storage API introduced in v1.12. This allows the application to rejoin
the same network if the board is reset.

The host stack now supports more flexible choices for how to pass
attributes to bt_gatt_notify().

Boards:

The frdm_kl25z board now supports USB.

Nordic board Kconfig files can now select CONFIG_BOARD_HAS_DCDC,
which will enable the DC/DC converter.

Build:

There is a new CONFIG_SPEED_OPTIMIZATIONS flag, which requests the
build system to optimize for speed. (The default is to optimize for
binary size.)

The warning output for when the value a user sets for a Kconfig option
differs from the actual value has been improved.

Documentation:

Zephyr's Kconfig documentation now includes output for choices. For
example, here is the page documenting the architecture choice:

http://docs.zephyrproject.org/reference/kconfig/choice_0.html#choice-0

Device Tree:

The RISCV32 QEMU target now has DT support for flash, SRAM, and UART.

nRF52 SoCs now have device tree support for GPIO.

Drivers:

A variety of nRF peripheral accesses throughout the tree were replaced
with calls to inline accessors in the vendor HAL. The stated reason
given is to enable easier testing.

The nRF PWM driver now has prescaler support.

The mcux Ethernet driver now uses the carrier detection API calls
described below in the new networking features.

A new driver for the TI SimpleLink WiFi offload chip was merged; so
far, this only supports the network management commands related to
WiFi which were introduced for v1.12 (see include/net/wifi_mgmt.h
for details).

A variety of USB-related changes were merged.

The USB subsystem now sports new USBD_DESCR_xxx_DEFINE macros for
declaring descriptors of various types; behind the scenes, these use
linker magic to ensure that the defined descriptors end up in
contiguous memory. This allowed migrating descriptors formerly defined
in an increasingly large subsys/usb/usb_descriptor.c into the files
for the individual USB classes, etc. that defined them.

As all Zephyr USB controllers support USB v2.0, the USB protocol
version reported in the device descriptor has been updated to that
value, increasing it from its former setting of v1.1.

The HID interrupt endpoint size configuration option
CONFIG_HID_INTERRUPT_EP_MPS is now visible and thus configurable by
applications.

Interface descriptors are now configurable at runtime.

Networking:

Ethernet drivers can now signal detection and loss of a carrier via
new net_eth_carrier_on() and net_eth_carrier_off() routines. This is
used by the network management APIs to generate interface "up" and
"down" events.

http://docs.zephyrproject.org/subsystems/networking/network-management-api.html

The DHCP implementation uses these events to obtain new addresses when
a network interface reappears after going down.

The network shell's conn command now unconditionally prints the
state of each TCP connection.

A variety of performance improvements were merged into the networking
layer; these speed things up by avoiding unnecessary work, like
duplicated filling in of packet headers and checksums. Better
management of some internal caches when multiple networking interfaces
are running on board was also merged.

Samples:

The BBC micro:bit now supports servomotors; see samples/basic/servo_motor.

Scripts:

A variety of updates were merged to the Kconfiglib dependency vendored
into Zephyr, along with its users; these are mostly related to
hardening warnings into errors and improving error and warning output.

Testing:

The long-ranging work on issue 6991:

https://github.com/zephyrproject-rtos/zephyr/issues/6991

continues with several samples being refactored, moved or otherwise
cleaned up to better fit in a test management system.

Bug Fixes
---------

Arches:

The PendSV interrupt handler on ARM now prevents other operating
system interrupts from running before accessing kernel state,
preventing races.

Bluetooth:

The USB Bluetooth device class implementation saw a few
fixes. Notably, it now has a transmit thread as well as a receive
thread, fixing an issue where bt_send() was incorrectly called
from interrupt context, and properly reserves some headroom needed in
its net_buf structures.

Build:

The CONFIG_COMPILER_OPT option now allows setting multiple compiler
options, separated by whitespace.

Numerous fixes and updates were merged affecting usage of Kconfig
options throughout the tree.

The "minimal" C library that ships with Zephyr is no longer built as
part of the "app" target, which is reserved as much as possible for
user applications. Any applications that may have been relying on this
behavior may need updates, as the C library is now part of its own
Zephyr library.

Drivers:

Bluetooth drivers now have access to bt_hci_cmd_send() and
bt_hci_cmd_send_sync() routines via <hci.h>; allowing them to,
well, send HCI commands. HCI drivers can now also declare "quirks", or
deviations from standard behavior, with BT_QUIRK_NO_RESET being the
first user.

The Nordic RTC timer driver saw a fix for the number of hardware
cycles per tick; the PWM driver also has improved accuracy after a
clock frequency fix.

A build issue in the Bluetooth HCI implementation using SPI as a
transport was fixed.

The lis2dh accelerometer driver seems to be working again, after
seeing build breakage and I2C protocol usage fixes.

Kernel:

A fix was merged partially restoring the behavior of
CONFIG_MULTITHREADING=n following the scheduler rewrite. (Some
former behavior related to semaphores was not restored, forcing flash
drivers elsewhere in the tree to behave differently depending on
whether this option is enabled.)

A race condition which could cause k_poll() to return NULL when a
timeout is set has been fixed.

Networking:

The TCP stack now properly responds to Zero Window Probe segments (see
https://tools.ietf.org/html/rfc6429 for details on these).

Some use-after free bugs in network statistics calculations were fixed.

IPv4 and UDP checksums are now calculated only when needed in the DHCPv4 core.

Samples:

The mbedtls_sslclient networking sample now uses a hardware
entropy source at system startup to seed the random number generator
when one is available, rather than relying on sys_rand32_get(),
which doesn't guarantee cryptographically strong output.

Individual Changes
==================

Patches by area (226 patches total):

- Arches: 26
- Bluetooth: 25
- Boards: 5
- Build: 14
- Continuous Integration: 2
- Device Tree: 11
- Documentation: 12
- Drivers: 59
- External: 3
- Kernel: 5
- Libraries: 2
- Miscellaneous: 3
- Networking: 27
- Samples: 12
- Scripts: 11
- Storage: 1
- Testing: 8

Arches (26):

- a7de06a6 native_posix: irq_offload to use a sw interrupt
- 477b5497 native: Add command line options to control real timeness
- ab81d2c7 arch: arm: block ARM_MPU K-option in Cortex-M0
- 7b56b448 arch: arm: accelerate _get_num_regions() for Cortex-M0+, M3, and M4
- dbede45d arch: arm: improve inline comment in _arm_mpu_config/enable
- 61439b01 arch: arm: remove redundant flag
- 41070c3b arch/arm: Fix locking in __pendsv
- 8c53f242 arch: arm: set VECTOR_ADDRESS to _vector_start
- 28007296 arch/stm32: remove irq definition files
- 3a87e0ed native: Fix entropy generator kconfig warning
- ebbb744b native: Fix host BT driver kconfig warning
- 070c1ae0 soc: nRF52x: Add Kconfig options to enable DC/DC converter
- f177fb88 arch: arc: Fix reference to removed NSIM Kconfig symbol
- 77643677 esp32: update to ESP-IDF v3.0-dev-2648-gb2ff235b
- 31aa9b9a arch: arm: atmel_sam: Use a single RAM region when possible
- e86c53b4 arch: arm: atmel_sam: Map the whole RAM in MPU
- bb55155d arch: arm: core: cortex_m: add a barrier before the dummy
FP instruction
- 158ea44e arch: arm: improve help text for ARM_SECURE_FIRMWARE
- dd640f14 arch: arm: introduce ARM_NONSECURE_FIRMWARE option
- 13dc3762 arch: arm: introduce ARMV8_M_SE option
- 0a2dcaaf arch: arm: introduce dependencies for CPU_CORTEX_M_HAS_SPLIM option
- f630559e arch: arm: Define and implement API for test target (Secure)
- d426adcc arch: arm: refactor function to align with the adopted api
- 87936612 arch: arm: implement cmse address range check (secure)
- fe3cd4c8 arch: arm: convenience wrappers for C variable Non-Secure permissions
- 7a864bb7 arch: arm: define and implement ARM IRQ target state API

Bluetooth (25):

- c3edc82f Bluetooth: GATT: Allow Characterist to be used with bt_gatt_notify
- 679a0b39 Bluetooth: GATT: Allow Characterist to be used with bt_gatt_indicate
- 68de9d5d Bluetooth: Use Characteristic attribute whenever possible
- 7d989657 Bluetooth: Add HCI User Channel driver for native POSIX port
- ea5b8667 Bluetooth: hci: spi: Select BT_RECV_IS_RX_THREAD
- edb2ad11 Bluetooth: controller: Remove redundant include of cmsis.h
- dc95e1ba Bluetooth: controller: Add Tx Power Kconfig option
- 362a6b34 Bluetooth: controller: Fix to use max. tx power in DTM test mode
- bb4ed94c bluetooth: tester: Increase system workqueue stack size
- e1b77247 Bluetooth: GATT: Fix notifications
- b1b10171 Bluetooth: Export HCI command APIs through public hci.h header file
- b20aff2f Bluetooth: Introduce HCI driver quirks
- 660c5c92 Bluetooth: controller: Remove include guards in internal files
- 37e6162c bluetooth: tester: Fix bt_gatt_service_register call with
invalid params
- 3904442e bluetooth: tester: Remove redundant config option from qemu.conf
- aa190cd5 bluetooth: tester: Set configuration file for qemu_cortex_m3 target
- 48b7f236 Bluetooth: Fix assertion condition in bt_gatt_discover
- bc606d22 Bluetooth: controller: Use nRFx functions for RTC reg with
sideeffects
- 347f3262 Bluetooth: controller: Use nRFx functions for ECB reg with sideeffect
- 17429725 Bluetooth: controller: Use SOC series macro instead of board macro
- 5f146e49 Bluetooth: controller: Use SOC series macro instead of the
board macro
- 88f0fbdc Bluetooth: controller: Use nRFx functions for RTC reg w sideeffects
- 1c5bb494 Bluetooth: controller: Use nRFx functions for CCM reg w sideeffects
- c97645c8 Bluetooth: controller: Use nRFx functions for TIMER reg w sideeffects
- 15ae4fa3 Bluetooth: controller: Use nRFx functions for PPI reg with sideef

Boards (5):

- fb3aedde boards: lpcxpresso54114_m0: do not set as default
- a58043e1 boards: cc3220sf_launchxl: Restore removal of CONFIG_XIP setting
- 558eac2f boards: arm: stm32: Added pwm to supported list
- 2055b84f boards: frdm_kl25z: add USB support
- 74c44b29 boards: arm: nrf52840: default IEEE802154_NRF5 if IEEE802154 enabled

Build (14):

- d94231f6 cmake: libc: minimal: Move sources from 'app' to a new CMake library
- 025a1e90 cmake: fix CONF_FILE parsing to allow for cmake lists
- ee9af86f cmake: Improve user error feedback when -H$ZEPHYR_BASE is specified
- a74e80fa cmake: Removing the need for always rebuild
- f38e388a cmake: Update to dependency handling for syscalls.json
- 8f3fea30 cmake: bluetooth: Don't #include gatt files from src files
- 7f5203d3 kconfig: Remove UART_QMSI_{0,1}_NAME Kconfig reference
- 2e0af08e build: remove unused CMakeLists.txt
- d62117e5 kconfig: Change how BT affects SYSTEM_WORKQUEUE_PRIORITY
- b35a41f9 include: linker: add sections for USB device stack
- 5bfc7ff2 kconfig: Fail in CI if Kconfig files reference undefined symbols
- 92a6898b cmake: allow multiple compiler options
- e8413d18 kconfig: add a compiler speed optimization
- 3c1a78ea cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE

Continuous Integration (2):

- 33fa63e4 sanitycheck: Add progress to verbose mode
- 5dce5ea5 ci: user latest docker file

Device Tree (11):

- e5b0e9ac DTS: interrupt controller: Define IRQ priorities for CAVS & DW ICTL
- 4ec773f2 DTS: intel_s1000: Clean up I2C and UART stuff from soc.h
- 71e66f06 dts: stm32: Add Timer and PWM binding
- 0e8d97f1 dts: stm32f0: Add PWM nodes
- da0caab3 dts: stm32f1: Add PWM nodes
- bfa1941e dts: stm32f3: Add PWM nodes
- 7a60a2c4 dts: stm32f4: Add PWM nodes
- c7d2dc23 dts: stm32l4: Add PWM nodes
- 5c6ccf4a dts: stm32: Enable PWM nodes on selected boards
- b7c4c030 dts: riscv32: riscv32-qemu: Add device tree support
- 0824ec64 dt: nrf52840: remove 0x from USBD address

Documentation (12):

- 5917f9b6 doc: Makefile: Remove CONFIG_SHELL assignment
- 953dfe75 doc: Makefile: Remove the 'doxy-code' target
- fa121da1 doc: Makefile: Remove the 'prep' target
- 9af9b1fb doc: Makefile: Lowercase internal Make variables
- a760c5b0 doc: Makefile: Remove latex_paper_size (PAPER) option
- 4dcf928a doc: fix doxygen error for device.h macros
- 92f146ea doc: update application docs wrt CONF_FILE
- ef75956d doc: update known-issues filter
- f5e38130 docs: Fix mailbox k_mbox_msg.tx_block documentation
- d901add4 doc: update .gitignore file list
- a3d83ec9 doc: update doc build tools documentation
- de6d61d1 doc: remove local copy of jquery.js

Drivers (59):

- e16037d8 drivers: sensor: lis2dh: Fix of compilation issue
- 87bd2c25 drivers: sensor: lis2dh: Fix I2C burst read/write operations
- e7206318 drivers: eth: mcux: Inform IP stack when carrier is lost
- 51fecf80 usb: bluetooth: Add TX thread
- 00a6b4c5 usb: bluetooth: Fix assert due to unreserved headroom
- 452cb618 usb: bluetooth: Use transfer API for ACL packets
- 1ce6a6ea subsys: usb: update bcdUSB to 2.00
- 7b7784e1 drivers: dma_cavs: Add support for circular list
- 3f3a907b drivers: timer: Use sys_clock_hw_cycles_per_tick in nrf_rtc_timer.
- c524ff6b subsys: console: getchar: Use consistent var names for RX path
- 0bdcef9e pwm: stm32: Use macro to simplify registration
- f34e74db pwm: stm32: Add support for all PWMs up to PWM20
- 20365bac pwm: stm32: Do not hardcode the prescalers
- c65499d4 pwm: stm32: Add clock group information
- 07908748 pwm: stm32: Add STM32F0-specific clocks
- bef42fad pwm: stm32: Fix driver to compile with STM32F0
- 18f24f08 pinmux: stm32f3: Add PA8_PWM1_CH1
- 653d75cf pwm: stm32: Add PWM fixup for STM32* and remove Kconfig options
- e7252fbb drivers: uart: Refactor nrf uart shim
- 3f99eefe drivers: uart: Rename nrf5 namings to nrfx
- 1f22a418 gpio: doc: Be explicit about how EDGE and DOUBLE_EDGE work together
- 1002e904 drivers/exti: stm32: Use CMSIS IRQ defines instead of zephyr
- d84795b0 drivers/dma: stm32: Use CMSIS IRQ defines instead of zephyr
- f5310d5b drivers: pwm: pwm_nrf5_sw: Fix calculation of cycles per second
- fc1898cc drivers: pwm: pwm_nrf5_sw: Add prescaler support
- 2e6386f5 drivers: ieee802154: Remove GPIO_MCUX_PORT{A,B}_NAME
Kconfig references
- 02b5f3ed drivers: gpio: Fix GPIO_QMSI_{0,1}_NAME Kconfig references
- 2a834995 drivers: sensors: Consistently quote "GPIO_0" string default
- 8df42eb4 drivers: Replace ff hex constants with 0xff
- a55c72d3 subsys: usb/class/hid: make interrupt endpoint size configurable
- 6c60abb0 drivers: gpio: add dts support for nrf52 gpio
- 2fe51996 drivers/flash: Remove irrelevant option in w25qxxdv driver
- cf14a60f include: usb: add descriptor and data section macros
- 0fca1644 subsys: usb: rework usb string descriptor fixup
- 589dbc4c subsys: usb: add function to find and fix USB descriptors
- 6807f3a8 subsys: usb: move descriptor parts to the class drivers
- 7c708604 include: driver: usb: add check for endpoint capabilities
- 52eacf16 driver: usb: add check for endpoint capabilities
- 18b27b7f subsys: usb: fetch endpoint address from usb_ep_cfg_data
- bf332d00 subsys: usb: validate and update endpoint address
- 12375490 subsys: usb: configure Interface descriptor at runtime
- 1383dad8 subsys: usb: rework composite device support
- 32cac08e usb: class: adapt functions for new composite interface
- 391cf424 usb: tests: Add missing sections to sanitycheck
- 085a8b75 usb: hid: fix write to interrupt IN endpoint
- 408ea146 drivers: flash: nrf: Avoid locking when not threaded
- 49554dd3 drivers: usb_dc_stm32: Change SYS_LOG_LEVEL
- 785faea8 drivers: timer: nRFx: Use nrf_rtc hal for registers w sideeffects
- 53220198 drivers: clock_control: Use nrf_clock HAL for registers w sideeffects
- 78bf7518 drivers: entropy: nrf5: Use nrf_rng hal for registers w sideeffects
- 88de5bd8 drivers: serial: Remove SOC_NRF52810 Kconfig reference
- 392da5ba drivers: flash: w25qxxdv: Avoid locking when not threaded
- fc4fc655 drivers: serial: Revert change to init level for nrfx uart driver.
- 03f2eb7f stm32_pwm: add pinmux port definition for pwm4
- 80b8c501 drivers/serial: stm32: simplify check of TEACK/REACK flags
- 13a96574 drivers/serial: stm32: Put LPUART code under LPUART Kconfig symbol
- ebc31f62 drivers: can: Prepare STM32 driver for other series than STM32F0
- c601f3be can: Add can support for STM32L432
- 7688f490 drivers: usb_dc_stm32: change all endpoints to bidirectional

External (3):

- 4db7cce0 ext: lib: mgmt: Remove MDLOG Kconfig reference
- 354c8222 ext: hal: nordic: Update nrfx to version 1.1.0
- fb6f9b78 ext: Kconfig: Remove redundant 'default n' properties

Kernel (5):

- fd559355 kernel: work_q: Document implications of default sys work_q priority
- b173e435 kernel/queue: Fix spurious NULL exit condition when using timeouts
- 55a7e46b kernel/poll: Remove POLLING thread state bit
- 2e405fbc native_posix & kernel: Remove legacy preemption checking
- 3d14615f kernel: Restore CONFIG_MULTITHREADING=n behavior

Libraries (2):

- 99cef4c6 lib: Fix malformed JSON_LIBARY Kconfig default
- 6245d6c4 libc: minimal: Add typedefs for "least" types

Miscellaneous (3):

- 0f9a6426 release: Post-release patch level update
- 5890004e release: 1.12 doc cleanup
- c16bce7a samples, subsys, tests: Use ARRAY_SIZE() whenever possible

Networking (27):

- c0109fd6 net/ethernet: There is no need to fill in the header in all frags
- 9e0cfaf0 net/arp: There is no need to fill in the header in all frags
- 06fbcb1c net/arp: Removing header filling duplicate
- 97699537 net/arp: Clear cache per-iface when relevant
- a999d53a net/icmpv6: Removing duplicate checksum calculation
- d4e0a687 net/pkt: Simplify a tiny bit how TC priority is set
- e1c11499 net/pkt: Use IS_ENABLED instead of ifdef
- eb3ecf6e net: shell: conn: Always show TCP state
- 3122112a net: ethernet: Provide stubs for ethernet carrier functions
- b93d29df net: ethernet: Add carrier detection to L2
- fa882418 net: dhcpv4: Fix IPv4 and UDP checksum calculation
- 5cda31c8 net: dhcpv4: Detect network interface on/off events
- 4dd61f88 net: tcp: Process zero window probes when our recv_wnd == 0
- 3cf1b07d net: stats: do not use deallocated packet pointer
- 30c4aae9 net: samples: increase main stack size for echo_client
- d4943989 net: stats: handle_na_input: unref packet after stats are updated
- ce6f9819 net: Remove redundant NETWORKING dependency
- 1a96f2b4 net: ethernet: Show interface for dropped RX packet
- 4ae875f9 net: arp: Timeout too long ARP request
- 699023a9 net: ethernet: Fix asserts in net_eth_fill_header()
- e62972bb net: ethernet: net_eth_fill_header: Remove superfluous "frag" param
- 268c0e33 net: tcp: Add MSS option on sending SYN request
- f8dc4b6b net: bluetooth: Enforce the minimum user_data size at Kconfig
- c0e0d613 net: rpl: Fix malformed Kconfig default
- 3bc77e88 net: drivers: wifi: SimpleLink WiFi Offload Driver (wifi_mgmt only)
- 7934e249 net: lwm2m: retry registration update 6 seconds before expiration
- 1da4ddba net: pkt: Fix comment typo in word tailroom

Samples (12):

- 57f67903 samples: can: move CAN sample under drivers
- 3f8352f2 samples: remove sample.tc
- f37287bb samples: cleanup sample test naming
- 10d8e711 samples: move grove samples to sensors and display
- 59309c1a samples: sockets: dumb_http_server: Use consistent logging settings
- fb4227bd samples: mbedtls_sslclient: Use entropy driver to kickstart RNG
- 416614e2 samples: net: echo-client: Increase buf count for frdm-k64f
- 7a073bf9 samples: bluetooth: Fix microbit/nrf5 UART flow control assignments
- e5b5f85c samples: servo_motor: Add support for the BBC micro:bit
- 1bbfdf1d samples: mesh/onoff-app: Enable persistent storage support
- 98465702 samples: net: wifi: Add a cc3220sf_launchxl conf file
- af70e8f7 samples: net: Check the return value of close()

Scripts (11):

- cb95ea0b kconfiglib: Update to add list of choices
- 31ab6bff genrest: Generate documentation and links for choices
- 20721f39 scripts: kconfig: Improve the 'user value != actual value' warning
- ad29ec69 scripts: extract: globals.py: fix node name when it includes "@"
- f971aaca scripts: kconfig: Turn most warnings into errors
- 7f84001f menuconfig: Fix searching for nonexistent objects
- f425c0aa scripts: kconfig: Disable the "FOO set more than once" warning
- 59c8ae8c kconfiglib: Fix incorrectly ordered props. for some multi.def symbols
- ea108107 scripts: kconfig: Extend the assignment-failed warning
- 80f19cca kconfiglib: Correctly report choice locations in some warnings
- 4dcde2e6 menuconfig: Allow searches from the info dialog and vice versa

Storage (1):

- 72959543 settings: fix typo in header file

Testing (8):

- 9b2880fe tests: posix: fix meta-data and rename test file
- 252be0b9 tests/kernel/sched/preempt: enable test for native_posix
- e8a906c2 tests: disable preempt testcase for native_posix
- 4a2d109a native tests: fix kernel sched preempt for arch posix
- 791daa70 tests: sprintf: remove kconfig options
- 072a43d1 tests: Do not build arm_irq_vector_table .config's for ARC
- 7bbd3a79 tests/kernel: Add a test for CONFIG_MULTITHREADING=n
- a3fe7af2 tests: obj_tracing: Enhance object counter logic


Re: Why is the CMake-architecture as it is?

Patrick Boettcher <patrick.boettcher@...>
 

Thank you for your answer.

On Mon, 18 Jun 2018 11:34:24 +0000
"Sebastian Boe" <Sebastian.Boe@...> wrote:

Hi,

CMake's toolchain concept is not used because CMake requires the
toolchain to be specified on the command-line when CMake is invoked.
This was and is considered unacceptable from a user-experience point
of view.[0]
Yes, passing -DCMAKE_TOOLCHAIN_FILE=... to the initial cmake-run is
error-prone.

Having said that, I regularly forget to run

. path/to/zephyr/zephyr-env.sh

before running CMake. Resulting in me doing rm in the build-dir and
re-run cmake after having source the env.sh .

I solved the passing of the toolchain-file by a
build-dir-bootstrap-script which runs cmake.

So, imagine instead of sourcing zephyr-env.sh we would run

path/to/zephyr/cmake-bootstrap.sh path/to/app(s)/dir \
-DUSER_CMAKE_VAR=VALUE

. This script would pass all necessary arguments to cmake plus the args
given by the user. And no more sourcing of zephyr-env.sh would be
needed.

This, plus (some) changes to the cmake-architecture would allow to
do add_library(), add_executable(), target_link_libraries() at will +
some macro-call to tell zephyr to do its magic on executables.

I would also like it to be possible to have several applications in a
single build (without recursive cmake). This might ease verification,
multi-core SoC support, and multi-SoC board support. The reason this
is not supported today is because today we are using a CMake port of
the Linux kernel's build system, and the Linux kernel build system
does not support multi-kernel builds.
Yes, the limitation would be that only one .config-file (and
device-tree maybe as well) could be used for all applications linking
to the same zephyr-instance within the same build.

That would be fine by me, seeing all the benefits I could get from
doing this way. (Out-of-source code/drivers, binary libraries)

I'd love to try it out, but my time is unfortunately very limited.

best regards,
--
Patrick.


Re: NRF52840 UART1

Carles Cufi
 

Hi Ryan,

 

Yes, Jakub is working on this as we speak. If you share your GitHub ID with us we can copy you in the Pull Request as soon as it’s posted.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Ryan Erickson
Sent: 18 June 2018 21:09
To: devel@...
Subject: Re: [Zephyr-devel] NRF52840 UART1

 

Hello All,

Any news on when we might have the new UART features in master for testing?  Having both UARTs operational is critical for our project.
If I can help in any way, please let me know.

Regards,

Ryan


Re: Memory Optimization for Nordic Boards

Sebastian Boe
 

Hi,

I am not familiar with the network protocols, but in general, to memory optimize
an application you would want to run

ninja ram_report

then have a look at what is consuming memory, and navigate with 'menuconfig'
to the appropriate system to see if there are any features that can be disabled or any
buffer sizes that could be adjusted for the given application.
________________________________________
From: devel@... <devel@...> on behalf of Ryan Moeller <ryan.moeller@...>
Sent: Monday, 18 June 2018 5:48:00 PM
To: devel@...
Subject: [Zephyr-devel] Memory Optimization for Nordic Boards

Hello,

I currently have an nRF52-DK running a program that primarily uses three capabilities of Zephyr: IPCP, MQTT, and the Central bluetooth role.

My board is currently using about 90k memory, which isn’t an issue now. That memory usage, however, will become and issue later, when the program is supposed to be ported to a Thingy:52 (64k of memory), and eventually a nRF51(32k of memory).

I have the python menuconfig program running on my machine too – what would be the best way to reduce memory usage for the program?

Thanks,

Ryan


Re: NRF52840 UART1

Ryan Erickson
 

Hello All,

Any news on when we might have the new UART features in master for testing?  Having both UARTs operational is critical for our project.
If I can help in any way, please let me know.

Regards,

Ryan


Memory Optimization for Nordic Boards

Ryan Moeller <ryan.moeller@...>
 

Hello,

 

I currently have an nRF52-DK running a program that primarily uses three capabilities of Zephyr: IPCP, MQTT, and the Central bluetooth role.

 

My board is currently using about 90k memory, which isn’t an issue now. That memory usage, however, will become and issue later, when the program is supposed to be ported to a Thingy:52 (64k of memory), and eventually a nRF51(32k of memory).

 

I have the python menuconfig program running on my machine too – what would be the best way to reduce memory usage for the program?

 

Thanks,

 

Ryan


Add support for libraries targeting ARM ABI C library?

Joakim Andersson <joakim.andersson@...>
 

There is an issue in linker compatibility between GCC and ARM Compiler 5 (not sure about 6) when it comes to linking libraries compiled with ARM compiler and libc functions.
As part of the ARM ABI there is specified some extensions to the C Library for optimized memory functions (memmove, memcpy, memset).
The ARM Compiler will add link symbols to optimized version of these functions, for example __aeabi_memset8 which is memset assuming 8 byte alignment.
For memcpy and memmove these can simply be declared as aliases, for memset the order of the arguments needs to be changed and and memclr can be implemented as a call to memset.

Would it make sense to add support for this to the minimal libc implementation in zephyr?

See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0039d/index.html for information about C Library ABI for ARM architecture.
There exists compiler switches to force ARM compiler to target non aeabi implementations of libc, so it is not strictly needed.

Best regards,
Joakim Andersson


Re: Why is the CMake-architecture as it is?

Sebastian Boe
 

Hi,

CMake's toolchain concept is not used because CMake requires the toolchain
to be specified on the command-line when CMake is invoked. This was and is
considered unacceptable from a user-experience point of view.[0]

I would also like it to be possible to have several applications in a single
build (without recursive cmake). This might ease verification, multi-core
SoC support, and multi-SoC board support. The reason this is not supported
today is because today we are using a CMake port of the Linux kernel's build
system, and the Linux kernel build system does not support multi-kernel builds.

[0] https://github.com/zephyrproject-rtos/zephyr/pull/1107#issuecomment-322440016



________________________________________
From: devel@... <devel@...> on behalf of Rasmussen, Torsten <torsten.rasmussen@...>
Sent: Monday, 18 June 2018 11:06:19 AM
To: devel@...
Subject: Re: [Zephyr-devel] Why is the CMake-architecture as it is?

Hi Patrick,

As Carles mentioned, there has been some discussions ongoing, and some issues has been created.
https://github.com/zephyrproject-rtos/zephyr/issues/8439
https://github.com/zephyrproject-rtos/zephyr/issues/8440
https://github.com/zephyrproject-rtos/zephyr/issues/8441

I think part of those issues is targeting your needs (but not all) so you are more than welcome to comment and give additional feedback.

I believe parts of the Zephyr / CMake libraries should be easier to re-use, but I also know that descisions has been made in past while migrating from make to solve certain use-cases.

Making it easier to just build the libs, and then use target_link_libraries together with add_executable() is what your looking for, correct ?

For the toolchain part, I believe Sebastian can give the reasons on why CMake's standard way is not being used.

You are more than welcome to give specific references to where you face the biggest challenges.

Best regards

Torsten

-----Original Message-----
From: Cufi, Carles
Sent: 15 June, 2018 11:10
To: Patrick Boettcher <patrick.boettcher@...>;
devel@...
Cc: Bøe, Sebastian <Sebastian.Boe@...>; Rasmussen, Torsten
<Torsten.Rasmussen@...>
Subject: RE: [Zephyr-devel] Why is the CMake-architecture as it is?

+Sebastian, +Torsten

Hi Patrick,

I know there's been some discussion on the times you mention so I've
copied a couple of people that might be able to explain why things are like
they are and the work being done to improve some of them.

Thanks,

Carles

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Patrick Boettcher
Sent: 15 June 2018 09:39
To: devel@...
Subject: [Zephyr-devel] Why is the CMake-architecture as it is?

Hi,

first a disclaimer: I was not there yet when it was decided to go with
CMake replacing what was there before in zephyr. I'm a big user of
CMake.

And with all my ignorance as to why things have been designed as they
are, I must say that I find the CMake-architecture quite complicated
and little bit limited to users.

In my project I'm suffering from different problems (out-of-tree-
drivers, binary-delivery of libraries to clients and other things).
With quite some acrobatics I'm getting what I want, but not without
kludges.
These are directly related to the way zephyr imposes things on the user.

I'm sure there are good reasons why it is like that, very good people
have been working on it.

Could someone point me to the mail-archives and the time-period when
this was discussed - I tried the archives, but might have not dug deep
enough.

Some of my questions are:

Why are we not using toolchain-files for cross-compilation, but
instead are doing the linking "ourselves" by overriding
CMake-variables where the documentation is saying do not override them
(well almost)?

Using the standard CMake way of building and linking would give me all
the flexibility I need to face my problems, and I believe we could
still have the app built as it is done today.

The current way of building things limits the build of one application
with one zephyr-build. I understand that for the vast majority this is
enough. I, however, would love to build several apps with one zephyr
build.

Thanks for any response in advance.

best regards,
--
Patrick.


Re: Why is the CMake-architecture as it is?

Rasmussen, Torsten
 

Hi Patrick,

As Carles mentioned, there has been some discussions ongoing, and some issues has been created.
https://github.com/zephyrproject-rtos/zephyr/issues/8439
https://github.com/zephyrproject-rtos/zephyr/issues/8440
https://github.com/zephyrproject-rtos/zephyr/issues/8441

I think part of those issues is targeting your needs (but not all) so you are more than welcome to comment and give additional feedback.

I believe parts of the Zephyr / CMake libraries should be easier to re-use, but I also know that descisions has been made in past while migrating from make to solve certain use-cases.

Making it easier to just build the libs, and then use target_link_libraries together with add_executable() is what your looking for, correct ?

For the toolchain part, I believe Sebastian can give the reasons on why CMake's standard way is not being used.

You are more than welcome to give specific references to where you face the biggest challenges.

Best regards

Torsten

-----Original Message-----
From: Cufi, Carles
Sent: 15 June, 2018 11:10
To: Patrick Boettcher <patrick.boettcher@...>;
devel@...
Cc: Bøe, Sebastian <Sebastian.Boe@...>; Rasmussen, Torsten
<Torsten.Rasmussen@...>
Subject: RE: [Zephyr-devel] Why is the CMake-architecture as it is?

+Sebastian, +Torsten

Hi Patrick,

I know there's been some discussion on the times you mention so I've
copied a couple of people that might be able to explain why things are like
they are and the work being done to improve some of them.

Thanks,

Carles

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Patrick Boettcher
Sent: 15 June 2018 09:39
To: devel@...
Subject: [Zephyr-devel] Why is the CMake-architecture as it is?

Hi,

first a disclaimer: I was not there yet when it was decided to go with
CMake replacing what was there before in zephyr. I'm a big user of
CMake.

And with all my ignorance as to why things have been designed as they
are, I must say that I find the CMake-architecture quite complicated
and little bit limited to users.

In my project I'm suffering from different problems (out-of-tree-
drivers, binary-delivery of libraries to clients and other things).
With quite some acrobatics I'm getting what I want, but not without
kludges.
These are directly related to the way zephyr imposes things on the user.

I'm sure there are good reasons why it is like that, very good people
have been working on it.

Could someone point me to the mail-archives and the time-period when
this was discussed - I tried the archives, but might have not dug deep
enough.

Some of my questions are:

Why are we not using toolchain-files for cross-compilation, but
instead are doing the linking "ourselves" by overriding
CMake-variables where the documentation is saying do not override them
(well almost)?

Using the standard CMake way of building and linking would give me all
the flexibility I need to face my problems, and I believe we could
still have the app built as it is done today.

The current way of building things limits the build of one application
with one zephyr-build. I understand that for the vast majority this is
enough. I, however, would love to build several apps with one zephyr
build.

Thanks for any response in advance.

best regards,
--
Patrick.


Re: [Zephyr-users] Bluetooth mesh provisionning got stuck #bluetoothmesh #nrf52840

vikrant8051 <vikrant8051@...>
 

Hi Rodrigo,

Can you access Models after following these steps ?

Provisioning & Configuration of Models -> un-provisioning (using reset node option in #nRFMesh) -> re-provisioning & re-configuration of Models -> reset / power reset the circuit
-> reconnect to same proxy node -> And try to access Models (means try to control LED associate with Gen. OnOff Server)

Thank You !!

On Sat, Jun 16, 2018 at 2:59 AM, Rodrigo Peixoto <rodrigopex@...> wrote:
Hi guys.


Board: nrf52840_pca10056
Zephyr version: 1.12.0

I am trying to add the mesh feature to my project. I am using a nrf52840_10056pca board, and I'm adding the samples/bluetooth/mesh code to project. 

In this project I have running console shell, mcumgr, PWM, SAADC, thermometer, Bluetooth mesh. Everything is compiling and is working properly. But I am getting stuck when I try to provision the device to enter to the Bluetooth mesh network.

The log for the provision when I press the button provision on the Nordic Mesh app for iOS:

    [bt] [DBG] bt_mesh_pb_gatt_open: (0x200026fc) conn 0x2000085c
    [bt] [DBG] bt_mesh_pb_gatt_recv: (0x200026fc) 2 bytes: 0000
    [bt] [DBG] prov_invite: (0x200026fc) Attention Duration: 0 seconds
    [bt] [DBG] bt_mesh_pb_gatt_recv: (0x200026fc) 6 bytes: 020000020304
    [bt] [DBG] prov_start: (0x200026fc) Algorithm:   0x00
    [bt] [DBG] prov_start: (0x200026fc) Public Key:  0x00
    [bt] [DBG] prov_start: (0x200026fc) Auth Method: 0x02
    [bt] [DBG] prov_start: (0x200026fc) Auth Action: 0x03
    [bt] [DBG] prov_start: (0x200026fc) Auth Size:   0x04
    [BLUETOOTH] [DBG] output_number: OOB Number: 1224  <-- this line is printed by my code
    [bt] [DBG] bt_mesh_pb_gatt_recv: (0x200026fc) 65 bytes: 03d5287e2bd8d07a6b5346d103737dbbf8085f008e13e5586ebc453dcab8fc66d3bf5830f6e6e9935dc175d679bbe2cf2d1d356d83fe560e750a742c179803c9
    [bt] [DBG] prov_pub_key: (0x200026fc) Remote Public Key: d5287e2bd8d07a6b5346d103737dbbf8085f008e13e5586ebc453dcab8fc66d3bf5830f6e6e9935dc175d679bbe2cf2d1d356d83fe560e750a742c179803c990
    [bt] [DBG] prov_clear_tx: (0x200026fc) 
    [bt] [WRN] prov_pub_key: Waiting for local public key

It stops right here...

Any clue on that? I have no idea what to do. When I run the sample separately it is being provisioned. I have already removed the OTA, and other features but nothing seems to fix that.

I hope you can help me.


Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex




Re: Why is the CMake-architecture as it is?

Carles Cufi
 

+Sebastian, +Torsten

Hi Patrick,

I know there's been some discussion on the times you mention so I've copied a couple of people that might be able to explain why things are like they are and the work being done to improve some of them.

Thanks,

Carles

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Patrick Boettcher
Sent: 15 June 2018 09:39
To: devel@...
Subject: [Zephyr-devel] Why is the CMake-architecture as it is?

Hi,

first a disclaimer: I was not there yet when it was decided to go with
CMake replacing what was there before in zephyr. I'm a big user of
CMake.

And with all my ignorance as to why things have been designed as they
are, I must say that I find the CMake-architecture quite complicated and
little bit limited to users.

In my project I'm suffering from different problems (out-of-tree-
drivers, binary-delivery of libraries to clients and other things). With
quite some acrobatics I'm getting what I want, but not without kludges.
These are directly related to the way zephyr imposes things on the user.

I'm sure there are good reasons why it is like that, very good people
have been working on it.

Could someone point me to the mail-archives and the time-period when
this was discussed - I tried the archives, but might have not dug deep
enough.

Some of my questions are:

Why are we not using toolchain-files for cross-compilation, but instead
are doing the linking "ourselves" by overriding CMake-variables where
the documentation is saying do not override them (well almost)?

Using the standard CMake way of building and linking would give me all
the flexibility I need to face my problems, and I believe we could still
have the app built as it is done today.

The current way of building things limits the build of one application
with one zephyr-build. I understand that for the vast majority this is
enough. I, however, would love to build several apps with one zephyr
build.

Thanks for any response in advance.

best regards,
--
Patrick.


Re: Adding own Library to project

König Patrick <Patrick.Koenig@...>
 

I solved it. I made a mistake while moving some of the function to the separated module.
While preparing the example I noticed, that some of the functions in the USB CDC_ACM example, which I used as a base for my project, were declared as static, which I did not notice.
When I added them to my lib, I did not see the static keyword and I forgot to remove it. This functions gave me the errors as described.

I apologize for my mistake and I want to thank all of you for your help.

Patrick


-----Ursprüngliche Nachricht-----
Von: Bøe, Sebastian [mailto:Sebastian.Boe@...]
Gesendet: Donnerstag, 14. Juni 2018 14:39
An: König Patrick <Patrick.Koenig@...>; Li, Jun R <jun.r.li@...>; Patrick Boettcher <patrick.boettcher@...>
Cc: zephyr-devel@...; Sittkus Manuel <Manuel.Sittkus@...>
Betreff: Re: [Zephyr-devel] Adding own Library to project

As far as I am able to understand your description, this is expected to work.

Perhaps you could share a minimal patch to an existing sample to demonstrate when the linker error occurs.

________________________________________
From: devel@... <devel@...> on behalf of König Patrick <Patrick.Koenig@...>
Sent: Thursday, 14 June 2018 10:32:43 AM
To: Li, Jun R; Patrick Boettcher
Cc: zephyr-devel@...; Sittkus Manuel
Subject: Re: [Zephyr-devel] Adding own Library to project

Thanks a lot for your help. I have tried your suggested solution with the CMakeList. Unfortunately, this did not work for me. I got the linker errors as described in my initial mail.

Let me try to illustrate my problem in a bit more detail:

If I add two function to my main.c file, for example usb_send() and usb_receive(), my code works fine. Once I move these functions to independent files like usb_xyz.c for the source and usb_xyz.h for the headers and include the header file in the main.c file, I am no longer able to link my project.

Usually I just need to include usb_xyz.h to my main.c file and add the usb_xyz.c and usb_xyz.h to a Makefile. With Cmake however, I added the usb_xyz.c file to the CMakelist and included header file in my main.c file, which leaves me with linker errors, like undefined reference to usb_send() and usb_receive().
I checked the compiler output, and saw the following line: “Building C object CMakeFiles/app.dir/src/usb_xyz.c.obj”, which leads me to believe that the file was compiled.

I hope this example makes my issue a bit clearer. Basically I just want to create modular Code that I can reuse in other zephyr projects as well.

Regards,

Patrick



-----Ursprüngliche Nachricht-----
Von: Li, Jun R [mailto:jun.r.li@...]
Gesendet: Mittwoch, 13. Juni 2018 16:59
An: Patrick Boettcher <patrick.boettcher@...>
Cc: König Patrick <Patrick.Koenig@...>; zephyr-devel@...; Sittkus Manuel <Manuel.Sittkus@...>
Betreff: Re: [Zephyr-devel] Adding own Library to project

That is true, this way doesn't support adding a driver module into the application since the app doesn't directly call anything from the driver. I'm wondering why driver modules in zephyr directory can be linked even without specifying dependency relationship. How is a driver module in Zephyr directory linked together?


On 6/13/18, 07:53, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

On Wed, 13 Jun 2018 14:45:43 +0000
"Li, Jun R" <jun.r.li@...> wrote:

> Hi Patrick,
>
> If you still want to keep your library (module), another way you can
> do is to add your library as the link dependency for the application
> library (app) by the following:
>
> target_link_libraries(app your_lib_name)

Well, this way of doing bears a whole of problems in some conditions.

While it works in probably most cases, including drivers in such a
library won't work.

Link-order sometimes messes up things as well if your library requires
zephyr functions from libraries where explicit dependencies was
not/could not be declared.

Sebastian is working on it, there is an issue on github's page for it.

--
Patrick.


Why is the CMake-architecture as it is?

Patrick Boettcher <patrick.boettcher@...>
 

Hi,

first a disclaimer: I was not there yet when it was decided to go with
CMake replacing what was there before in zephyr. I'm a big user of
CMake.

And with all my ignorance as to why things have been designed as they
are, I must say that I find the CMake-architecture quite complicated
and little bit limited to users.

In my project I'm suffering from different problems
(out-of-tree-drivers, binary-delivery of libraries to clients and other
things). With quite some acrobatics I'm getting what I want, but not
without kludges. These are directly related to the way zephyr imposes
things on the user.

I'm sure there are good reasons why it is like that, very good people
have been working on it.

Could someone point me to the mail-archives and the time-period when
this was discussed - I tried the archives, but might have not dug
deep enough.

Some of my questions are:

Why are we not using toolchain-files for cross-compilation, but
instead are doing the linking "ourselves" by overriding CMake-variables
where the documentation is saying do not override them (well almost)?

Using the standard CMake way of building and linking would give me all
the flexibility I need to face my problems, and I believe we could
still have the app built as it is done today.

The current way of building things limits the build of one application
with one zephyr-build. I understand that for the vast majority this is
enough. I, however, would love to build several apps with one zephyr
build.

Thanks for any response in advance.

best regards,
--
Patrick.


Re: How does the app get notified if authentication failed?

Li, Jun R
 

Hi Johan,
Thanks for help!

It seems the function " pairing_complete" in your proposal is enough to cover both failure and success cases, with the parameter "bool bonded", right?

And I'm not sure why it is not proper to place the new api function in the API " bt_conn_auth_cb". Can you explain it a bit more?

Sure I'll create a new issue to request this.

Regards,
Jun


On 6/14/18, 02:58, "Johan Hedberg" <johan.hedberg@...> wrote:

Hi Jun,

On Wed, Jun 13, 2018, Li, Jun R wrote:
> In my BLE project, a passkey is required to access the NRF51 device;
> thus the callback functions of “struct bt_conn_auth_cb” were
> implemented to achieve secured paring. What I observed is that
>
> 1. The function “cancel” will be called if the other peer canceled
> the pairing process.
> 2. The function “security_changed” will be called if the passkey
> was successfully entered.

The second one is a bit ambiguous, since it'll also be called for
subsequent connections when the connection gets encrypted, even though
pairing is not in progress (it already happened over some earlier
connection).

> However, my application was NOT notified if a wrong passkey was
> entered, thus the BLE connection is still kept. Ideally, I hope to
> immediately disconnect the connection if the passkey is wrong.
> However, I can’t find a callback function to notify the application if
> the passkey was wrong.
>
> With more debugging logs, I can see the function
> “smp_pairing_complete” got status (-4) when pairing failed while this
> status is zero when successful.
>
> Can anyone enlighten me what kind of function can be used to notify
> the application that pairing failed? Thank you!

This seems to be an oversight in the API. I'd propose to add two new
entries to bt_conn_auth_cb, something like the following:

void (*pairing_complete)(struct bt_conn *conn, bool bonded);
void (*pairing_failed)(struct bt_conn *conn);

For the second one we might want to add another parameter for the
reason. An SMP error comes to mind, but then that wont be reusable for
BR/EDR (which we have experimental support for).

Actually, now that I think about it, bt_conn_auth_cb could be
problematic since it's possible to do just-works pairing without
registering such a structure. I wonder if our bt_conn_cb would be
better. That said, these callbacks are strictly about pairing..

Could you open a github issue to track this, so we get it done for 1.13?

Johan


Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Carles Cufi
 

Yes, that is exactly it.

In that case I am not sure about the issue. Perhaps Johan can bring some light into it.

 

Carles

 

From: "Li, Jun R" <jun.r.li@...>
Date: Thursday, 14 June 2018 at 17:32
To: "Cufi, Carles" <Carles.Cufi@...>, "devel@..." <devel@...>
Subject: Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Yes, every time when I did the tests, I let iPhone “forget the device”, which I suppose to erase the bond info, right?

 

Regards,

Jun

 

 

From: "Cufi, Carles" <Carles.Cufi@...>
Date: Thursday, June 14, 2018 at 08:29
To: Jun Li <jun.r.li@...>, "devel@..." <devel@...>
Subject: RE: Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi there,

 

Have you tried erasing the bond from iOS settings? I find that sometimes bonding fails if the device is already bonded, for whatever reason.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Li, Jun R
Sent: 14 June 2018 17:23
To: devel@...
Subject: [Zephyr-devel] Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi everyone,

 

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

 

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

 

 

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

 

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

 

More logs can be referred below. Thank you!

 

Regards,

Jun

 

 

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

 

 

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8


Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Li, Jun R
 

Yes, every time when I did the tests, I let iPhone “forget the device”, which I suppose to erase the bond info, right?

 

Regards,

Jun

 

 

From: "Cufi, Carles" <Carles.Cufi@...>
Date: Thursday, June 14, 2018 at 08:29
To: Jun Li <jun.r.li@...>, "devel@..." <devel@...>
Subject: RE: Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi there,

 

Have you tried erasing the bond from iOS settings? I find that sometimes bonding fails if the device is already bonded, for whatever reason.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Li, Jun R
Sent: 14 June 2018 17:23
To: devel@...
Subject: [Zephyr-devel] Different BLE pairing behaviors on iPhone 6 and iPhone 7

 

Hi everyone,

 

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

 

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

 

 

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

 

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

 

More logs can be referred below. Thank you!

 

Regards,

Jun

 

 

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

 

 

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

3901 - 3920 of 8692