Date   

Re: [Zephyr-devel] Kconfig changes on master

jack ma <assangema@...>
 

Hi,
What is the relationship  cmake and kconfig ?  both of them can be used to configure Zephyr ?
Are they alternative or dependent?

Thanks.

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

 * The gconfig and xconfig targets have been removed
 * The menuconfig target now uses a Python implementation with curses as its backend
 * There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

 * Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
 * Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide







Re: [Zephyr-devel] Kconfig changes on master

Carles Cufi
 

Hi there,

 

CMake is the build system, Kconfig is the configuration system. Kconfig is run by CMake as one of the first things it does in order to figure out what needs to be built and how.

 

More information can be found here:

http://docs.zephyrproject.org/application/application.html#cmake-details

http://docs.zephyrproject.org/application/application.html#application-configuration

 

Regards,

 

Carles

 

From: jack ma <assangema@...>
Sent: 08 May 2018 12:29
To: Cufi, Carles <carles.cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Kconfig changes on master

 

Hi,

What is the relationship  cmake and kconfig ?  both of them can be used to configure Zephyr ?

Are they alternative or dependent?

 

Thanks.

 

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

 * The gconfig and xconfig targets have been removed
 * The menuconfig target now uses a Python implementation with curses as its backend
 * There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

 * Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
 * Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide



 


[Zephyr-user] Read connection RSSI on nRF52840

전형욱
 

Hello,

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)
It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.
CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon



Re: zephyr thread.

Leandro Pereira
 

Novello,

On 04/18/2018 12:58 PM, novello wrote:
I waold like to know if there is an application note that explain haw to make an application with  some thread that are static.Every thread will have an fixed address space.
The address space at the moment is fixed in Zephyr. A feature to fuzz the initial stack pointer is available (CONFIG_STACK_POINTER_RANDOM) to provide some unpredictability at runtime, but that's disabled by default.

We have plans to support address space layout randomization on devices with memory management units (MMUs), but this requires some design changes that will happen only in upcoming releases. On systems with memory protection units (MPUs), which comprises the majority of devices supported by Zephyr, there isn't much that can be done WRT randomizing the memory layout besides what we have now.


Every task will have a Statically Allocated RAM?
When creating a thread with k_thread_create(), a pointer to a memory block to be used as a stack has to be passed to the function. A dynamic memory allocator (e.g. malloc) is not required for Zephyr to function. Any sample found in the "samples" directory that calls this function should be sufficient to guide you.

Leandro


Kconfig changes on master

Carles Cufi
 

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

* The gconfig and xconfig targets have been removed
* The menuconfig target now uses a Python implementation with curses as its backend
* There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

* Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
* Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide


Reminder: Zephyr API discussion weekly call tomorrow

Carles Cufi
 

Hi all,

Tomorrow we will have another API discussion call. Details on how to join:

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

We still need someone to take ownership of the I2C API at this point. The list of issues to address can be found summarized here:

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

If you think you can help out improving the I2C API please let us know.

As always, more information in the umbrella GitHub issue:

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

and in the meeting minutes:

https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk

Thanks,

Carles


Re: What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

vikrant8051 <vikrant8051@...>
 

Hi Johan, 

Awesome, thanks for the info !!


On Sun, May 6, 2018, 10:55 AM Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Thu, May 03, 2018, vikrant8051 wrote:
> What will be status of #BluetoothMesh in #LTS v.1.12.0 release?
>
> Will it be released as #Qualified stack?

There has been discussion of doing a qualification listing (perhaps two,
one for the core host stack and another for Mesh) for LTS releases under
the name of the Linux Foundation, but as far as I know there's no firm
committment to this yet (e.g. the funding of it). These would be
subsystem qualification listings, so you could combine them together
into a product listing (e.g. the controller qualification that Nordic
did is also a subsystem listing).

That said, both the core host stack (GAP, GATT, SM, L2CAP, etc) and mesh
are periodically run against the PTS, so there shouldn't be any major
surprises if you were to do the qualification process yourself.

> As of now, we can't save Provisioning, Configuration & other real time data
> (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it
> be possible in #LTS release ?

If you follow the master branch, you'll have seen that the Bluetooth
stack has transitioned from the bt_storage API to the newly introduced
settings API (ported from MyNewt, where it's called "conf"). Currently
only pairing credentials (LTK, etc) are covered, but I have some patches
for Mesh that I'm hoping to send next week.

> How many Models (for eg. Generic, Lighting) will show case under #LTS ?

There's really not much "secret" stuff when it comes to the release,
i.e. something that would only be "revealed" at the last moment (the way
you make it sound). A lot of what you'll get is what you can see already
now in the master branch.

> What will be status of Friend & Low Power Nodes implementation ?

Both of those are complete and passing the PTS tests for them.

Johan


Re: What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

Johan Hedberg
 

Hi Vikrant,

On Thu, May 03, 2018, vikrant8051 wrote:
What will be status of #BluetoothMesh in #LTS v.1.12.0 release?

Will it be released as #Qualified stack?
There has been discussion of doing a qualification listing (perhaps two,
one for the core host stack and another for Mesh) for LTS releases under
the name of the Linux Foundation, but as far as I know there's no firm
committment to this yet (e.g. the funding of it). These would be
subsystem qualification listings, so you could combine them together
into a product listing (e.g. the controller qualification that Nordic
did is also a subsystem listing).

That said, both the core host stack (GAP, GATT, SM, L2CAP, etc) and mesh
are periodically run against the PTS, so there shouldn't be any major
surprises if you were to do the qualification process yourself.

As of now, we can't save Provisioning, Configuration & other real time data
(eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it
be possible in #LTS release ?
If you follow the master branch, you'll have seen that the Bluetooth
stack has transitioned from the bt_storage API to the newly introduced
settings API (ported from MyNewt, where it's called "conf"). Currently
only pairing credentials (LTK, etc) are covered, but I have some patches
for Mesh that I'm hoping to send next week.

How many Models (for eg. Generic, Lighting) will show case under #LTS ?
There's really not much "secret" stuff when it comes to the release,
i.e. something that would only be "revealed" at the last moment (the way
you make it sound). A lot of what you'll get is what you can see already
now in the master branch.

What will be status of Friend & Low Power Nodes implementation ?
Both of those are complete and passing the PTS tests for them.

Johan


Zephyr news, 4 May 2018

Marti Bolivar
 

Hello and happy Friday,

This is the 4 May 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/05/04/zephyr-news-20180504/

Contents are broken down like this:

- 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
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

This newsletter covers changes in Zephyr between these two commits
(inclusive):

- b742b62b ("kconfiglib: Update to get split_expr() in"), 17 April 2018
- dc97fc2a ("kconfiglib: Update to default to UTF-8 for Python 3"), 2 May 2018

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

Retpolines on x86:

x86 CPUs affected by Spectre v2 now support retpolines when invoking
interrupt and exception handlers, during thread entry, and when
invoking syscall handlers.

These changes also saw the removal of the (unused) _far_jump() and
_far_call() routines.

LED and Button Definition Moves:

This continues the long-term project to move device configuration from
Kconfig to Device Tree.

LED and button definitions were removed from all STM32 board.h files,
since the corresponding defines now come from device tree. This is a
breaking change, as the old XXX_GPIO_PORT is now
XXX_GPIO_CONTROLLER. Applications which used the old names will need
updates.

NXP Kinetis SoCs were also converted to generate this information from
Device Tree. This change preserved names, but did not include updates
for the FXOS8700 or FXAS21002 temperature sensors or the MCR20A
802.15.4 radio. Users of those devices on NXP Kinetis boards should be
advised that support is broken in this Zephyr tree.

Deprecated __stack macro removed:

The __stack macro, which was deprecated in favor of K_STACK_DEFINE
before v1.11 was released, has been removed.

mbedTLS update to fix remote execution holes:

The mbedTLS cryptography library was updated from version 2.7.0 to
version 2.8.0, addressing CVEs 2018-0488 and 2018-0487. These are
remote execution vulnerabilities that could occur when TLS or DTLS is
in use.

k_thread_cancel() deprecated:

The k_thread_cancel() API is deprecated. Applications should use
k_thread_abort().

Generic storage partition rename:

The NFFS flash partition available on many boards, which was
previously aliased to nffs_partition, has been renamed to
storage_partition, to reflect its general usefulness for a variety of
storage systems. Its existence is now controlled via a
CONFIG_FS_FLASH_MAP_STORAGE.

Out of tree applications using the old alias or configuration option
to access this partition will need updates.

Features
--------

Architectures:

The ARC architecture now supports CONFIG_STACK_SENTINEL, which can help
diagnose stack overflow issues.

SEGGER RTT support is now enabled on all NXP MCUs.

Support was added for Cadence's proprietary XCC compiler toolchain for
the XTensa architecture, along with support for the intel_s1000 SoC.
Judging from these drivers, the SoC is intended for use in speech and
other audio processing. Zephyr SoC-level support is provided for DMA,
I2S, UART, GPIO, USB, and I2C, with board support via intel_s1000_crb.

Boards:

I2C driver support was enabled for all the official nRF5 boards
provided by Nordic Semiconductor.

The bbc_microbit now supports flash partitions for mcuboot and on-chip
storage.

Build system:

A variety of improvements were merged into the build system.

Notably, the build system now caches information obtained from the
toolchain, optimizing subsequent invocations of cmake using the same
toolchain. Factor of two speedups have been observed when the cache is
used. A few problems have been identified and fixed up since the
initial merge, but hopefully the major issues are resolved.

In another significant addition, the build system now contains an
initial Python-based menuconfig alternative. This can currently be
used by running "ninja pymenuconfig" on all supported targets (though
Windows users will need to install an additional wheel). This is a
significant improvement for Windows users, who previously have not had
a configuration system browser. The pymenuconfig target is
experimental. When it reaches sufficient feature parity with the
existing menuconfig target, it will replace it, and the C-based
Kconfig tools will be removed from Zephyr.

Further improvements include better error feedback when toolchains are
not found, the list of printed boards now respecting BOARD_ROOT, and
silencing of verbose compiler check messages.

Drivers:

There is a new API for LEDs in include/led.h. (Zephyr had an API for
strips of LEDs; this new API is for controlling individual lights.)
The initial API includes support for basic on/off, as well as
brightness and blinking. A driver and sample application for the TI
LP3943 LED controller were also merged.

The ST LSM6DSL inertial module driver saw a cleanup and now supports
sensor hub mode. This allows the LSM6DSL to act as a sensor hub by
connecting additional I2C slave devices through to the driver via the
main communication channel.

STM32L0 and L4 microcontrollers now support the MSI (multi-speed
internal) clock as a system clock source.

The uart_pipe console driver now supports both edge and level
triggering, allowing it to work with CDC ACM.

The MCUX GPIO driver now uses device tree.

A GPIO driver for NXP i.MX SoCs was merged.

Device Tree:

Bindings were added for the DesignWare CAVS multilevel interrupt
controller.

GPIO nodes are now present on all Kinetis SoCs.

Documentation:

The search results pages for the online Zephyr documentation now have
much cleaner output.

Zephyr's documentation describing its Kconfig usage was re-worked and
improved as part of the transition towards a Python-based menuconfig
alternative.

Kernel:

The kernel's scheduler interface was significantly refactored and
cleaned up. The scheduler's system interface was decreased to twelve
functions; notably, usage of _Swap() was removed in various places in
favor of a new _reschedule().

Userspace configurations now support dynamic creation of kernel
objects. Previously, kernel objects (such as mutexes, pipes, and
timers) needed to be declared statically. This is because a special
linker pass is used when building the Zephyr image, which creates a
perfect hash table which was used to validate if a memory address
passed from userspace pointed to a valid kernel object, among other
security checks. In addition to this hash table, Zephyr now supports
maintaining metadata for dynamically created kernel objects using the
new red/black tree implementation that was added in the v1.12
development cycle. Dynamic kernel objects are allocated and freed from
the system heap. The new allocate and free routines are respectively
k_object_alloc() and k_object_free(). They are currently only
callable from supervisor mode.

Libraries:

The singly-linked list implementation in include/misc/slist.h is now
implemented in terms of a new macro metaprogramming header,
include/misc/list_gen.h. This new header allows generation of static
inline routines implementing "list-like" behavior (i.e. defining
operations for getting, removing, inserting, etc.) for any compound
data type that implements a base set of operations. The base
operations from which the others are derived are: initialization;
getting the "next" node; setting the next, head, and tail nodes;
and peeking at the head and tail nodes.

The JSON library's internal descriptor type is more tightly packed,
using bitfields to place information formerly found in four integers
into 32 bits worth of bitfields. This results in a net savings of
read-only data at a slight increase in text size.

Samples:

A sample application demonstrating the BLE broadcaster role by
providing Apple iBeacon functionality was added in
samples/bluetooth/ibeacon.

Samples using LEDs and buttons were updated following the device tree
name change from PORT to CONTROLLER described above.

The LWM2M sample was re-worked to add configuration overlay fragments
for enabling Bluetooth networking and DTLS. The README was updated
with new instructions for building the sample.

Testing:

The effort to prepare Zephyr's tests for inclusion in a test
management system continues.

Various tests were cleaned up with style, tag, and category fixes,
along with numerous tests receiving Doxygen-based documentation.

The sanitycheck script now parses test cases declared by a test suite
from the source code, using regular expressions.

Sanitycheck also now supports a --list-tests flag, which prints
declared test cases. Its output can be further refined by passing the
-T option a relative path to a subdirectory of "tests" (e.g. -T
tests/net/socket).

The test suite core now includes support for skipping tests when they
are not supported.

USB:

There was a fair bit of USB-related activity which spanned areas in
the tree.

The USB DFU class driver was heavily re-worked and moved to
subsys/usb/class. The driver now determines the flash partition layout
for the currently running image and an area to store an update image
via device tree flash partitions, matching Zephyr's MCUboot area
support mechanism. This allows Zephyr applications to add firmware
update support by enabling the USB DFU driver and booting under
MCUboot. Refer to the README and other documentation in
samples/subsys/usb/dfu for more details.

The hci_usb sample application, which allows a Zephyr device which
supports USB and a Bluetooth controller to act as a Bluetooth dongle,
had its core USB operations generalized and migrated into the core USB
subsystem. The sample application is now much smaller; what remains
essentially just enables the driver.

The wpanusb sample, which allows Zephyr applications to expose
802.15.4 radio functionality to a host via USB, saw a major
cleanup. This sample will be more widely useful upon release of
corresponding Linux drivers.

Bug Fixes
---------

There were several networking-related bug fixes: a fragment
double-free, a build error for HTTP clients, a buffer overflow in the
hostname storage area, an ARP null network packet dereference, and a
miscalculation of ICMPv6 packet payload length and checksum fields.

Calling pthread_cond_signal() from a cooperative thread no longer
yields.

The irq_lock() compatibility layer on SMP configurations was fixed,
avoiding potential deadlocks when swapping away from a thread that
holds the lock.

The kernel scheduler's validation of priority levels was fixed.

A bug which allowed user mode code to force the kernel to execute code
at address 0x0 has been fixed by introducing an extra validation step
at every syscall entry point.

A race condition which could potentially allow user space code to
modify memory containing I2C messages before the kernel-level handler
runs was closed.

Issues preventing successful thread context switch during exception
return on ARC were fixed. The fatal error handler on that architecture
also no longer hangs the system after aborting a non-essential thread.

The BusFault Status Register bits on ARMv8-M MCUs are now properly
cleared when that fault occurs.

The Bluetooth Mesh implementation continues to become more robust,
with three bug fixes affecting initialization vectors and node
identity advertising, and two other cleanups.

The boot banner now correctly prints the Zephyr "git describe" output
when the application is outside the Zephyr tree.

A variety of warnings emitted when using dtc version 1.4.6 are now
fixed. These fixes appear to be backwards-compatible.

A variety of USB-related bug fixes went in, including a fix for the
DesignWare driver's excessive generation of zero-length packets, a
missing byte order conversion computation in the common configuration
descriptor, and other fixes and cleanups.

The ST LSM6DSL inertial module driver was converted to use the new SPI
API, following the removal of the old API.

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

Patches by area (241 patches total):

- Arches: 31
- Bluetooth: 5
- Boards: 11
- Build: 19
- Continuous Integration: 6
- Device Tree: 9
- Documentation: 12
- Drivers: 36
- External: 4
- Kernel: 17
- Libraries: 6
- Maintainers: 1
- Miscellaneous: 6
- Networking: 8
- Samples: 26
- Scripts: 9
- Storage: 4
- Testing: 31

Arches (31):

- 3d9ba10b arch: arc: bug fixes and optimization in exception handling
- 24acf2a4 arch: arc: bug fixes in irq_load
- 8da51ee3 arch: arc: optimize the _SysFatalErrorHandler
- adf6f48e arch: arc: add the support of STACK_SENTINEL
- b4696bd7 arch: arm: Fix coding style in file irq_relay.S
- 50b69fbb arm: nxp_kinetis: Remove unused defines from soc.h
- 0b7c964f arch: arm: clear BFSR sticky bits in ARMv8-M Mainline MCUs
- 16472caf arch: x86: Use retpolines in core assembly routines
- ae7911cc arch: x86: segmentation: Remove unused _far_call() and _far_jump()
- adf5b36a lpc54114: Remove unused include in soc.c
- 3e3d1a1c x86: minnowboard: Add support for enabling MMU
- 960e9783 x86: linker: Maintain 4K alignment for application memory.
- 246f03c9 x86: minnowboard: Enable the userspace mode
- ae5e11be arm: soc: NXP: Enable SEGGER RTT on all NXP SoCs
- c7d808f9 arch: arm: improve help text for PROGRAMMABLE_FAULT_PRIOS option
- c36e5ac1 arm: Fix title for SoC configuration in Kconfig
- 42a7c573 arm: soc: Elaborate Kconfig strings for MPU selection
- d9cdf7bf arch/arm/soc/st_stm32: Fix typos in soc.h
- de7f40ac kconfig: fix menuconfig
- f14d1be6 intel_s1000: Add intel_s1000 SoC
- 1fcd39b6 intel_s1000: define memctl_default.S and memerror-vector.S files
- c9ace83c xtensa: reset-vector.S hack for booting intel_s1000 [REVERTME]
- 47ff9659 intel_s1000: uart: configure UART for intel_s1000
- 9ed55af2 arch: xtensa: set __start as entry point for Xtensa.
- 63d50e15 intel_s1000: gpio: enable GPIO handling
- 9cc381c0 intel_s1000: i2c: enable I2C for intel_s1000
- dadf9e7a xtensa: intel_s1000: implement interrupt mechanism
- 08172cdf xtensa: provide XCC compiler support for Xtensa
- 2fd277fc arch/arm/soc/st_stm32/stm32f1: Add I2C1 to dts.fixup
- 6c65ac2b arch: arc: fix the typo of label which caused issue #7249
- e3efbd54 POSIX arch: Fix linker -T warning

Bluetooth (5):

- 2a896cc6 Bluetooth: Mesh: Fix IV Update tests when duration is unknown
- c7c5829b Bluetooth: Mesh: Fix missing IVU normal mode timer when provisioning
- aa67a4c5 Bluetooth: Mesh: Remove redundant branch for IV Update
- 92749e7a Bluetooth: Mesh: Remove unnecessary #ifdefs from header file
- 6b111064 Bluetooth: Mesh: Fix enabling Node Identity advertising

Boards (11):

- 678a6e02 boards: stm32 remove led and button definitions from board.h
- c627de1f boards: Move led and button definitions to dts for kinetis boards
- 597517c7 boards: dts: Add i2c to nrf5X_pcaX board dts.
- 513488c9 boards: disco_l475_iot1: define 2 default clock configurations
- f496fd2a boards/arm/stm32_min_dev: Fix APB2 prescaler value
- 992070f1 boards: microbit: Add flash partition definitions to dts
- 034a11b7 boards: arm: 96b_neonkey: Fix I2C_3 for LP3943 LED driver
- 0090fd4d intel_s1000: create xt-sim_intel_s1000_defconfig
- 02736e59 intel_s1000: add intel_s1000_crb board
- cea1c75e boards: intel_s1000_crb: enable DMA
- 46d6ba46 boards: intel_s1000: enable I2S

Build (19):

- f10fddeb cmake: toolchain: Improve error feedback when toolchain is not found
- d9ac1d4b warnings: Disable "unused-local-typedefs" compiler warning
- 6779d3f3 cmake: Fix printed list of supported boards.
- 6c3a94c0 cmake: Add function for checking if a directory is write-able
- 709daa20 cmake: Find a directory that could be used to cache files
- c95c6bef cmake: check_compiler_flag: Support empty-string options
- a7c3f4ed cmake: toolchain: Checksum the toolchain to uniquely identify it
- 84475810 cmake: Introduce zephyr_check_compiler_flag()
- 71b849f1 cmake: Port Zephyr to use zephyr_check_compiler_flag
- 8bcf30e2 cmake: posix: Use absolute paths for toolchain paths
- 33d87efd build: simplify git describe call
- f9b2da37 kconfig: Move CPLUSPLUS from root to "Compiler Options"
- 7db4d569 Revert "warnings: Disable "unused-local-typedefs" compiler warning"
- a4381d9e kconfig.cmake: Consistently use ZEPHYR_BASE
- 9fbdab52 build: fix git describe call on older Git versions
- 632fe1d4 cmake: check_compiler_flag: Fix bug where checks were aliased
- 5f08b106 cmake: Suppress messages about compiler checks
- aa90d721 cmake: Introduce a key version to invalidate corrupted caches
- 878f39c1 makefile: Fix dependencies for privileged stacks

Continuous Integration (6):

- 140daa2f sanitycheck: add min_flash option for 32K devices
- aae71d74 sanitycheck: parse test cases from source files
- c0149cc0 sanitycheck: support listing test cases
- de223cce sanitycheck: Updated helptext to -O/--outdir argument.
- 75e2d901 sanitycheck: refinements to --list-tests
- 770178b7 sanitycheck: Stop on linker warnings also in native_posix

Device Tree (9):

- a43ad6d5 dts: arc: quark_se_c1000_ss: Fix worng interrupt number in i2c 0/1
- 22955b83 dts: Add gpio labels to all kinetis socs
- a27c0ede dts/st: dtc v1.4.6 warnings: #address-cells/#size-cells
without "ranges"
- acc20e24 dts/st: dtc v1.4.6 warnings: Missing property '#clock-cells' in node
- 986f249f dts/st: dtc v1.4.6 warnings: pin-c... node has a reg ... no unit name
- 398a5a4f dts: dtc v1.4.6 warnings: Fix warning for leading 0s
- 97f721d9 dts: xtensa: Add device tree support for xtensa
- 9ee4929d dts: i2c: Add dts support for i2c
- 7be3236c dts: interrupt_controller: Add dts support for DesignWare controller

Documentation (12):

- 3a72cc98 doc: genrest: Simplify select logic with split_expr()
- 28724732 doc: fix mgmt sample path
- 55840693 doc: win: Invoke pip3 instead of pip to be safe
- b57ac8a2 doc: improve Sphinx search results output
- a380dce0 doc: fix links to mailing lists
- e618608f doc: Expand info about troubleshooting ModemManager
- 1ae99f02 doc: Improve Kconfig interface description
- 303484aa doc: Clarify application configuration
- 64eb789f doc: Clarify format for CONF_FILE
- b4d67dcc doc: update doc generation instructions
- 63cb2334 doc: Document Zephyr's Kconfig configuration scheme
- 699759a0 doc: brief description on intel_s1000 usage

Drivers (36):

- 4e8f29f3 gpio: Refactor the mcux gpio driver to use dts
- 8d3b2fa8 usb: usb_dc_dw: Fix incorrect MPS return
- 4f84cf78 usb: Add BOS Descriptors
- 773f3e18 usb: Add sys_cpu_to_le16() conversion for USB field
- 6239341a usb: Add subsys/usb for device descriptor header
- 16532549 usb: mass_storage: Use simpler header include
- 4d703b1e usb: Add Bluetooth USB Device configuration options
- 0322af58 usb: Add Bluetooth device decriptors
- 53410af9 usb: Add Bluetooth device class core functionality
- a09a0b2c sensors/lsm5dsl: Fix SPI API usage
- b7862eb8 hid: core: truncated wLength if it doesn't match report
descriptor size
- 8f7e5bd0 uart_pipe: re-work the RX function to match the API and
work with USB.
- c26fdc1b drivers/spi: Fixed incorrect prompt.
- d8ba007a drivers: clock_control: Add MSI as possible clock source for stm32
- 25fb83c6 drivers: i2c: Fix TOCTOU while transferring I2C messages
- 7e067414 usb: Remove unneeded header include
- c200367b drivers: Perform a runtime check if a driver is capable of
an operation
- 185f2be6 netusb: rndis: Add more debugs
- 222aa600 netusb: rndis: Fix RNDIS always disabled state
- 94bba071 drivers: led: Add public API for LED drivers
- bb394bba drivers: led: Add LED driver support for TI LP3943
- f4ad6988 drivers/spi: Remove DW spi slave test left over
- 180b1397 drivers: sensor: lsm6dsl: Adding sensorhub support
- 580a9b3f drivers: sensor: lsm6dsl: Fix typos
- f7f56ccd drivers: sensor: lsm6dsl: add .attr_set callback
- 46700eaa include: usb: add USB DFU class header
- b2ca5ee5 subsys: usb: rework USB DFU class driver
- 74016bb6 drivers: interrupts: introduce CAVS interrupt logic
- e3f2fa4f drivers: interrupts: introduce Designware interrupt controller
- bd0d5133 drivers: dma: introduce Intel CAVS DMA
- 5b6f0244 drivers: i2s: introduce CAVS I2S
- 5060f4bd driver: usb: enable usb2.0 on intel_s1000
- f618af75 driver: ieee802154: cc1200: fix context handling
- 943ca29d usb: dw: Fix Coverity issue with get_mps()
- c6f2b4cc spi: Fix mcux dspi driver to parse lsb transfer mode correctly
- 67ba7d8a gpio: Add imx gpio driver shim

External (4):

- 2c58de57 ext: lib: crypto: Update mbedTLS to 2.8.0
- 9791597e ext: mcux: Update README to follow template format
- 57e80e53 ext: mcux: Reorganize imported drivers into soc family subfolders
- 4624f132 ext: mcux: Remove clock_config.c/h

Kernel (17):

- 56c2bc96 kernel: add CODE_UNREACHABLE in _StackCheckHandler
- 541c3cb1 kernel: sched: Fix validation of priority levels
- b481d0a0 kernel: Allow pending w/o wait_q for scheduler API cleanup
- 8606fabf kernel: Scheduler refactoring: use _reschedule_*() always
- e0a572be kernel: Refactor, unifying _pend_current_thread() + _Swap() idiom
- 0447a73f kernel: include cleanup
- 15cb5d72 kernel: Further unify _reschedule APIs
- 3f55dafe kernel: Deprecate k_thread_cancel() API
- 5792ee6d kernel/mutex: Clean up k_mutex_unlock()
- 22642cf3 kernel: Clean up _unpend_thread() API
- 8a4b2e8c kernel, posix: Move ready_one_thread() to scheduler
- f5f95ee3 kernel: sem: Ensure that initial count is lesser or equal than limit
- 31bdfc01 userspace: add support for dynamic kernel objects
- e7ded11a kernel: Prune ksched.h of dead code
- 68040c8d kernel: sem: Modify the way BUILD_ASSERT is used
- eb258706 kernel: Move SMP initialization to start of main thread
- 15c40077 kernel: Rework SMP irq_lock() compatibility layer

Libraries (6):

- 2a5fb57e lib: posix: mqueue: Do not dereference mqd pointer before null check
- 3af88642 lib: posix: mqueue: Minor formatting cleanups
- d89249db pthread: Respect cooperative thread schedulign in condition variable
- e7648ba3 lib: posix: pthread_common: Fix potential integer overflow issue
- 9faa42f5 slist: abstract node and list implementation
- 0ec79d68 lib: json: Efficiently pack field name, offset, alignment, type

Maintainers (1):

- 517a08ee CODEOWNERS: Add myself as the Codeowner for LED API and drivers

Miscellaneous (6):

- 81f4b111 include: toolchain: common: Remove deprecated __stack macro
- 666274fa toolchain: gcc: Only use _Static_assert if building with C11
- 05169a02 toolchain: common: Allow multiple uses of BUILD_ASSERT() in
same scope
- 83ac3e24 shell: kernel: Add reboot command
- f8c1cc17 toolchain: update xtools config
- b3153d24 intel_s1000: scripts: debug, debugserver and flash scripts

Networking (8):

- c0d0a61b net: ipv6: Remove irrelevant error log
- 460a6c77 net: tcp: send_syn_segment: Log packet before it's sent
- bf185f58 net: ipv6: Fix crash from double free of fragment
- 8c561994 net: http: Fix client compilation if HTTPS is enabled
- a12138d4 net: hostname: Fix hostname buffer length
- 2002a4e2 net: arp: Do not access NULL network packet
- 3da4d370 net: Implement VLAN priority to packet priority conversion
- d1715685 net: icmpv6: Fix payload length and checksum

Samples (26):

- 162b6e4b samples: Allow use of "CONTROLLER" postfix for LED and GPIO
- d38116cb usb: Use new USB Device interface for Bluetooth over USB sample
- fc5134b0 usb: hci_usb: Fix test name
- d665e128 usb: hci_usb: Correct README
- b35274a4 samples: usb: webusb: Prettify binary object store descriptor
- a9d377e0 usb: wpanusb: Replace char array with structs for descriptor table
- 10ec019a usb: wpanusb: Replace local hexdump() with net_hexdump()
- 9e753f0c usb: wpanusb: Clean up code
- c8e23874 usb: wpanusb: Remove unused headers
- a5e7a8de usb: wpanusb: Remove unused packet handlers
- 74d08efb usb: wpanusb: Correct protocol description
- 7337f4a0 usb: wpanusb: Code cleanup
- acb0f099 samples: echo_server: Update prj_cc2520 configuration
- 2b47d358 usb: wpanusb: Fix regression with putting LQI to wrong place
- 24cc5cc4 usb: wpanusb: Make generic interface to raw 802.15.4 channel
- 190e8d96 usb: wpanusb: Fix setting wrong length
- 30c3461e samples: lwm2m: replace prj_dtls.conf with overlay fragment
- 5df33d67 samples: lwm2m: add overlay conf to support BT networking
- 970b0a99 samples: lwm2m: update README with use of overlay files
- f59a68b6 samples: net: http: Add TLS compilation test
- 6c70aa28 samples: net: Fix CoAP server payload dump function
- 1572594b samples: drivers: Add sample application for LP3943
- b27d9685 samples: bluetooth: Add Apple iBeacon demo application
- 2d1c5241 samples: flash_shell: Use correct flash write block size
- a6eee02c samples: enhance integration sample and document it
- 00c26d24 samples: remove stray config

Scripts (9):

- b742b62b kconfiglib: Update to get split_expr() in
- f3caef8e scripts: extract_dts_inlcudes: look up compatible field in parents
- 69beec87 scripts: extract_dts_includes: generate controller #define's
- 39dc7d03 scripts: gen_kobject_list: Generate enums and case statements
- d3bfbfeb kconfiglib: Update to get choice.direct_dep in
- 73549ad8 scripts: kconfig: Add a Python menuconfig implementation
- cfb3c925 kconfiglib: Update to add warning for malformed .config lines
- 1799cfdb scripts: kconfig: Turn malformed .config lines into errors
- dc97fc2a kconfiglib: Update to default to UTF-8 for Python 3

Storage (4):

- 9fe30535 susbsys: settings: fix coverity issues
- 341b4273 subsys: settings: fix fcb back-end initialization
- 9968cda4 fs: Convert NFFS partition to a generic one
- d67009da subsys: settings: Fix Kconfig dependencies

Testing (31):

- 1931f124 tests: fix arc related codes
- edc048e0 tests: socket: udp: Make sure client sockaddr fully initialized
- e8bcc6f1 tests: socket: Free resources with freeaddrinfo
- 1d1db121 tests: socket: udp: Tighten up error checking
- e564d58b tests: socket: udp: Close test sockets
- 1609f251 tests: kernel: style, tag, and category fixes
- 63f21391 tests: use consistent test function names
- 1f2627a6 tests: net: style, tag, and category fixes
- 9312de00 tests: crypto: style, tag, and category fixes
- 89a50932 tests: posix: style, tag, and category fixes
- fa6cce43 tests: ztest: style, tag and category fixes
- 0f5a88b0 tests: posix: mqueue remove extra printk
- 910a569e tests: stackprot: move to ztest
- 20495e89 ztest: support skipping tests
- 7a5ff137 tests: allow unsupported tests to be skipped
- eb6f2031 tests: fix meta data of peripheral tests
- 7753bc50 tests: kernel: mem_protect: tests for userspace mode.
- b4cb1014 tests: mem_prot: skip unsupported tests
- 9a2b5357 tests: settings: Remove references to non-existent Kconfig variable
- 6f1cff73 ztest: fix result checking
- 3298d60f tests: subsys: settings: Add FCB-beckend initialization test
- ff0857df tests: threads: Add test to verify delayed thread abort
- 2182a53f tests: irq_offload: document test functions
- 25e7b27b tests: critical: document test functions
- 67194a40 tests: errno: document test functions
- 2b62f1ab tests: fixed doxygen comments
- 18cc28a9 tests: Fix malformed CONFIG_TEST=y prj.conf entry
- 567482ff intel_s1000: tests: introduce tests to check features enabled
- a2afa6cf test: board: intel_S1000: Add test application for HID
- e57df9a3 tests: boards: intel_s1000_crb: select application based on config
- b3275d65 tests/samples: add hw dependencies


Re: [Zephyr-devel] What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

vikrant8051 <vikrant8051@...>
 

HI Aaron,

This PDF may help developers who want to go with Zephyr #BluetoothMesh.

https://www.zephyrproject.org/wp-content/uploads/sites/38/2018/03/openiot_zephyr_lts_what_and_why.pdf

But following links are Silent about #BluetoothMesh
As per attached image, #LTS is going to release in June 2018.

So currently, I'm clueless & unfortunately have to go with stack provided by Silicon manufactures
which are Black Box & inherently complicated.  😥

 

On Fri, May 4, 2018 at 8:27 AM, Aaron Xu <overheat1984@...> wrote:
Hi,

We all look forward that the zephyr project bluetooth mesh can be used on a real project.
Before that, we want to know those question's answer.

Thanks.

vikrant8051 <vikrant8051@...> 于2018年5月3日周四 下午9:53写道:
Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!








Re: [Zephyr-devel] What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

Aaron Xu <overheat1984@...>
 

Hi,

We all look forward that the zephyr project bluetooth mesh can be used on a real project.
Before that, we want to know those question's answer.

Thanks.

vikrant8051 <vikrant8051@...> 于2018年5月3日周四 下午9:53写道:

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

vikrant8051 <vikrant8051@...>
 

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







Re: [Zephyr-devel] [ #BluetoothMesh ] possible Bug .. without assigning subscription address to Model, it is reacting to subscription address assign to other Model #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,
It was bug from my side & I've resolved it.
Now everything is working as expected.

Excuse me for that !!

On Wed, May 2, 2018 at 2:31 PM, Vikrant More <vikrant8051@...> wrote:
Hi,

I gone through my code once again & found that it was small bug from my side.
I had forgotten to add "break" in my customized version of $zephyr/samples/bluetooth/mesh .

Extremely sorry for that.

//------------------------------------------------------------------------doer.c----------------------------------------------------------------------------------------------------------------------

#include "common.h"

int8_t  gen_onoff_srv_state, last_gen_onoff_srv_state;
int16_t gen_level_srv_state, last_gen_level_srv_state;

void doer(struct bt_mesh_model *model, struct bt_mesh_msg_ctx *ctx, struct net_buf_simple *buf, uint16_t opcode)
{
    int err=0;

    int8_t tmp8;
   
    int16_t tmp16;

    struct net_buf_simple *msg;

    switch(opcode)
    {

        case 0x8201:    //GEN_ONOFF_SRV_GET

            msg = NET_BUF_SIMPLE(2 + 1 + 4);

            bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x04));

            net_buf_simple_add_u8(msg, gen_onoff_srv_state);

            if (bt_mesh_model_send(model, ctx, msg, NULL, NULL))
            {
                printk("Unable to send GEN_ONOFF_SRV Status response\n\r");
            }
       
           break;


        case 0x8203:    //GEN_ONOFF_SRV_UNACK

            msg = model->pub->msg;

            gen_onoff_srv_state = (unsigned char)global_state;

            if(last_gen_onoff_srv_state != gen_onoff_srv_state )
            {
                last_gen_onoff_srv_state = gen_onoff_srv_state;

                if(gen_onoff_srv_state != 0)
                {
                    NRF_P0->OUT &= ~(1<<13);    //LED ON
                }
                else
                {
                    NRF_P0->OUT |=  (1<<13);    //LED OFF   
                }

                if(model->pub->addr != BT_MESH_ADDR_UNASSIGNED)
                {

                    bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x04));
                    net_buf_simple_add_u8(msg, gen_onoff_srv_state);

                    err = bt_mesh_model_publish(model);

                    if(err)
                    {
                        printk("bt_mesh_model_publish err %d", err);
                    }

                }
            }

            break;

        case 0x8204:    //GEN_ONOFF_SRV_STATUS

            tmp8 = net_buf_simple_pull_u8(buf);

            NRF_P0->OUT ^= (1<<16);

            printk("Acknownledgement from GEN_ONOFF_SRV = %u\n\r",tmp8);

            break;

        case 0x8205:    //GEN_LEVEL_SRV_GET
           
            msg = NET_BUF_SIMPLE(10);

            bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x08));

            net_buf_simple_add_le16(msg, gen_level_srv_state);

            if(bt_mesh_model_send(model, ctx, msg, NULL, NULL))
            {
                printk("Unable to send GEN_LEVEL_SRV Status response\n\r");
            }

            break;

        case 0x8207:    //GEN_LEVEL_SRV_UNACK

            msg = model->pub->msg;

            gen_level_srv_state = (int16_t)global_state;

            if(last_gen_level_srv_state != gen_level_srv_state )
            {
                last_gen_level_srv_state = gen_level_srv_state;

                printk("gen_level_srv_state = %d \n\r" , gen_level_srv_state );
               
                if(gen_level_srv_state > 10000)
                {   
                    CLRB(NRF_P0->OUT,15);
                    SETB(NRF_P0->OUT,16);
                }
                else
                {   
                    CLRB(NRF_P0->OUT,16);
                    SETB(NRF_P0->OUT,15);
                }
                               
                if(model->pub->addr != BT_MESH_ADDR_UNASSIGNED)
                {

                    bt_mesh_model_msg_init(msg,BT_MESH_MODEL_OP_2(0x82, 0x08));

                    net_buf_simple_add_le16(msg,gen_level_srv_state);

                    err = bt_mesh_model_publish(model);

                    if (err)
                    {
                        printk("bt_mesh_model_publish err %d", err);
                    }

                }
            }       
   
            break;

        case 0x8208:    //GEN_LEVEL_SRV_STATUS

            tmp16 = net_buf_simple_pull_le16(buf);
            printk("Acknownledgement from GEN_LEVEL_SRV = %d\n\r",tmp16);

            break;

        case 0x820A:    //GEN_DELTA_SRV_UNACK
           
            break;

        case 0x820C:    //GEN_MOVE_SRV_UNACK
           
            break;

        default:

           break;
    }
}



On Wed, Apr 25, 2018 at 9:28 PM, Vikrant More <vikrant8051@...> wrote:
Hi Kai,

Please see attached mesh.zip file for what you had asked. (Refer DEVICE_composition.c for 
static struct bt_mesh_model root_models[] = {};
             static struct bt_mesh_elem elements[] = { }; )

I have break provided #ZephyrBluetoothMesh sample code into multiple files for simplicity.

Have you faced same issue ?

Please let me Know, if there is bug from my side & keep me in loop if you are going to ask further queries based on it.

Thank You !!

On Wed, Apr 25, 2018, 8:39 PM Vikrant More <vikrant8051@...> wrote:
Hi Kai,
Sorry, today I was busy & didn't get time to access my email. Right now I am on the way to my Home. Tomorrow I will definitely share what you have asked.

Thanks !!

On Wed, Apr 25, 2018, 9:21 AM Kai Ren <kren@...> wrote:
Hi vikrant8051,
Could you please share the following definitions?
             static struct bt_mesh_model root_models[] = {};
             static struct bt_mesh_elem elements[] = { };

Thanks!

Kai




Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi to all,

cd $(zephyr_base)
git fetch origin pull/7283/head:BlueZMeshctl
git checkout BlueZMeshctl 

I execute above commands & re-build samples/bluetooth/mesh & try to provision 
it using BlueZ 5.49 #meshctl. And this time, whole process has completed.

Thank You !!



On Tue, May 1, 2018 at 11:01 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
> > That's a good catch. I'm sorry for not realizing it earlier. I've
> > uploaded an untested pull request that attempts to fix this. Could
> > you
> > try it please:
> >
> >     https://github.com/zephyrproject-rtos/zephyr/pull/7283
>
> Works for me.
>
> Provisioning completes on samples/bluetooth/mesh and connects for
> configuration. The identity connection had previously failed.

Thanks for testing. Could you also please add some sort of "tested to be
working" comment in the PR to help it get merged?

> It's curious that the SILabs provisioner reportedly worked.

It'd indeed be interesting for someone to analyze the difference. E.g.
perhaps it doesn't disconnect the link in between, or maybe it connects
to Network ID advertising (however shouldn't meshctl work then as
well?).

Johan


Zephyr hci_usb nrf52840

Nathan Miller
 

Hi all,

I am trying to test an nRF52840 as a USB HCI using the Zephyr hci_usb sample project. I'm running into an issue in which devices I attempt to connect to will disconnect themselves after about 30 seconds, every time I attempt to connect. When I watch btmon, I see this:

< ACL Data TX: Handle 0 flags 0x00 dlen 7                  #15 [hci0] 17.698158
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
< HCI Command: Disconnect (0x01|0x0006) plen 3             #16 [hci0] 49.737234
        Handle: 0
        Reason: Remote User Terminated Connection (0x13)

it appears that the device never receives or never responds to the Exchange MTU Request. I'm using bluetoothctl to establish the connection. I've tried two different device types and both exhibit the problem, and when I attempt to use the internal adapter on my host, I do not have this problem with either device. My host is an x86_64 machine running Ubuntu 16.04.4, kernel version 4.13.0-39, and BlueZ version 5.49. I've attempted it with both a Nordic PCA10056 board and a Rigado BMD-340 dev board. Has anyone seen this before? I'm not entirely sure what steps to take next to debug this. I can provide any additional info necessary.


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could
you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283
Works for me.

Provisioning completes on samples/bluetooth/mesh and connects for
configuration. The identity connection had previously failed.
Thanks for testing. Could you also please add some sort of "tested to be
working" comment in the PR to help it get merged?

It's curious that the SILabs provisioner reportedly worked.
It'd indeed be interesting for someone to analyze the difference. E.g.
perhaps it doesn't disconnect the link in between, or maybe it connects
to Network ID advertising (however shouldn't meshctl work then as
well?).

Johan


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi Johan,

On Tue, 2018-05-01 at 16:37 +0100, Johan Hedberg wrote:
Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
It doesn't appear that bt_mesh_proxy_identity_enable() gets called
in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes
the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey:
7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce:
3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey:
b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005,
addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534
type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags
0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB()
added just before bt_mesh_proxy_identity_enable() >>>>>>
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could
you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283

Thanks.

Johan
Works for me.

Provisioning completes on samples/bluetooth/mesh and connects for
configuration. The identity connection had previously failed.

It's curious that the SILabs provisioner reportedly worked.

Steve


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283

Thanks.

Johan


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi,

I had a chance to look at this further.

More at the bottom.


On Thu, 2018-04-26 at 15:24 +0300, Johan Hedberg wrote:
Hi,

This was already identified as a bug in meshctl by Steve, a week ago
or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr
project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of
today, you can see that my log is the same like yours, after close
the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb

Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX: 03 00 10

GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00

Got provisioning data (12 bytes)

01 04 00 01 00 00 06 00 18 00 00 00

GATT-TX: 03 02 00 00 02 04 06

GATT-TX: 03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is
basing on the commit, c33087d3366f395168d477feb631aae1785a008e on
March 29th, it works well, you can see below screenshot that BlueZ
could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 03 00 10
GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00
Got provisioning data (12 bytes)
01 04 00 01 00 00 06 00 18 00 00 00
GATT-TX: 03 02 00 00 02 04 06
GATT-TX: 03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-
00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002add-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002ade-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys,
just guessing…

Regards,
Kai



From: Vikrant More <vikrant8051@...>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <
devel@...>, "users@..." <us
ers@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh
provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh
library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did
not complete.

This is complete log,
-----------------------------------------------------------------
-----------------------------------------------------------------
-----------------------------------------------------------------
-------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...
m<mailto:vikrant8051@...>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...<mailto:kr
en@...>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make
model configuration, use meshctl "menu onoff" to control LED on and
off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last
week, it was successful, so BlueZ works well, the issue may be from
Zephyr.

Kai

It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>

Steve


Re: Going mad about I2C #i2c #stm32 #nrf51822

Yannis Damigos
 

Hi Roman,

you need to update boards pinmux.c file to add the I2C pins. You could
check olimexino_stm32 board's pinmux file for reference.

Yannis
On Mon, Apr 30, 2018 at 10:36 AM Roman Tataurov <diytronic@...> wrote:

MCU is this
https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/arch/arm/soc/st_stm32/stm32f1
Using this board
https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/stm32_min_dev

Seems it completely off i2c devices so added to board dts
&i2c1 {
status = "ok";
};
&i2c2 {
status = "ok";
};
To make it work. Together with bug fixed about DTS
https://github.com/zephyrproject-rtos/zephyr/issues/7248 I have now I2C
device created. So code is work now.
But still no activities on device pins. Checked all the pins with logick
analser and found nothing.

I suspect some GPIO setup required.

2341 - 2360 of 3109