Date   

Re: Problem with mbedtls

Vakul Garg <vakul.garg@...>
 

Hi Clemence

I was also trying to use mbedtls on frdm-k64f when I encountered handshake errors.
In my case, I used zephyr sample app mbedtls_sslclient.

See if the problem you are seeing is related to bug report I logged.

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

Regards

Vakul

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org]
On Behalf Of clemence
Sent: Monday, May 14, 2018 10:07 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Problem with mbedtls

Hi,

I am trying to use mbedtls with a NXP FRDM-K64F to connect to a server.

I get in the function "mbedtls_ssl_handshake_client_step"

I go in the case: MBEDTLS_SSL_SERVER_HELLO. The client send the message
"Client Hello" and the server receive it.

Then I go in: MBEDTLS_SSL_SERVER_CERTIFICATE. The server send the
"Server Hello" put it seems that the client does not receive it. Then the code
stop there and does not go to the other case.

It looks like that the client cannot get the message from the server and wait
for an answer.

This is the log I get when I get in the case
MBEDTLS_SSL_SERVER_CERTIFICATE

###########=> flush output
ssl_tls.c:2473: |2| => flush output
###########<= flush output
ssl_tls.c:2485: |2| <= flush output
=================> les secondes = 6
=> parse server hello
message =
=> read record: ssl->keep_current_message = 0 =================>
mbedtls_ssl_read_record = les secondes = 6 mbedtls_ssl_read_record_layer,
in => fetch input
0 - in_left: 0, nb_want: 5
=================> les secondes = 6
1 - in
12- in
&&&&&tcp_rx
net_context_recv
MIDLLLLLLLLE
END net_context_recv !!!!!
rc == 0
&&&&&  MIDDLE 0
***** BUS FAULT *****
  Executing thread ID (thread): 0x2000c334
  Faulting instruction address:  0x3a04
  Precise data bus error
  Address: 0x11f3804c
Fatal fault in thread 0x2000c334! Aborting.
net_pkt_get_tx !!!!
=================> les secondes = 16
return net_pkt_get_tx
net_pkt_get
return pkt
net_send_data !!!
NET_OK
END net_send_data


The code is stuck in the the function "net_context_recv" in the file
net_context.c.

How can I fix this problem ?


Thanks


Clemence



Zephyr news, 14 May 2018

Marti Bolivar
 

Hello,

This is the 14 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/14/zephyr-news-20180514/

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**: a complete list of patches, sorted
chronologically and categorized into areas, like:
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

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

- c5615aad ("doc: change https://zephyrproject.org/doc refs"), merged
2 May 2018

- 1b038f29 ("Bluetooth: GATT: Make BT_GATT_CHARACTERISTIC declare its
value"), merged 14 May 2018

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

New Watchdog API:

Continuing the Zephyr Long Term Support (LTS) goal of having stable driver
APIs, the watchdog.h interface was overhauled and re-worked. The
wdt_enable(), wdt_get_config(), wdt_set_config() and
wdt_api_reload() routines are still around for now, but have been
deprecated. Users of the watchdog API will want to switch to the new
routines documented in include/watchdog.h instead.

A driver using the new API was merged for the nRF SoC family's watchdog
peripheral. This driver uses device tree.

Menuconfig is now in Python:

The previously experimental Python menuconfig implementation has replaced
the C tools, following the addition of symbol search and jump-to-definition
features.

Users who were building the C tools in order to run menuconfig must use
the new Python tools instead. Windows users need to install a new
dependency via pip (by re-running "pip3 install -r
scripts/requirements.txt") before using this program. Mac and Linux users
do not require any additional dependencies.

Zephyr's use of Kconfig includes additional features not present in
the language implemented by the C tools. Somewhat confusingly,
documentation for these features was added to the board porting guide:

http://docs.zephyrproject.org/porting/board_porting.html#kconfig-extensions

This is a significant change, in that it now makes Zephyr development
possible on Windows in the native cmd.exe or Powershell shells, without any
additional Unix-specific toolchains or environments.

Storage API changes:

A variety of storage-related API changes were merged. These mostly are used
to enable new features.

The Kconfig knob which enables the storage_partition flash partition
(see http://docs.zephyrproject.org/devices/dts/flash_partitions.html)
was renamed from CONFIG_FS_FLASH_MAP_STORAGE to
CONFIG_FS_FLASH_STORAGE_PARTITION. This rename was done because use of
the storage partition does not require the flash_map module.

The filesystem API's struct fs_mount_t can now store references to
storage devices of arbitrary type in its storage_dev field; it was
previously restricted to a struct device*, but is now a void*. This
change was made to enable additional layers of indirection between this
field and the backing device.

The disk_access.h API was modified to support simultaneous use of multiple
disk interfaces. The old disk_access_ram.c and disk_access_flash.c have
seen a corresponding refactor; their globally available functions are now
hidden behind instances of the new struct disk_info and struct
disk_operations structures introduced in this change. The external FAT
file system library now supports multiple volumes.

The filesystem subsystem now supports multiple mounted instances of a
filesystem. As a result of these changes, the fs/fs_interface.h API no
longer assumes that either FAT or NFFS file systems are being used.

Bluetooth bt_storage removed in favor of settings API:

The bt_storage API was removed, as it provided features now enabled by the
settings subsystem using CONFIG_BT_SETTINGS. Users of this API will need
updates.

The Bluetooth shell and mesh and mesh_demo samples now have settings
support, as demonstrations of using the API.

Bluetooth Mesh support for the settings API required some refactoring to
expose previously hidden symbols to the storage API. There are some
tradeoffs, particularly related to managing flash wear when storing the
local sequence number and replay protection list; refer to the help for the
new CONFIG_BT_MESH_SEQ_STORE_RATE and BT_MESH_RPL_STORE_TIMEOUT options
for details.

Using this API requires a larger system workqueue stack size; the present
recommended size when using this API is now 2 KB, double its default value.

One additional alternative to using the settings API is the new
bt_set_id_addr() routine, which allows applications to set their identity
addresses in a manner similar to the bt_settings API.

Features
--------

Arches:

ARMv8-M MCUs with the Main Extension now have support for hardware-based
main stack overflow protection. The relevant Kconfig option to enable the
feature is CONFIG_BUILTIN_STACK_GUARD.

x86 CPUs can now grant user space access to the heap when using the newlib
C library.

Documentation:

In something of a "meta" development, documentation was added for how
to write Zephyr documentation:

http://docs.zephyrproject.org/contribute/doc-guidelines.html

Drivers and Device Tree:

The YAML device tree bindings for SPI now include an optional cs-gpios
property, which can be used to generate GPIO chip select definitions.

The bindings for ST's SPI-based BTLE nodes now require irq-gpios and
reset-gpios properties. The names of such devices are now only present in
Kconfig if a new CONFIG_HAS_DTS_SPI_PINS selector is unset.

There are two new Kconfig symbols, CONFIG_HAS_DTS_GPIO and
CONFIG_HAS_DTS_GPIO_DEVICE, which respectively allow declaring that the
GPIO driver supports device tree, and that drivers which need GPIOs do as
well. Currently, only the STM32 and MCUX GPIO drivers select
CONFIG_HAS_DTS_GPIO.

DT-based GPIO support for the NXP i.MX7 M4 SoC was added.

The mcux DSPI driver now uses device tree; SPI bindings were added to the
SoC files appropriately to enable this change. This driver also now
supports KW40/41Z SoCs.

The LED driver subsystem now has system call handlers for user mode
configurations.

The USB device controller driver for STM32 devices now supports all STM32
families, among a variety of other improvements to enable USB support on
STM32 MCUs in a variety of families. Board support was also added for
olimexino_stm32 and stm32f3_disco.

The pinmux subsystem no longer supports user mode access. This subsystem's
drivers lack sufficient input validation to prevent a malicious userspace
from accessing unauthorized memory through API calls. A proper fix will
require developing a specification for the subsystem, and updating existing
drivers to do appropriate input validation.

Altera HAL drivers can now be run on Zephyr. Such a driver for the Nios-II
modular scatter-gather DMA (mSGDMA) peripheral was merged, from the Altera
SDK v17. This was used to add a shim driver using Zephyr's dma.h API.

Networking:

The LWM2M implementation was significantly refactored and cleaned up. Once
nice benefit of this work is a 3KB RAM savings when running an LWM2M
client.

The network interface core now supports net_if_ipv4_select_src_addr() and
net_if_ipv4_get_ll() routines for accessing IPv4 source addresses.

Each struct net_pkt now uses one less byte of space, thanks to an
optimization in the size of its _unused field.

Testing:

The test case documentation now describes best practices for developing a
test suite, and how to list and skip test cases; see
http://docs.zephyrproject.org/subsystems/test/ztest.html for details.

Various tests were converted to use the ztest API, along with other
cleanups, renames, and Doxygen fixups added to the test suite.

Bug Fixes
---------

A build issue on sam_e70 was fixed.

An off-by-one error in the ARM MPU buffer validation routine was fixed.

A dedicated routine for incrementing the sequence number in the Bluetooth
Mesh implementation was added; in addition to fixing race conditions, this
is used by Mesh's settings subsystem integration in order to persist
sequence numbers to flash.

A Bluetooth Mesh bug affecting sequence number calculation in the Friend
queue was fixed.

Fixes to the TI ADC108S102 driver; VL53L0X, LSM6DSL, and HTS221 sensor
drivers; and QMSI UART driver were merged.

Fixes for using the FXOS8700, FXAS21002, and MCR20A drivers on NXP SoCs
were merged.

User mode heap access was fixed for applications which use the newlib C
library. User mode applications also no longer allow the stack sentinel
debugging feature to be enabled. This change was made because
CONFIG_USERSPACE implies separate and more robust stack protection
mechanisms.

The networking traffic class map from packet priorities to traffic classes
was fixed to comply with the IEEE 802.1Q specification.

The websocket implementation was refactored to avoid unnecessary tricky
calculations, resolving Coverity warnings.

The http_client sample was fixed in cases when TLS is enabled; previously,
this application overflowed a stack in this use case.

The mcumgr smp_svr sample's build was fixed.

The echo_server sample works on CC2520 again, along with other improvements
on that board. The CC3220sf board's linker map was also fixed.

The echo_server sample works on frdm_kw41z again, after other changes went
in that caused a stack overflow.

Various fixes and refactoring patches were merged to the
extract_dts_includes.py script, which generates code used by Zephyr from
the final device tree produced during an application build.

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

Patches by area (232 patches total):

- Arches: 20
- Bluetooth: 38
- Boards: 18
- Build: 5
- Continuous Integration: 8
- Device Tree: 9
- Documentation: 13
- Drivers: 29
- External: 4
- Kernel: 1
- Libraries: 2
- Maintainers: 3
- Miscellaneous: 1
- Networking: 22
- Samples: 5
- Scripts: 13
- Storage: 6
- Testing: 35

Arches (20):

- 4073db79 arch: nios2: Add _nios2_dcache_flush_no_writeback() routine
- 4a41f42e arch: arm: set interrupt stack protection with MSPLIM
- 91dc3bd0 arch: arm: ignore stack pointer limit checks during HF and NMI
- 8d1b013f arch: arm: thread built-in stack guard implementation
- e8e76ae4 arch: Add imx7d_m4 gpio definitions
- 3d691988 arm_mpu: fix off-by-one in mpu_buffer_validate
- 7f271b86 cc3220sf: soc: Update PRCM call to allow use of ROM API
- 55979aa3 arm: Add more flash and ram size options to i.MX RT MPU config
- dd26f285 arch: arm: add synchronization point after Stack Pointer switch
- fc76839b x86: grant user mode access to newlib heap
- 197e2773 arch: arm: improve description of ARMV7_M_ARMV8_M_MAINLINE option
- 47564a09 arch: arm: feature consistency checks for Cortex M regs
- 816e3d87 arch: stm32l4: add HAL_Delay for hal library hooks
- e81d9b98 arch: nxp dts bindings: Set IP clock name to matching clock
controller
- c136a107 soc: sam_e70: Mpu regions should include SRAM regions.
- b493f484 arch: arm: soc: Cleanup Kconfig inclusion per SoC
- 071212be arch: arm: atmel_sam: Fixup build issue on sam_e70
- c7dd4f55 nxp_kinetis: Enable mcux dspi driver on kw40/41z socs
- a88e31d2 nxp_kinetis: Remove unused dspi irq defines from soc.h
- 329c00dc arch/soc/st_stm32: Move STM32Cube HAL core funtions

Bluetooth (38):

- 6a71a69f Bluetooth: GATT: Fix CCC handling
- 8dd37fa7 Bluetooth: Mesh: Fix sequence number in Friend queue
- b997a283 Bluetooth: Introduce skeleton for settings-based storage
- d22b7c9f Bluetooth: Remove bt_storage API
- 470349c2 Bluetooth: settings: Add support for per-submodule handlers
- f36ea836 Bluetooth: Add support for persistent pairing keys storage
- 6af5d1cd Bluetooth: Compress bt_keys struct
- a2955436 Bluetooth: shell: Add settings support
- 10fabcd0 Bluetooth: Mesh: Move IV Update defines to net.h
- f7e780a7 Bluetooth: Mesh: Increase visibility of net & app key helpers
- ca10b6bc Bluetooth: Mesh: Remove redundant initialization
- 2be496a0 Bluetooth: Mesh: Create dedicated helper for incrementing seq
- 9540f7d5 Bluetooth: Mesh: Add skeleton for persistent storage
- 1c846651 Bluetooth: Mesh: Add storage APIs for core network values
- 3f30d12c Bluetooth: Mesh: Remove redundant 'provisioned' variable
- 43c7ef39 Bluetooth: Mesh: Move network startup operations to common function
- be7fe55b Bluetooth: Mesh: Introduce measures to avoid too frequent
flash writes
- cc3830f8 Bluetooth: Mesh: Fix resetting configuration model state
- 31afd189 Bluetooth: Mesh: Add support for clearing persistent network storage
- 5b01cb1a Bluetooth: Introduce new bt_set_id_addr() API
- c1c5f3d9 Bluetooth: Mesh: Expose destination address in bt_mesh_msg_ctx
- f6a687c0 Bluetooth: GATT: Add support to persistent CCC config
- ace19814 Bluetooth: Mesh: Convert RPL storage timer into a generic one
- 9e2189c4 Bluetooth: Mesh: Introduce generic storage timer
- b7078e14 Bluetooth: Mesh: Perform storage clearing also through delayed work
- 8703ffad Bluetooth: Mesh: Redesign element and storage info for models
- c3d5a0da Bluetooth: Mesh: Support for storing model bindings persistently
- dde2db56 Bluetooth: Mesh: Support for storing model subscriptions persistently
- efb68ca2 Bluetooth: Mesh: Support for storing model publication persistently
- 44bd5687 Bluetooth: Mesh: Support for storing heartbeat publication
persistently
- 59239032 Bluetooth: Mesh: Support for storing common configuration states
- 53c85cf8 Bluetooth: Mesh: Fix updating RPL for locally originated messages
- e2404214 Bluetooth: Mesh: Fix sequence number restoring
- da82976e Bluetooth: samples/mesh_demo: Add support for settings-based storage
- 88dfd399 Bluetooth: Mesh: Remove sequence number from bt_mesh_provision()
- 4f4afce5 Bluetooth: Remove unused rx_prio_queue
- 318a1758 Bluetooth: GATT: Introduce BT_GATT_ATTRIBUTE
- 1b038f29 Bluetooth: GATT: Make BT_GATT_CHARACTERISTIC declare its value

Boards (18):

- cdd108f6 boards: intel_s1000_crb: Assign Intel VID and PID for S1000 CRB
- 4388f6f3 boards/arm/nrf52_blenano2: add storage flash partition
- 31a2ac87 board: add gpio support for colibri_imx7d_m4 board
- f64657e8 frdm_k64f: Fix pin name typos in the board doc
- 6be824d0 cc3220sf: Fix linker map and dtsi to ensure full 256K SRAM size
- 77e9e27d mimxrt1050_evk: Add config to select code linking location
- 65e96eef boards: disco_l475_iot1: enable XSHUT master control
- 38d2567e boards: olimexino_stm32: Add USB support
- 80d69ea4 boards: stm32f3_disco: Add USB support
- 2acb1287 boards: disco_l475_iot1/dts: add gpios in bt controller node
- 90ac25f7 boards: dts: Add fxos8700 interrupt bindings and fix sensor sample
- 9cd36c7b boards: dts: Add fxas21002 interrupt bindings and fix sensor sample
- 87b95184 hexiwear_k64: Fix whitespace in dts.fixup
- ed1ab61e frdm_kw41z: Configure spi0 pinmuxes and update board doc accordingly
- ae2a9b0f boards: Select HAS_DTS_SPI_DEVICE on kinetis boards
- 0d1beb2f boards: dts: Add mcr20a bindings and fix networking samples
- 4edae077 boards/arm/olimexino_stm32: Add disconnect gpio in usb node
- 5ce10f1d boards: arm: nrf52_blenano2: Add I2C default config

Build (5):

- 60b01f3f kconfig: Refactor kconfig.py to use __main__ and argparse
- 890a5a5a kconfig: Remove targets specific to the C implementation
- 11952a60 kconfig: Remove the C Kconfig implementation
- ac7f2239 kconfig: Mention that checkconfig.py lacks Kconfiglib 2 support
- 547ed9b5 kconfig: Make 'source' non-globbing and use 'gsource'

Continuous Integration (8):

- 73440ead sanitycheck: device handler, allow running tests on real hw
- e0a6a0b6 sanitycheck: parse test results and create detailed report
- d3384fb7 sanitycheck: cleanup handler class
- 37f9dc5c sanitycheck: simplify argument passing and use global options
- a3abe967 sanitycheck: do not count duplicate tests
- 61e2163e sanitycheck: support skipped tests, enhance device handler
- 10776c44 ci: remove pyserial install
- de7fc9de sanitycheck: we need pyserial for sanitycheck

Device Tree (9):

- 16399a64 dts: mimxrt1050_evk: Add external memory nodes
- 47fe4ee7 dts/arm/st: Add USB support for stm32f070/72
- 3bbe87e1 dts/arm/st: Add usbotg_fs node to stm32l4 DT
- 11a70647 dts: spi: Add optional cs-gpios to the spi bus controller binding
- 00376f08 dts/bindings: Add reset and irq gpios to "st,spbtle-rf" yaml
- d2d4cea0 dts: nxp_kinetis: Add spi bindings for kinetis dspi and
update soc nodes
- b3107fd1 dts/bindings/usb: Add disconnect gpio in st,stm32-usb.yaml
- c0b47213 dts/arm/st: Add USB support for stm32l072/73
- 83e4947c dts: nrf: Expand nRF DTS to support watchdog

Documentation (13):

- c5615aad doc: change https://zephyrproject.org/doc refs
- 2c8a3835 doc: DRAFT start for 1.12 release notes
- 7a6f7136 doc: process test documentation
- 418cc0ea doc: Update for menuconfig.py
- 5443d065 doc: fix colibri_imx7d_m4 board documentation
- 18859171 doc: flatten doxygen-generated HTML structure
- 850b218e doc: document best practices for main.c suite declaration
- 3e136b4d doc: fix misspellings in doc and Kconfig files
- 0d12b74a doc: fix references to mailing lists
- 930dbd5d doc: Document Kconfig extensions and Zephyr-specific behavior
- 486c5a54 doc: add doc writing guides w/common usages
- 7ac624e7 doc/subsystem/settings: fix wrong settings_handler field names
- a869f875 doc: Mention that dependencies can be checked in menuconfig

Drivers (29):

- 15447fa1 drivers: dma: Add dma driver for Nios-II MSGDMA core
- 26babfc6 drivers: led: Add system call handler support
- d1bd3a6f dma: define and document the source and dest adjust enum.
- a4208365 pinmux: remove user mode access
- a0c3aadd uart_qmsi: fix possible divide-by-zero
- 97ccf99b ti_adc108s102: fix verification off-by-one
- 5dc2ab4f ti_adc108s102: validate num_entries
- b83d0782 sensor: vl53l0x: make xshut pin control optional
- 77c0456d sensors: hts221: Fix a crash due to bad device init
- 921bfeb0 drivers: usb_dc_stm32: Add support for all STM32 families
- 55dada25 drivers: usb_dc_stm32: Add usb disconnect pin support
- ad530033 drivers: pinmux_stm32l4x: add usb otg pinmux
- b1478518 drivers: usb_dc_stm32: use HSI48 if available
- e2b27d82 drivers: usb_dc_stm32: enable VDDUSB if needed
- 57904102 gpio: dts: Introduce Kconfig symbols to convey GPIO dts support
- 3fbc7c58 spi: Wrap instance configs consistently with ifdefs
- d749feb6 spi: Fix missing "depends on !HAS_DTS_SPI"
- cae90744 spi: Refactor mcux dspi driver to use dts
- 2fbb4d35 spi: Refactor mcux dspi shim driver to use clock control interface
- 4e324e21 usb: dfu: fix 'this area can not be overwritten'
- f47b9c2f drivers/usb/device: Remove USB DISCONNECT gpio options
- 3ff4065c drivers: sensors: lsm6dsl: Fix array overrun
- 2a55fcf6 drivers/usb/usb_dc_stm32: Provide EP_TYPE_* defines for L0
- c9d5b561 drivers/usb_dc_stm32: HSI48 requires VREFINT in L0
- f6a96979 drivers/stm32l0x_ll_clock: Enable SYSCFG in clock_control
- 87d62441 drivers/stm32f0x_ll_clock: Enable SYSCFG in clock_control
- aec46596 drivers/usb_dc_stm32: Check if SYSCFG is enabled
- 0c2ef4ea drivers: watchdog: Watchdog API redesign
- 30a24e8a drivers: watchdog: Add shim for nrfx WDT driver

External (4):

- 4f68b4dc ext: hal: altera: Add modular Scatter-Gather DMA HAL driver
- 9b5fa895 ext: hal: altera: Add wrapper function for Altera HAL runtime API
- e2024171 ext: hal: ti: simplelink: ensure ROM APIs used in board port file
- c5f1b0b8 ext: hal: ti: simplelink: Add comments to CMakeLists.txt

Kernel (1):

- abf77ef7 subsys: debug: Fix stack sentinel dependencies

Libraries (2):

- a8532122 newlib: libc-hooks: Print "exit" message with newline
- 42a2c964 newlib: fix heap user mode access for MPU devices

Maintainers (3):

- d9ff55f2 CODEOWNERS: add more owners to tests/*
- def4a4c1 CODEOWNERS: more fix and and updates
- 6b5ded4c CODEOWNERS: Add pfalcon for various net directories

Miscellaneous (1):

- 81bac40b gitignore: let git ignore *.patch file only to top tree

Networking (22):

- 12855789 net: if: Add functions to get correct IPv4 address
- 3e16be3c net: lwm2m: refactor engine_get_obj to be more useful
- 44c9b79a net: lwm2m: clear lwm2m_obj_path obj in string_to_path
- cf55b70b net: lwm2m: fix error code in read and write handlers
- f80c52d6 net: lwm2m: introduce LWM2M_HAS_PERM macro
- aa9a24aa net: lwm2m: remove LWM2M_OP_NONE flag and renumber the rest
- 42717a97 net: lwm2m: use BIT macro instead of LWM2M_OP_BIT
- b6ca731b net: lwm2m: remove unused CONFIG_LWM2M_BOOTSTRAP_PORT config
- f038d35a net: lwm2m: remove unused LWM2M_PEER_PORT define
- af8a0b1a net: tc: Proper packet priority to traffic class mapping
- 9681f3d0 net: Update bit size of _unused member in struct net_pkt
- 7359c5b1 net: lwm2m: Do not use snprintk() to get debugging token
- 8c2362a6 net: ip: context: Merge send_data() into the only caller
- bba1fe8c net: lwm2m: Re-order lwm2m object structs for memory alignment
- 2027c10a net: lwm2m: remove "path" from object and resource instances
- bc7a5d3a net: lwm2m: relocate/memory align notification_attrs struct
- 573c1f77 net: lwm2m: improve return errors from update_attrs()
- 6ef46e3f net: lwm2m: remove attr_list from obj, obj_inst and res_inst structs
- ad13866f net: lwm2m: remove "used" from observe_node
- fc8d0935 net: lwm2m: lower default maximum observes from 20 to 10
- e81b9043 net: websocket: Simplify building of responses
- 03f9f664 net: websocket: Revise generation of Sec-WebSocket-Accept header

Samples (5):

- 33eb03a8 samples: net: https-client: Increasing main stack size
- 94136829 samples: subsys: usb: Set disk name Kconfig option
- c913c671 smaples/mgmt/mcumgr/smp_svr: fix missing nffs.h header
- 7d9631e6 samples/net: Fix echo_client for cc2520
- d536ffa6 samples/echo_server: Increased stack sizes for testing OT on kw41z

Scripts (13):

- b737fcb9 scripts: kconfig: Add incremental search to menuconfig
- 7229a9a5 scripts: kconfig: Switch 'menuconfig' over to menuconfig.py
- 133bad78 scripts: install windows-curses package on Windows
- 65f0c679 checkpatch: downgrade COMPLEX_MACRO to a warning
- 27d34926 menuconfig: Increase indent and make Unicode more robust
- e099f381 scripts: extract_dts_includes: rename arguments for easier reading
- 081c9c3b scripts: extract_dts_includes: Generate'_0' defines only when needed
- 97a1ea22 scripts: extract_dts_includes: Fix extract_cells for a list
- ded17a91 scripts: extract_dts_includes: Fix extract_controller for a list
- 9272a3e5 scripts: extract_dts_includes: remove prefix argument
- 93d3a427 scripts: extract_includes_dts: Remove usage of cell_string
yaml attribute
- 295c1d85 menuconfig: Fix rendering of long prefilled edit box string
- e24788eb menuconfig: Make search more flexible and search prompts

Storage (6):

- 4954fe06 subsys: fs: fix generic storage partition selection
- f4dcb459 subsys: fs: fcb: fix - crc write size not aligned
- b99ff6f9 subsys: fs: Extend storage_dev type beyond 'struct device'
- 2b5b7da9 subsys: disk: Add support for multiple disk interfaces
- dd5449a7 subsys: fs: Add the support for multiple instances of fs
- cf06bc58 susbsys: settings: optimized fcb compression for deleted entry

Testing (35):

- 542f10de tests: net: ip: Refactor and add IPv4 tests
- 11120bf1 tests: remove comma from whitelist
- ee1e9886 tests: boards: altera_max10: Add test for Nios-II MSGDMA soft IP
- 7a587eea tests: document skipping tests and listing them
- cc6f8b52 tests: fp_sharing: Fix definition of PI_NUM_ITERATIONS
- 12c5bfaf tests : ipv6_fragment : Avoid NULL pointer access
- 93109f2d tests: enhance test meta-data/improve test naming
- efb52c5b tests: neighbor: use ztest asserts
- 478f6807 tests: http: call tests via ztest macro
- ee6b8761 tests: ipv6: convert to ztest
- 8603f7a4 tests: flash_map: use proper test name
- fa0a670d tests: integration: do not run test on hw
- bc672895 tests: remove duplicate tests
- 540e11ce tests: rename main test to main.c
- c57326e1 tests: fix doxygen comments
- c44f4e0e tests: alert: add doxygen documentation
- a279403c tests: remove dot after PASS|FAIL
- 01b83175 tests: subsys: fs: Add changes to support multiple FS instance
- c239ea70 tests: subsys: fs: Add test for FAT FS dual instance case
- 7174546b tests: threads: Document description for test cases
- 8e8cb4a9 tests: doxygen comment cleanup
- 2a64fe66 ztest: prints newline after failure message
- 79a0fa68 tests: mem_protect: Add memory domain testcases
- 0e8daafd tests kernel pending: unitialized variable
- 5ef03f5f tests: spi_loopback: Add frdm_kw41z configuration
- 3be0c56d tests/subsys/settings/fcb: add deleted settings compression test
- d76cc488 tests: net: checksum_offload: Check for valid UDP_HDR
- 5575487d tests: posix: Fix sigevent initialization
- f71e497d tests: net: ipv6: Add assert for net_if_config_ipv6_get
- 7e0d1d27 tests: lib: rbtree: Clarify increment of variable
- 93e71ab0 tests: net: mgmt: Do not allocate link address from stack
- d5515658 tests: net: coap: Fix uninitialized memory access
- 47638440 tests: net: tcp: IPv4 header was not initialized
- e8d0571b tests: net: tcp: Remove unnecessary code
- c9898097 tests: watchdog: Add new test implementation


Problem with mbedtls

clemence
 

Hi,

I am trying to use mbedtls with a NXP FRDM-K64F to connect to a server.

I get in the function "mbedtls_ssl_handshake_client_step"

I go in the case: MBEDTLS_SSL_SERVER_HELLO. The client send the message "Client Hello" and the server receive it.

Then I go in: MBEDTLS_SSL_SERVER_CERTIFICATE. The server send the "Server Hello" put it seems that the client does not receive it. Then the code stop there and does not go to the other case.

It looks like that the client cannot get the message from the server and wait for an answer.

This is the log I get when I get in the case MBEDTLS_SSL_SERVER_CERTIFICATE

###########=> flush output
ssl_tls.c:2473: |2| => flush output
###########<= flush output
ssl_tls.c:2485: |2| <= flush output
=================> les secondes = 6
=> parse server hello
message =
=> read record: ssl->keep_current_message = 0
=================> mbedtls_ssl_read_record = les secondes = 6
mbedtls_ssl_read_record_layer, in
=> fetch input
0 - in_left: 0, nb_want: 5
=================> les secondes = 6
1 - in
12- in
&&&&&tcp_rx
net_context_recv
MIDLLLLLLLLE
END net_context_recv !!!!!
rc == 0
&&&&&  MIDDLE 0
***** BUS FAULT *****
  Executing thread ID (thread): 0x2000c334
  Faulting instruction address:  0x3a04
  Precise data bus error
  Address: 0x11f3804c
Fatal fault in thread 0x2000c334! Aborting.
net_pkt_get_tx !!!!
=================> les secondes = 16
return net_pkt_get_tx
net_pkt_get
return pkt
net_send_data !!!
NET_OK
END net_send_data


The code is stuck in the the function "net_context_recv" in the file net_context.c.

How can I fix this problem ?


Thanks


Clemence


Re: Read connection RSSI always return -127

Carles Cufi
 

Hi there,

 

I just tried this today with the current master, and it seems to work as expected.

 

I did the following:

 

  1. Add the following to samples/bluetooth/hci_uart/nrf5.conf:

 

CONFIG_BT_CTLR_ADVANCED_FEATURES=y

CONFIG_BT_CTLR_CONN_RSSI=y

 

  1. Build the sample and flash it
  2. Attach the controller as per http://docs.zephyrproject.org/samples/bluetooth/hci_uart/README.html#using-the-controller-with-bluez
  3. Use btmgmt to power on and advertise (auto-power, connectable on, advertising on)
  4. Connect from a mobile phone
  5. Use hcitool to query the RSSI:

 

$ sudo tools/hcitool -i 1 cmd 0x05 0x0005 0x00 0x00

 

It all seems to work fine as you can see from my log:

 

https://paste.fedoraproject.org/paste/68qutfTyId6aCiwSgKa77g

 

Can you please try with the current master?

 

Regards,

 

Carles

 

From: 전형욱 <hwjeon@...>
Sent: 12 May 2018 06:39
To: Cufi, Carles <carles.cufi@...>; devel@...
Subject: Re: [Zephyr-devel] Read connection RSSI always return -127

 

Hi Carles,

Thank you for your reply.

Yes, I enable COFIG_BT_CTRL_CONN in prj.conf file.
HCI command was successfully executed but I got always -127 for rssi value.
(Please refer to btmon log in my previous message.)

Regrads,
Hyoungwook

2018-05-11 오후 6:28 Cufi, Carles () :

Hi there,

 

Strange, this should work as expected. I haven’t tested it myself but will do if you cannot figure it out.

 

Have you enabled the CONFIG_BT_CTLR_CONN_RSSI option in Kconfig?

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of ???
Sent: 10 May 2018 03:35
To: devel@...
Subject: [Zephyr-devel] Read connection RSSI always return -127

 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

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

 

 


OT Shell

Diana Rivera
 

Hi Jukka and Robert,

Thank you to both of you for your help.

Robert, I am currently using the latest Zephyr release, and the nrf52840 pca10056 platform. However, I have troubles using the shells for several subsystems. I have tried using the one for OpenThread, BT Mesh (tests/bluetooth/mesh_shell), and the samples/subsys/shell/shell_module shells, and so far, I haven't been able to make them work. The codes are compiled and are flashed with no problem; however, when it comes to writing to them, I'm able to see what I'm writing (after activating the local echo), but once I hit enter, the commands ('help' for example) have no effect.

Is there a specific way to run the shells? Or what could be the mistake or problem that might be happening?

Once again, Thank you in advance for your help!

Cheers,
Diana


Re: about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Johan,

As per nrf52840_pca10056.dts file last 16KB is used for persistent data storage.

To calculate FLASH life time, I have to understand what is going on at background (at #FCB layer).

This is my understanding,

There should be 2 parts in memory (which starts from 0xFC000)
PART-A : to save variables id
PART-B:  to save combo of {variable's data, variable's data length, variable id} in this sequence

If so then,

    editing any variable's data ==>> writing variable attributes in this sequence: {variable's data, variable's data length(1 byte), variable id(1 byte)} in Part-B


    reading  ==>> data retrieve from latest entry

(Here in Part-B, Last byte is always variable id)

Till this, am I right ?
If so, then what is size of current PART-B ?

Where I will find documentation which shows architectural implementation behind #Setting as well as #FCB layer?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

is $zephyr/tests/subsys/settings/src only option to getting started with #Setting layer ?

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

Thank You !!
 


On Mon, May 14, 2018 at 1:24 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Sat, May 12, 2018, vikrant8051 wrote:
> How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be
> depend upon setting layer which is newly introduce concept or gonna
> completely independent as part of App layer ?

The currently implementation is purely based on settings, so you can
just register your own settings subpath to store app-specific
information. I'd advise to use something else than "bt/" however, since
that's what we use for stack-internal data and wouldn't want application
code to conflict with it (or different apps to confict with each other).

> There are 2 types of Persistent Data in context of #BluetoothMesh:
> 1) constant
>      (which is created & saved during provisioning & configuration )
>
> 2) non - constant
>   ( eg. Sequence no., Models states etc.)
>
> Is current implementation using same sector of flash for both ?

It all uses the same settings API, i.e. no attempt is currently made to
split things into different categories.

I think you might have a slightly wrong idea of the different categories
of data that mesh has. The only really constant values with Mesh 1.0 are
the unicast address and the device key. And even these will change if
you do a node reset and reprovision.

Everything else, including Network Key, Application Keys, etc can and
often will change during the lifetime of the mesh network. So if you
really want to try to categorize the data into two two categories it'd
be frequently changing data, and infrequently changing (but not
constant) data.

> If Node is receiving 100 messages a day in which destination address could
> be it's own or group address for which it has subscribed, then what will be
> life of that device  (assuming SoC flash supports 10K erase cycles) as per
> FCB based current implementation ?

It depends on how you've configured CONFIG_BT_MESH_SEQ_STORE_RATE. The
nice thing with the settings API is that we could use its "export"
callback together with settings_save() to support power-loss triggered
flash writing on boards that have a small backup power source and are
able to give an interrupt of some sorts when the main one gets lost.

> Is there any documentation which shows approximate life span of
> #BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or
> upcoming #NVS layer) ?

No, and as I said, it depends on your configuration and your hardware. I
welcome you to do these calculations for some reference implementation
(hardware included) and share your results with the Zephyr project
community!

> If we use #meshctl, then sometimes it complete provisioning but it fails
> after executing
>
> --> appkey-add 1
>
> & something constantly goes on #meshctl terminal. Is anyone observed same ?

I haven't. Btw, may I ask that you in the future split different topics
to different emails? Otherwise these unrelated things may get lost on
people.

> If provisioning or configuration fails & there is no hardware reset button
> to trigger bt_mesh_reset() in that case, how to push device into factory
> reset mode ? Any Idea ?

That depends on your hardware. If it doesn't have any buttons then you
need to reflash it, I suppose.

> My solution is to add vendor state (Let it be Foo) which will be set to "1"
> only after proper provisioning & configuration by provisioner App.
>
> On device side following logic will get execute after every reset
>
>    if(Foo == 0)
>    {
>         bt_mesh_reset( );
>    }

The problem with that is that it's not really generalizable, since
there's no standard way of detecting (on the configuration server side)
when the configuration phase is complete. The best that you might be
able to do in a generic way is to have some timer that's reset after
each received configuration message, and when it expipres assume that
the configuration phase is complete. This is e.g. what the Zephyr LPN
implementation already supports in order to determine when to reduce the
scanning duty cycle (see CONFIG_BT_MESH_LPN_AUTO_TIMEOUT).

Johan


Re: Using SPI_SLAVE on STM32

Armando Visconti
 

On 05/14/2018 08:35 AM, Tomasz Bursztyka wrote:
Hi Armando,
I am not maintaining stm32 driver, I won't much of any help about it.
Get in touch with PR 5200 owner or one of the guys that created the
driver (git blame).
I see.

OK, for the moment I will work at 1Mhz speed which seems to work fine
(before was 10MHz). Then I will evaluate how to proceed here.
The code owner is superna9999 (Neil Armstrong on github)

Thanks,
Arm


Re: 64 bit time stamp in microseconds (us)

Carles Cufi
 

Hi there,

I think we should keep the discussion in the existing GitHub issue:

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

Regards,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Ziecik, Piotr
Sent: 14 May 2018 11:53
To: Abderrezak Mekkaoui <ab.mekka@clevertsystems.com>;
devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] 64 bit time stamp in microseconds (us)

Hi All,
Does anybody know how to reliably implement a 64 bit (int64_t) time
stamp in microseconds?
Thanks and have a great WE.
Abderrezak
Hi.

Could you please be a bit more precise? What reliability problem do you
have in mind?

Best Regards,
Piotr Zięcik


Re: 64 bit time stamp in microseconds (us)

Zięcik, Piotr <piotr.ziecik@...>
 

Hi All,
Does anybody know how to reliably implement a 64 bit (int64_t) time stamp in microseconds?
Thanks and have a great WE.
Abderrezak
Hi.

Could you please be a bit more precise? What reliability problem do you have in mind?

Best Regards,
Piotr Zięcik


Re: Usage of generated dts *_GPIO_FLAGS

Diego Sueiro
 

Erwan, 

I submitted a PR to apply these modifications:

--
*dS
Diego Sueiro
sent from mobile


On Mon, 14 May 2018, 8:48 am Erwan Gouriou, <erwan.gouriou@...> wrote:

I agree with you about using a more generic name (FLAGS). So basically we will need to update the "samples/basic/button/src/main.c" (SW0_GPIO_INT_CONF ->SW0_GPIO_FLAGS) application and move all SW0_GPIO_INT_CONF definitions from board.h to the respective dts file?

That's it!
 
Does anyone have a better idea?


Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/

On 4 May 2018 at 09:34, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Diego,


Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

Erwan


On 4 May 2018 at 07:33, Diego Sueiro <diego.sueiro@...> wrote:
Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/





Re: about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Sat, May 12, 2018, vikrant8051 wrote:
How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be
depend upon setting layer which is newly introduce concept or gonna
completely independent as part of App layer ?
The currently implementation is purely based on settings, so you can
just register your own settings subpath to store app-specific
information. I'd advise to use something else than "bt/" however, since
that's what we use for stack-internal data and wouldn't want application
code to conflict with it (or different apps to confict with each other).

There are 2 types of Persistent Data in context of #BluetoothMesh:
1) constant
(which is created & saved during provisioning & configuration )

2) non - constant
( eg. Sequence no., Models states etc.)

Is current implementation using same sector of flash for both ?
It all uses the same settings API, i.e. no attempt is currently made to
split things into different categories.

I think you might have a slightly wrong idea of the different categories
of data that mesh has. The only really constant values with Mesh 1.0 are
the unicast address and the device key. And even these will change if
you do a node reset and reprovision.

Everything else, including Network Key, Application Keys, etc can and
often will change during the lifetime of the mesh network. So if you
really want to try to categorize the data into two two categories it'd
be frequently changing data, and infrequently changing (but not
constant) data.

If Node is receiving 100 messages a day in which destination address could
be it's own or group address for which it has subscribed, then what will be
life of that device (assuming SoC flash supports 10K erase cycles) as per
FCB based current implementation ?
It depends on how you've configured CONFIG_BT_MESH_SEQ_STORE_RATE. The
nice thing with the settings API is that we could use its "export"
callback together with settings_save() to support power-loss triggered
flash writing on boards that have a small backup power source and are
able to give an interrupt of some sorts when the main one gets lost.

Is there any documentation which shows approximate life span of
#BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or
upcoming #NVS layer) ?
No, and as I said, it depends on your configuration and your hardware. I
welcome you to do these calculations for some reference implementation
(hardware included) and share your results with the Zephyr project
community!

If we use #meshctl, then sometimes it complete provisioning but it fails
after executing

--> appkey-add 1

& something constantly goes on #meshctl terminal. Is anyone observed same ?
I haven't. Btw, may I ask that you in the future split different topics
to different emails? Otherwise these unrelated things may get lost on
people.

If provisioning or configuration fails & there is no hardware reset button
to trigger bt_mesh_reset() in that case, how to push device into factory
reset mode ? Any Idea ?
That depends on your hardware. If it doesn't have any buttons then you
need to reflash it, I suppose.

My solution is to add vendor state (Let it be Foo) which will be set to "1"
only after proper provisioning & configuration by provisioner App.

On device side following logic will get execute after every reset

if(Foo == 0)
{
bt_mesh_reset( );
}
The problem with that is that it's not really generalizable, since
there's no standard way of detecting (on the configuration server side)
when the configuration phase is complete. The best that you might be
able to do in a generic way is to have some timer that's reset after
each received configuration message, and when it expipres assume that
the configuration phase is complete. This is e.g. what the Zephyr LPN
implementation already supports in order to determine when to reduce the
scanning duty cycle (see CONFIG_BT_MESH_LPN_AUTO_TIMEOUT).

Johan


Re: Usage of generated dts *_GPIO_FLAGS

Erwan Gouriou
 


I agree with you about using a more generic name (FLAGS). So basically we will need to update the "samples/basic/button/src/main.c" (SW0_GPIO_INT_CONF ->SW0_GPIO_FLAGS) application and move all SW0_GPIO_INT_CONF definitions from board.h to the respective dts file?

That's it!
 
Does anyone have a better idea?


Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/

On 4 May 2018 at 09:34, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Diego,


Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

Erwan


On 4 May 2018 at 07:33, Diego Sueiro <diego.sueiro@...> wrote:
Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/





Re: IPv6 addresses

Lubos, Robert
 

Hi Diana,

 

Regarding OpenThread shell, it should be enabled by default if you use OpenThread. Of course, setting CONFIG_OPENTHREAD_SHELL=y explicitly is fine as well. Just note, that when OT shell is enabled, you are not able to use OpenThrad CLI commands rightaway. You have to select OT shell during runtime by issuing `select ot` command. After that you are ready to use OpenThread CLI commands, but you have to start every command with `cmd` prefix, for example `cmd router table`. Issuing `cmd help` will print out commands available for OpenThread.

 

Regards,

Robert

 

From: devel@... [mailto:devel@...] On Behalf Of Diana Rivera
Sent: Friday, May 11, 2018 17:27
To: devel@...
Subject: Re: [Zephyr-devel] IPv6 addresses

 

Hi Jukka,

Thanks for your answer. If SLAAC is enabled by default, how are you then able to know the device's IPv6 address so that so that it can be set as the PEER_ADDR of another device?

I've been also trying to run the OpenThread shell by simply enabling CONFIG_OPENTHREAD_SHELL=y in the Kconfig file, but it doesn't seem to be having any effect. What is the proper way to run this shell?

Once again. Thank you for your answer.

Best regards,
Diana


Re: Using SPI_SLAVE on STM32

Tomasz Bursztyka
 

Hi Armando,


I am not maintaining stm32 driver, I won't much of any help about it.
Get in touch with PR 5200 owner or one of the guys that created the
driver (git blame).

Br,

Tomasz

Hello Thomasz,

Quick update before leaving for the week.

I took the patches suggested by you and I prepared
a very simple test environment. I have an issue
though: it seems that I'm not able to consume data
at the proper speed and OVR error is found in SR.

Just for testing I tried to comment the error out and
what I see is that I receive 1 byte evry 3.

I think I can slow down the spi master, but I think that
we would need to add DMA handling to stm32 spi. Is there
any plan?

Thanks,
Armando

On 05/04/2018 03:00 PM, Tomasz Bursztyka wrote:
It has not been rebased against latest SPI API changes, thus why it
can't be merged. But it's a fine PR besides that.

Tomasz


Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pul
l/52
00
You probably need the first patch, and the second is an example
how
to
do it. Note however the API has changed a bit, you'll have to
check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?








Re: IPv6 addresses

Jukka Rissanen
 

Hi Diana,

if your device is using auto address then you need to enable for
example mDNS responder support (for Linux clients) or LLMNR responder
(for windows clients) to use names instead of IP address for
connecting.

LLMNR support is not yet merged upstream but can be found at
https://github.com/zephyrproject-rtos/zephyr/pull/7251 if you want to
try it.


Cheers,
Jukka

On Fri, 2018-05-11 at 08:27 -0700, Diana Rivera wrote:
Hi Jukka,

Thanks for your answer. If SLAAC is enabled by default, how are you
then able to know the device's IPv6 address so that so that it can be
set as the PEER_ADDR of another device?

I've been also trying to run the OpenThread shell by simply enabling
CONFIG_OPENTHREAD_SHELL=y in the Kconfig file, but it doesn't seem to
be having any effect. What is the proper way to run this shell?

Once again. Thank you for your answer.

Best regards,
Diana


about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi, 

How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be depend upon setting layer which is newly introduce concept or gonna completely independent as part of App layer ?

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

There are 2 types of Persistent Data in context of #BluetoothMesh:
1) constant 
     (which is created & saved during provisioning & configuration )

2) non - constant 
  ( eg. Sequence no., Models states etc.) 

Is current implementation using same sector of flash for both ? 

Will it be secured during #DFU_OTA ?
Where it is define for every Board? Where I can get details about flash memory sector which here acting like EEPROM ?


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

If Node is receiving 100 messages a day in which destination address could be it's own or group address for which it has subscribed, then what will be life of that device  (assuming SoC flash supports 10K erase cycles) as per FCB based current implementation ?

Is there any documentation which shows approximate life span of #BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or upcoming #NVS layer) ?

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


If we use #meshctl, then sometimes it complete provisioning but it fails after executing 

--> appkey-add 1

& something constantly goes on #meshctl terminal. Is anyone observed same ? 

[In that case, I have to reflash the firmware or reset the board & send node-reset command via #meshctl.]

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

If provisioning or configuration fails & there is no hardware reset button to trigger bt_mesh_reset() in that case, how to push device into factory reset mode ? Any Idea ?

My solution is to add vendor state (Let it be Foo) which will be set to "1" only after proper provisioning & configuration by provisioner App.
 
On device side following logic will get execute after every reset

   if(Foo == 0)
   {
        bt_mesh_reset( );
   }

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


Thank You !!





Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
Following your suggestion, I just did a test on it after git fetch
7428. After compiling and running "mesh_demo", at least, sequence
number store and restore work well on my side. I use micro:bit as the
platform. :  But I have a question: when sequence number reach to
0x1A, I reset the board, after restoring, then I pressed button to
send message, sequence number start at 0x89, what is the consideration
on this? 
The idea is to avoid excessive flash writes (or worse, flash erases).
There's a variable that's set with CONFIG_BT_MESH_SEQ_STORE_RATE. It
controls that only the Nth sequence number increment gets stored. Since
only the Nth sequence gets stored, we have to add N upon bootup to the
stored value to ensure that we start with something that's guaranteed to
be higher than the last sent message when the board was powered off.

Btw, the PR is already merged to master, so you can just the master
branch from now on.

Johan


Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Hi Johan,

Following your suggestion, I just did a test on it after git fetch 7428.
After compiling and running "mesh_demo", at least, sequence number store and restore work well on my side. I use micro:bit as the platform. : 
But I have a question: when sequence number reach to 0x1A, I reset the board, after restoring, then I pressed button to send message, sequence number start at 0x89, what is the consideration on this? 

Kai


Re: Read connection RSSI always return -127

전형욱
 

Hi Carles,

Thank you for your reply.

Yes, I enable COFIG_BT_CTRL_CONN in prj.conf file.
HCI command was successfully executed but I got always -127 for rssi value.
(Please refer to btmon log in my previous message.)

Regrads,
Hyoungwook

2018-05-11 오후 6:28에 Cufi, Carles 이(가) 쓴 글:

Hi there,

 

Strange, this should work as expected. I haven’t tested it myself but will do if you cannot figure it out.

 

Have you enabled the CONFIG_BT_CTLR_CONN_RSSI option in Kconfig?

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of ???
Sent: 10 May 2018 03:35
To: devel@...
Subject: [Zephyr-devel] Read connection RSSI always return -127

 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

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

 



64 bit time stamp in microseconds (us)

Abderrezak Mekkaoui
 

Hi All,
Does anybody know how to reliably implement a 64 bit (int64_t) time stamp in microseconds?
Thanks and have a great WE.
Abderrezak

3461 - 3480 of 8033