Date   

Zephyr news, 21 May 2018

Marti Bolivar
 

Hello and happy v1.12 release candidacy,

This is the 21 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/21/zephyr-news-20180521/

The goals are to give a human-readable summary of what's been merged
into master, breaking it down as follows:

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

Highlights
==========

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

- e15a4923 ("ci: Clean the capability cache when the ccache is cleaned"),
merged 14 May 2018
- e7509c17 ("release: Move version to 1.12.0-rc1"),
merged 19 May 2018

Development since the last newsletter has been active, with 300+
patches merged before last Friday's release feature freeze and
subsequent tagging of v1.12.0-rc1.

If you're unfamiliar with Zephyr's release process, see the
Development-Model page on the wiki for more details on these terms:

https://github.com/zephyrproject-rtos/zephyr/wiki/Development-Model

The v1.12 release was originally the candidate for the first Long-Term
Support release. However, the release of the first LTS has been
postponed for various reasons, including ongoing work in:

- architectural updates to the networking stack:
https://github.com/zephyrproject-rtos/zephyr/issues/7591
- device driver API stabilization:
https://github.com/zephyrproject-rtos/zephyr/issues/5697
- moving all boards to use Device tree:
https://github.com/zephyrproject-rtos/zephyr/issues/4960

Along with other issues tracked using the LTS label in Zephyr's
GitHub issues:

https://github.com/zephyrproject-rtos/zephyr/labels/LTS

An online meeting is being scheduled for further revisiting and
discussing what is required for the final LTS release; details are
expected to be released in the next day or two.

Some timelines are already available; for example, the networking
architectural updates are targeting completion of major new features in
v1.14, according to a presentation given to Zephyr's Technical Steering
Committee by Andrei Laperie of Intel:

https://drive.google.com/file/d/0B5NybbZNGEEdRVl1aEpZcFlabGRQRHN4aDB0S0wzUk9aU1Fv/view

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

OpenAMP:

OpenAMP (and its libmetal dependency) was merged to enable message-based
cross-core communication. This carries BSD-3-Clause and BSD-2-Clause
licenses.

An usage sample is in samples/subsys/openamp:

http://docs.zephyrproject.org/samples/subsys/ipc/openamp/README.html

New Zephyr SDK:

Zephyr SDK version 0.9.3 has been released. Linux users should upgrade
using the updated installation instructions:

http://docs.zephyrproject.org/getting_started/installation_linux.html

Non-volatile Storage (NVS):

A long-running pull request to add a new storage mechanism for
persistent data was merged. The new Non-Volatile Storage (NVS)
subsystem is meant as an alternative to the existing FAT and NFFS file
systems, as well as the Flash Circular Buffer (FCB) library which was
ported to Zephyr from the MyNewt RTOS.

For more details, refer to the NVS subsystem documentation:

http://docs.zephyrproject.org/subsystems/nvs/nvs.html

This would seem to pair well with the storage API changes discussed in the
previous newsletter, which introduced greater abstraction over the storage
backend.

k_call_stacks_analyze() deprecated:

The k_call_stacks_analyze() API was deprecated. Users are recommended to
switch to using k_thread_foreach():

http://docs.zephyrproject.org/api/kernel_api.html#_CPPv216k_thread_foreach18k_thread_user_cb_tPv

(Perhaps re-implementing or calling into a stack usage dumping routine for
each thread.)

Userspace changes:

Numerous userspace-related features and optimizations were merged.

New API was merged for memory management from specified memory pools. The
main functions are:

- k_mem_pool_malloc():
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv217k_mem_pool_mallocP10k_mem_pool6size_t
- k_mem_pool_free():
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv215k_mem_pool_freeP11k_mem_block

This is used to allow dynamic allocation of kernel objects from userspace.

Cleanup functions defined on a per-kernel-object-type basis can now
be invoked when an object loses all permissions. This is used as a
framework for automatic resource release for dynamically-allocated
userspace objects.

New APIs were added for userspace allocation and freeing of kernel
objects of various types:

- k_pipe_alloc_init() and k_pipe_cleanup() for pipes:
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv217k_pipe_alloc_initP6k_pipe6size_t
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv214k_pipe_cleanupP6k_pipe

- k_msgq_alloc_init() and k_msgq_cleanup() for message queues:
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv217k_msgq_alloc_initP6k_msgq6size_t5u32_t
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv214k_msgq_cleanupP6k_msgq

- k_stack_alloc_init() and k_stack_cleanup() for stack objects:

http://docs.zephyrproject.org/api/kernel_api.html#_CPPv218k_stack_alloc_initP7k_stackj
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv215k_stack_cleanupP7k_stack

Additional APIs for allowing userspace access to queues includes:

- k_queue_alloc_append() and k_queue_alloc_prepend()

http://docs.zephyrproject.org/api/kernel_api.html#_CPPv220k_queue_alloc_appendP7k_queuePv
http://docs.zephyrproject.org/api/kernel_api.html#_CPPv221k_queue_alloc_prependP7k_queuePv

- k_fifo_alloc_put():
http://docs.zephyrproject.org/api/kernel_api.html#c.k_fifo_alloc_put

- k_lifo_alloc_put():
http://docs.zephyrproject.org/api/kernel_api.html#c.k_lifo_alloc_put

The k_poll Polling API is now also accessible from user mode:

http://docs.zephyrproject.org/kernel/other/polling.html

An optimization was merged which avoids executing user/supervisor
boundary checks when invoking system calls from privileged code in
translation units defined under arch/.

Access to the k_object_access_revoke() routine from userspace was
itself revoked, closing a hole where one thread could inappropriately
revoke another's access to a kernel object. Userspace threads may
revoke access to their own objects with k_object_release().

TCP TIME_WAIT config changes:

Configuration for how long Zephyr's TCP stack remains in the TIME_WAIT
state during connection closure is now managed through the single
CONFIG_NET_TCP_TIME_WAIT_DELAY option:

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

This replaces the previous CONFIG_NET_TCP_TIME_WAIT and
CONFIG_NET_TCP_2MSL_TIME options. Applications using the old options will
need updates.

Features
--------

Architectures:

Support for Arm's v8-M cores continues, with support for secure fault
handling on Cortex-M23 along with other behind-the-scenes work on
memory access privilege checks.

There is a new CONFIG_PLATFORM_SPECIFIC_INIT available on Arm
targets. When enabled, the user must provide a _PlatformInit
routine, which will be called at Zephyr startup before anything else
happens.

Support was added to enable a Zephyr image running on an NXP LPC-based
SoC to boot a slave Cortex M0+ core. (Board support was added for the
slave core as lpcxpresso54114_m0.)

Bluetooth:

The Mesh shell now supports the recently-merged persistent storage
mechanism.

Device Tree and Drivers:

Zephyr now supports the automobile Controller Area Network (CAN)
protocol. The API is specified in include/can.h. The new API is
userspace-aware.

GPIO bindings were added for QMSI (Intel Quark) based devices, with
nodes added for quark_se_c1000_ss.

Device tree bindings were added for real-time clocks (RTCs), as well
as NXP Kinetis and QMSI based RTCs. SoC support was added for
KW41Z and quark_se_c1000_ss.

Additional patches continuing the work migrating LED and buttons
definitions to device tree were merged for mimxrt1050_evk and
lpcxpresso54114. Device tree support for sensors on the argonkey board
was also merged, along with em_starterkit device tree optimizations,
and bindings for LSM6DSL sensors and Kinetis watchdogs. A shim driver
using the newly-stabilized watchdog API was added for NXP MCUx
devices. SOC support is provided for K64 and KW2XD.

USBD (USB device) and USBFSOTG (USB full-speed On-the-Go) support was
added for NXP Kinetis SoCs. USB support was also enabled for STMicro
nucleo_f413zh.

WiFi support for the WINC1500 network controller was merged. This chip
can be used to add networking via SPI. This is the first user of the
new WiFi API which was merged during the v1.12 development
cycle. Support can be enabled using CONFIG_WIFI_WINC1500.

A driver was added for ILI9340 LCD displays.

External Libraries:

The OpenThread library version was bumped to db4759cc, to pull in some
bug fixes.

The Atmel WINC1500 WiFi driver was merged as part of enabling WiFI on
that chip. This is a BSD-3-Clause licensed HAL.

Kernel:

In a highly significant but (hopefully mostly) behind-the-scenes change,
the scheduler was rewritten:

https://github.com/zephyrproject-rtos/zephyr/commit/1acd8c2996c3a1ae0691247deff8c32519307f17

A new k_thread_foreach() API was merged, which allows iterating over
threads:

http://docs.zephyrproject.org/api/kernel_api.html#_CPPv216k_thread_foreach18k_thread_user_cb_tPv

This requires CONFIG_THREAD_MONITOR to be enabled. Creation
and termination of existing threads is blocked via irq_lock() while
the routine is executing.

Libraries:

The red-black tree implementation in include/misc/rb.h now has
RB_FOR_EACH() and RB_FOR_EACH_CONTAINER() macros, for iterating over
red-black tree nodes and the structs which contain them.

The POSIX compatibility layer has additional file system support
APIs. Pulling in the POSIX headers defines macros which map POSIX
names to Zephyr-specific file system APIs appropriately. This includes
support for basic syscalls such as open(), read(), write(), close(),
and friends, and also allows for directory operations such as
rename(), stat(), and mkdir(). Refer to the headers in include/posix
for more information.

There is also now support for the POSIX mutex APIs.

Miscellaneous:

A new API was added for a singly-linked-list like type which allows
storing two flags in each node, by relying on 4-byte pointer
aligment. For details, refer to include/misc/sflist.h.

Networking:

The LWM2M subsystem now includes support for marking resources as
optional. Any resources so marked are not initialized by the core
LWM2M subsystem; applications must initialize them using
lwm2m_engine_set_res_data() and lwm2m_engine_get_res_data(). This
also enables remote administration of these resources by the LWM2M
server through CREATE operations. It also enables future work where
BOOTSTRAP operations will behave differently when encountering
optional resources. As part of these changes, various object resources
throughout the LWM2M core and in supported IPSO objects were marked
optional appropriately.

The 802.15.4 subsystem now supports source address filtering and
performing energy detection scans when OpenThread is in use.

Samples:

New samples include:

- a RPL border router application, samples/net/rpl_border_router:
http://docs.zephyrproject.org/samples/net/rpl_border_router/README.html

- A WiFi shell sample, samples/net/wifi:
http://docs.zephyrproject.org/samples/net/wifi/README.html

- An OpenAMP usage sample, samples/subsys/openamp:
http://docs.zephyrproject.org/samples/subsys/ipc/openamp/README.html

- An MCUX IPM mailbox example, samples/subsys/ipc/ipm_mcux:
http://docs.zephyrproject.org/samples/subsys/ipc/ipm_mcux/README.html

- A sample for the 96Boards ArgonKey, samples/boards/96b_argonkey:
http://docs.zephyrproject.org/samples/boards/96b_argonkey/README.html

- A CAN sample, samples/can, tested on stm32f072b_disco:
http://docs.zephyrproject.org/samples/can/README.html

Scripts:

The flash, debug, and debugserver handlers now use a new meta-tool
called "west". This is still a behind-the-scenes change; further work
expected before the v1.12 release will add documentation for this
tool.

Testing:

The effort adding descriptions, cleanups, and other improvements to
Zephyr's test cases to use them from a higher-level test management
system continues.

Bug Fixes
---------

Numerous drivers cleanups and bug fixes went in, affecting various
devices.

Various Arm-specific fixes went in as part of the v8-M work.

A new CONFIG_BT_MESH_IVU_DIVIDER went in, which fixes an issue related
to re-initializing initialization vectors. Various other Bluetooth
cleanups and fixes went in, including removals of deprecated APIs and
unused variables and documentation fixes.

Numerous fixes and additional Doxygen descriptions went into the test
cases.

Networking fixes include net-app fixes for TLS warnings, source IPv4
address selection, build fixes with TCP disabled, and byte order
handling; ethernet MAC address setting; LWM2M port handling fixes;
dropping of invalid packets; and a couple of ICMPv6 fixes.

Various build fixes, error handling and Kconfig dependency management
improvements, k_call_stacks_analyze() removals, and more were added to
the samples.

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

Patches by area (309 patches total):

- Arches: 29
- Bluetooth: 7
- Boards: 21
- Build: 5
- Continuous Integration: 2
- Device Tree: 28
- Documentation: 12
- Drivers: 54
- External: 6
- Firmware Update: 1
- Kernel: 25
- Libraries: 11
- Maintainers: 2
- Miscellaneous: 4
- Networking: 31
- Samples: 29
- Scripts: 21
- Storage: 2
- Testing: 19

Arches (29):

- 6307b8b9 arch: arc: refactor the soc part of em_starterkit
- 47d3a90d arch: arc: reuse GCC_M_CPU in cmake file and remove unused comments
- 5eb5bb7d arch: arc: add the missing SPI_DW_SPI_CLOCK in dts.fixup
- c13b12eb arch: arc: explictly list all def config
- 9bc1dc72 arch: arm: Secure fault handling for Cortex-M23
- 0a25ad15 arch: arm: fix bug in AIRCR config on init
- 361f4ac9 arch: arm: improve fault dump for secure firmware
- 70b45c63 arch: arm: distinguish integrity signatures with/without FP
- 7c91a4a5 arch: arm: fix SecureFault IRQn for non-CMSIS compliant MCUs
- 5ab3960c arch: Cmake: Add __ZEPHYR_SUPERVISOR__ macro for arch files.
- 0b7e22bd arch: arm: Add platform init hook at __start
- fd4759b5 arch: nxp: lpc54xxx: Rename SoC bits from LPC54114 to LPC54114_M4
- a5c12b6c arch/arm/soc/nordic_nrf/nrf52: NFCT pins configuration
- 0daf69bb xtensa: fix CONFIG_INIT_STACKS for IRQ stack
- 29ed87c9 native: entropy: warn of security risk
- 167efd70 arm: mpu: nxp: set bus master 4 to write and read access
- d6f14291 arch: nxp_kinetis: enable USB device driver
- c842f32d arch: arm: Define & implement API for test target (Non-Secure)
- 600d731c arch: arm: select CPU_CORTEX_M_HAS_CMSE in ARMv8-m
- 8e0c830d arch: arm: implement cmse address range check
- b8ec6da3 arch: arm: convenience wrappers for C variable permissions checks
- e9ca0a7d nxp_kinetis: Enable mcux watchdog driver on k64, kw2xd socs
- 02253c23 nxp_kinetis: Fix rtc base address in kw41z dts.fixup
- b7312d1b arch: arm: lpc: Added support for Cortex-M0+ on lpc54114 soc
- 7514a92c arch: arm: nxp_lpc: Added support for init of slave core
- 53f91976 arch/x86: Use dts to set gpio options for quark_se and quark_d2000
- 250c4a87 arch: Use dts to set rtc priorities for Intel quark, x86 and arc
- bd9706cd arch/arc: Use dts to set gpio priorities for quark_se_c1000_ss
- 60d509f3 arch: Use dts to set i2c priorities for quark_se/quark_d2000

Bluetooth (7):

- 0fb9ea03 subsys: bluetooth: Remove deprcated k_call_stacks_analyze API
- a3c1b3db Bluetooth: Mesh: Expose bt_mesh_is_provisioned() publicly
- 4b4b6762 Bluetooth: GATT: Fix documentation of bt_gatt_notify
- cfb34d2b Bluetooth: Mesh: shell: Add persistent storage support
- 2b73c97d Bluetooth: Mesh: Fix IV Update duration tracking
- 20ea1b86 Bluetooth: Mesh: Remove redundant ivu_unknown variable
- df4220b2 Bluetooth: L2CAP: Add support for dynamically allocated PSM values

Boards (21):

- 2368edd8 mimxrt1050_evk: Move led and button definitions to dts
- b8196c89 boards: em_starterkit: add pmod mux init
- ef19b90a boards: nucleo_f413zh: enable usb
- 5ec02d14 boards: 96b_carbon: add gpios in bt controller node
- d3ea9102 boards/96b_carbon: Update doc with USB support
- 45cfea6f board: lpcxpresso54114: Move led and button definitions to dts
- 0f4a2b75 board: lpcxpresso54114: Rename to lpcxpresso54114_m4
- 5b6fde14 boards: arm: nrf: Enable mcumgr UART
- 48cc4620 boards: frdm_kw41z: enable xoroshiro on board level only
- 11c68a10 boards/arm/nrf52xx_boards: makes GPIO_AS_PINRESET common
- 103cbe8c boards: minnowboard: do not run net/bluetooth tests
- c976dbb2 boards: Document watchdog driver support on k64, kw2xd boards
- c3ce923f arm: lpcxpresso54114_m0: Add board support for slave core
- 3053f351 boards: nios2: altera_max10: Enable device support for altera_max10
- 4687c989 boards: nios2: qemu: Enable device support for qemu
- ce13fc8e boards: stm32: argonkey: Enable STM32 I2C interrupt support
- 17c15ff1 boards: stm32: argonkey: Add dts support to sensors
- c9262bb4 board: argonkey: add LSM6DSL configuration in Kconfig.defconfig
- f8288abd boards/qemu_x86: Enable fast scheduler options
- 59dc82e0 boards: adjust openocd runner arg syntax
- e73637af boards: stm: Add CAN support for stm32f072b micro controller

Build (5):

- c674167f cmake: extensions: Added a new macro zephyr_library_ifdef
- cc8b7265 cmake: Add new generate_inc_file_for_gen_target function
- 4dc9e5b2 kconfig: Get rid of 'option env' bounce symbols
- 64badd97 cmake: flash: save runner configuration to CMake cache
- aa262894 kconfig: Get rid of leading/trailing whitespace in prompts

Continuous Integration (2):

- e15a4923 ci: Clean the capability cache when the ccache is cleaned
- df9210ca ci: use new docker file with new SDK

Device Tree (28):

- e524f0b8 dts: x86: derive RAM and ROM size from dts instead of Kconfig
- 99e1f849 dts: optimize the dts for em_starterkit
- 9c7d92a6 dts: fixes in the dts of em_starterkit em9d configuration
- 532e4d22 dts: optimize and bug fixes the dts of em_starterkit
- 8cf04a18 dts/bindings: Add reset/irq gpios to zephyr,bt-hci-spi yaml
- 48e2dba2 dts: xtensa: fix build error.
- d8983e6d dts/st,stm32-usb: Add use-prop-name to disconnect-gpios
- 9c27ae71 dts: bindings: add yaml file for Kinetis USBD support
- d8cd1195 dts: arm: nxp: use DT to configure USBD on Kinetis SoC
- ae71554b dts: stm32l4: add node and fixup for i2c4
- d75291ef yaml: rtc: Add yaml definitions for RTC
- 1fe586f6 dts: nxp: kw41z: Fixup NXP Kinetis RTCs on KW41Z
- 7960f791 dts: Add kinetis watchdog bindings and update k64, kw2xd soc nodes
- 8f908f38 dts: nios2f: Add device tree support
- 29489246 dts: nios2-qemu: add device tree support
- 9e1f1acc dts/x86: Add Copyright headers to x86 dtsi files
- b8e8077c dts: Adding priority cell to Intel's IOAPIC IRQ controllers
descriptor
- e4aced51 dts/x86: Enable generating the IRQ priority on all SoCs
- 878d0fb8 dts: Add yaml descriptor for the QMSI GPIO driver
- 69e5b3ec dts/x86: Fix GPIO nodes for intel_curie and quark_d2000
- 1f2553ba dts: Add yaml descriptor for the QMSI RTC driver
- 16c455e4 dts/arc: Add rtc node to quark_se_c1000_ss
- 43878fd8 dts/bindings: Remove useless attribute in QMSI uart node descriptor
- 8bbb80e3 dts/x86: Fix UART nodes for ia32, atom and quark_x1000
- 29e51982 dts/arc: Add the GPIO nodes to quark_se_c1000_ss
- 17a2c1e6 dts: Add yaml descriptor for the QMSI SS GPIO driver
- 0ce2cc19 dts/x86: Update i2c nodes with interrupts for quark_se and
quark_d2000
- 36b0c321 dts: bindings: Add SPI yaml file for LSM6DSL sensor

Documentation (12):

- 9af44d82 doc: add native posix command line help
- 15f2035c doc: update the doc of em_starterkit
- 9342e3d3 doc: getting_started: Remove redundant and erronous doc's
- 2a892d5d doc: update mac instructions
- 941007d4 doc: Update Zephyr SDK version
- b98388c6 doc: networking: qemu_setup: Update details and add DNS information
- aa9fe261 doc: genrest: Show properties on the correct symbol definition
- 39f396a8 doc: tests: remove obsolete and bogus test groups
- 09c81379 doc: genrest: Speed up documentation rebuilding
- d1d0dd45 doc: fix missing NVS API documentation
- ef927a87 doc: fix missing networking API documentation
- f93ca237 doc: mark bt_test_cb API as not documented

Drivers (54):

- 3f249755 drivers: spi: fix the bug of slave selection in spi_dw
- 63ffbe9d usb: usb_device.c: rewrite if condition judgment
- 4b0b65c1 subsys: usb: check for invalid descriptor type request
- b0db28b5 drivers: Cmake: Add __ZEPHYR_SUPERVISOR__ macro for driver files.
- 931630ca usb: webusb: Define and use MS descriptor structures
- df5e0e00 usb: webusb: Use sizeof instead of magic numbers
- 7fa8537d usb: webusb: Trivial cleanup
- 7de55a07 pwm: stm32: Fix type for PMW3 support
- 82c0b8cb drivers/bluetooth/hci: Name the choice of BT HCI driver bus
- 49d82086 drivers/dma: dma_stm32f4x: check stream id boundaries
- e2393a00 drivers: timer: nRFx: Remove redundant code
- 05c45e35 drivers: serial: Fix race condition in nRF5 UART TX
- e61c4812 drivers: crypto: crypto_tc_shim: Set output length for all operations
- ab16853b drivers: crypto: crypto_mtls_shim: Set output length for
all operations
- 845ac3ef drivers: spi: Fix TOCTOU while transceiving SPI messages
- cd580e0b drivers/adc: Uneven buffers will lead to buffer overflow
- 9bdf1cdb drivers/wifi: Add winc1500 WiFi driver
- 2a1d222a drivers/wifi: Generalize GPIO configuration for the WINC1500 driver
- 0294c673 drivers/wifi: Move configure macros to Kconfig
- 8e65f6ab drivers/wifi: Let's go away from SPI legacy API in WINC1500
- 1e4ba823 drivers/wifi: Remove useless gpio configuration call in
winc1500 driver
- 569e70aa drivers/wifi: Split case logic into functions in winc1500 driver
- 5f9ccad9 drivers/wifi: Switch info level to debug level in winc1500 driver
- 24bb24e6 drivers/wifi: WINC1500 driver is not using WAKE pin
- 21455032 drivers/winc1500: Implement wifi mgmt offloaded API
- ce947431 drivers/wifi: Move all winc1500 related code to its own directory
- 5dc6f99c drivers: usb: add usb device driver for Kinetis USBFSOTG Controller
- 06840af1 drivers: usb: kinetis: fixup endpoint config, stall and read
- 50990cdf drivers/ieee802154: KW41Z drivers is missing hw ACK caps
- e681f9cb pwm: stm32: fix off-by-one on PWM period
- af601c22 i2c: stm32: add support for I2C4
- 70fdb7f2 pinmux: stm32l4: add I2C4 pinmux on PD12/PD13
- d0fa5872 watchdog: iwdg: honor IWDG_STM32_START_AT_BOOT
- 35cb2ba3 watchdog: stm32: fix style issue
- 4aaaccc7 rtc: Kconfig: Split off QMSI into separate Kconfig
- 27bdb833 rtc: Add prescalar configuration option
- 7b92d3fb rtc: nxp: Add RTC driver for NXP Kinetis
- 39d63d31 clock_control: Add support for getting LPO frequency in
mcux sim driver
- 474a618f watchdog: Introduce mcux wdog shim driver
- 5477ee45 mcux: Add MCUX IPM driver for lpc and kinetis socs
- 375e8d73 spi_handlers: fix some build issues
- 7e5b021b drivers: adc: fix TOCTOU attacks
- c4a62e04 drivers: serial: nrf: Fix is_pending handling
- 17c64566 drivers/uart: Use dts to set uart priorities for QMSI driver
- 61ef30d1 drivers/uart: Use dts to set uart options for ns16550 driver
- ed26b957 drivers/gpio: Removing dts generated options in QMSI Kconfig
- 00bbbae4 drivers/serial: Add port 2 instance in ns16550 driver
- ca16779d driver: ILI9340 LCD display driver
- 05234e35 driver: sample: ILI9340 sample application
- 9e12807a API: can: Add API for Controller Area Network driver
- 023e4518 drivers: can: Add Kconfig for CAN driver
- d3101b1f drivers: can: Add syscall handlers for CAN API
- 50f8296b drivers: can: Add dts bindings for CAN
- 2976ac35 drivers: can: Add CAN driver support for STM32

External (6):

- 4dd8d684 ext: Add dual core startup code for lpc54114 based on mcux 2.3.0
- 6871057e ext: Modified lpc54114 startup code from mcux for use with Zephyr.
- 4d1da3f7 ext: Add winc1500 driver from Atmel
- 89ac6b5d ext/hal: Add WINC1500 README for non-Apache 2.0 licensed contribution
- 3ddfd171 ext: Import libmetal for IPC/open-amp
- 17b64baf ext: Import OpenAMP for IPC

Firmware Update (1):

- 05148610 mgmt: Fix smp_bt.c build

Kernel (25):

- 110b8e42 kernel: Add k_thread_foreach API
- 149a3296 kernel: Deprecate k_call_stacks_analyze() API
- 8618716c kernel: Cmake: Add __ZEPHYR_SUPERVISOR__ macro for kernel files.
- d70196ba linker-defs: Increase the number of kernel objects
- 5133cf56 kernel: thread: Move out the function _thread_entry() to lib
- 577d5ddb userspace: fix kobj detection declared extern
- a2480bd4 mempool: add API for malloc semantics
- e9cfc54d kernel: remove k_object_access_revoke() as syscall
- 337e7433 userspace: automatic resource release framework
- 92e5bd74 kernel: internal APIs for thread resource pools
- 97bf001f userspace: get dynamic objs from thread rsrc pools
- 44fe8122 kernel: pipes: add k_pipe_alloc_init()
- 0fe789ff kernel: add k_msgq_alloc_init()
- f3bee951 kernel: stacks: add k_stack_alloc() init
- 47fa8eb9 userspace: generate list of kernel object sizes
- 85699f7c kernel: Fix compile warning with _impl_k_object_alloc
- 2b9b4b2c k_queue: allow user mode access via allocators
- 8345e5eb syscalls: remove policy from handler checks
- 3772f771 k_poll: expose to user mode
- 4ca0e070 kernel: Add _unpend_all convenience wrapper to scheduler API
- ccf3bf7e kernel: Fix sloppy wait queue API
- 9666c30d kernel: mem_slab: Reschedule in k_mem_slab_free only when necessary.
- c0ba11b2 kernel: Don't _arch_switch() to yourself
- 1acd8c29 kernel: Scheduler rewrite
- 3ce9c84b kernel: Wait queues aren't dlists anymore

Libraries (11):

- bcdfa76f lib: posix: Fix pthread_attr_init() return code
- 2514f3c8 libc: minimal: fix fwrite()
- ba240502 lib: rbtree: Add RB_FOR_EACH macro for iterative enumeration
- eb0aaca6 lib: posix: Add Posix Style File System API support
- eb8ba696 lib: posix: Implement posix mutex APIs
- 4e3d99ed lib: posix: Use default attribute for mutex
- 0f1d30aa lib: posix: Do not redefine PATH_MAX in unistd.h
- d33b49d4 lib/rbtree: Fix crash condition with empty trees and rb_min/max()
- 6040bf77 lib/rbtree: Fix & document insert comparison order
- 12d6329e lib/rbtree: Add RB_FOR_EACH_CONTAINER()
- f4b6daff lib/posix: Port wait_q usage to new API

Maintainers (2):

- 8b29cb84 CODEOWNERS: fix path syntax
- a631e1a1 CODEOWNERS: Fix nxp related directories

Miscellaneous (4):

- 62bff616 subsys: shell: Remove deprcated k_call_stacks_analyze API
- 79215adc list_gen: slist: mark some APIs are private
- c8010e48 sflist: slist-alike that stores flags
- e7509c17 release: Move version to 1.12.0-rc1

Networking (31):

- 9e09e2a1 OpenThread: Change SETTINGS_CONFIG_PAGE_SIZE to target specific value
- 2c987298 net: tcp: expose some TCP helper functions
- 8a21d386 net: app: fix build warning in _net_app_ssl_mainloop()
- e50cacb3 net: app: Select proper source IPv4 address in client
- 0db9af5a net: lwm2m: return error from lwm2m_engine_get_* functions
- 0d67f6a7 net: lwm2m: introduce FLAG_OPTIONAL to denote optional resources
- 4fb16db2 net: lwm2m: mark OPTIONAL resources for LwM2M Security
- 9506b427 net: lwm2m: mark OPTIONAL resources for LwM2M Server
- 12901396 net: lwm2m: mark OPTIONAL resources for LwM2M Device
- 7a1024e5 net: lwm2m: mark OPTIONAL resources for LwM2M Firmware Update
- a5bdbc17 net: lwm2m: mark OPTIONAL resources for IPSO Light Control
- b6774f0e net: lwm2m: mark OPTIONAL resources for IPSO Temperature
- 07ec5567 net: lwm2m: remove unused OBJ_FIELD_MULTI_DATA macro
- bb98d876 net: coap: add COAP_INIT_ACK_TIMEOUT_MS setting
- d07391d3 net: coap: clear more fields in coap_reply_clear()
- 89f57c22 net: tcp: Define single config option for TIME_WAIT delay
- d6dfde36 net/ethernet: Fix mac address setting through ethernet mgmt
- 49bd1e9c ieee802154: Add support for filtering source short/ieee addresses
- 69e69b7f ieee802154: Add support for energy detection scan on driver API
- cc8fab8d net: app: client: fix local port byte-order in bind_local()
- 9cbe86f8 net: app: client: handle client_addr port in net_app_init_client()
- a0210343 net: lwm2m: honor CONFIG_LWM2M_LOCAL_PORT when starting client
- 21fdf536 net: lwm2m: default LWM2M_LOCAL_PORT to 0 (random)
- a58781f5 net: lwm2m: add LWM2M_FIRMWARE_UPDATE_PULL_LOCAL_PORT setting
- 198b3586 net: lwm2m: simplify registration client
- 68ef8f06 net: conn: Drop invalid packet
- 3c09bee9 net: app: server: Fix compile error if TCP is disabled
- c0af4de7 net: openthread: Bump OpenThread commit to db4759cc
- 5f534dc6 net: openthread: Add function for getting current radio channel
- 38866179 net: icmpv6: Fix error condition
- 3a6944d8 net: icmpv6: replace NET_ASSERT with NET_ERR

Samples (29):

- 994be4dc samples: net: dns: Fix compile error
- 3df9201e samples: net: dns_resolver: Add config options for tests
- 677262e9 samples: net: lwm2m: adjust BT RX buffer count /sizes for BT
- 769c3a8b samples: boards: Remove deprcated k_call_stacks_analyze API
- ef4cb15f samples: subsys: debug: sysview: Adapt k_thread_foreach API
- d257b946 samples: net: mbedtls_sslclient: Fix prj.conf file
- 16a8a309 samples: sockets: dumb_http_server: Improve error handling
- b56b1436 samples: sockets: Make more errors fatal
- 3b8c6c70 samples: usb: webusb: Add MS-OS descriptors for compatible IDs
- 6164c60c samples: usb: webusb: Add MS OS v1.0 descriptors too
- 092f7160 samples: sockets: dumb_http_server: Disable TIME_WAIT delay
- 6cadd380 samples: net: Fix echo_server reply packet preparation
- b2fa9ada samples: smp_svr: Rename conf file
- 5ebf1a2c samples: smp_svr: Add sample.yaml
- ddc30c8e samples: leds_demo: depend on netif and gpio
- 9c113d29 samples: drivers: crypto: Print output length for all operations
- bdfbbfee samples: sensor: vl53l0x: trivial README.rst fix
- 7588680a samples: olimex_stm32_e407: ccm: trivial README.rst fix
- 554999d3 samples/net: Add a simple sample to run wifi shell module
- 45156f6e samples: cdc_acm: enable sanitycheck for Kinetis boards
- 08795cf2 samples: net: rpl: Simple RPL border router application
- 2ef50442 samples: net: rpl: Enhance RPL border router application
- 26ebb918 samples: net: rpl: Add observer support to node application
- 37b7caa6 sample: Add MCUX IPM sample application
- 0b76b128 samples: sockets: big_http_download: Update for DHCPv4 support.
- 02bb83be samples/boards: Add ArgonKey test
- ca9a98e6 samples/subsys/console: Remove unused tx_sem semaphore
- 5eb88298 sample: add OpenAMP sample application
- 2de9f2f8 samples: can: Add example code for CAN driver

Scripts (21):

- e307ba34 kconfiglib: Record which MenuNode has each property
- 6d4d8ce0 menuconfig: Show properties on the correct symbol definition
- b58cbfd6 menuconfig: Add .config loading dialog
- 2715a011 scripts: runner: add __str__ for RunnerCaps
- 1430e0c7 scripts: runner: core: don't print unless self.debug
- b6af8eb9 scripts: create meta-tool package, "west"
- 641ae471 scripts: west: add cmake utility module
- 9e7d16ac scripts: make runner a west subpackage
- 3919e70e scripts: west: remove redundant quote_sh_list definition
- 4a354e89 scripts: west: runner: add get_runner_cls()
- b611e5b1 scripts: west: add flash, debug, debugserver commands
- fbd2e92b scripts: remove zephyr_flash_debug.py
- 367c0bab scripts: west: remove command from runner arguments
- a81f0559 scripts: west: trivial fix to runner comments
- bc587d92 scripts: west: add subprocess.call wrapper to runner classes
- a9aa250b scripts: west: clean up intel_s1000 runner
- bc7b1c59 scripts: west: fix some intel_s1000 runner issues
- c9dfbfaf scripts: west: convert runner to use log module
- 5317f76d scripts: west: introduce common runner configuration
- 68e5933e scripts: west: add build directory to runner configuration
- 38e8f06f scripts: west: add context-sensitive runner help

Storage (2):

- b1e45b41 subsys: fs: Add Non Volatile Storage (NVS) for zephyr
- 72050f46 settings: Make it safe to call settings_subsys_init() multiple times

Testing (19):

- bb717783 tests: kernel: profiling: Add test for k_thread_foreach API
- 43775402 tests: Kconfig: Added a new Kconfig for qemu_x86
- 2db1c080 tests: drivers: build_all: Ensure correct builds.
- c07ec386 tests: subsys: fs: Enable proper configuration for qemu_x86.
- e2db76c9 tests/net: Fix ethernet mgmt mac change test
- a1fc3969 tests: common: fixed pointer formatting
- 36eb4dd0 tests: samples: exclude usb_kw24d512 from wpanusb sample
- eeeffcaf tests: rtc: Adjust RTC samples tests for NXP RTC
- fb74866c tests: watchdog: Update test to work with the mcux watchdog driver
- 3f43fc77 tests: watchdog: Replace platform whitelists with depends_on
- c18a1132 HACK: tests: disable output disasm for 1 ARC test
- ad6b8904 tests: kernel: Add description for test cases
- 55cf6dd7 tests: posix: Add test for Posix File System API's
- 8b31cdad tests: kernel: Add description for test cases
- c1200cd3 tests: posix: fs: Add description for test cases
- 7393cb24 tests: threads: Add test case to verify k_wakeup()
- f0eaa8e8 tests: mutex: Add test case to test mutex API
- 5e87c08a tests: posix: Increase sram size
- 0c80ee08 tests/kernel: Bump stack sizes for a few tests on qemu_x86


Re: nRF52832 General purpose retention register (GPREGRET) and Zephyr FOTA

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Rodrigo,

I am not an expert on persistent storage, but if your system undergoes frequent cold resets then the system will need to write to flash. You may refer to flash API, circular buffer or filesystem implementations in Zephyr.
More details to help you could be provided by Andrzej (cc-ed).

Regards,
Vinayak

On 21 May 2018, at 05:28, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Hi Rodrigo,

GPREGRET is general purpose retention register in the SoC, which only retains value across warm resets.


The value is lost for reset behaviours like watchdog reset, pin reset, etc. Do not use this register in applications requiring persistent storage.

Regards,
Vinayak

On 21 May 2018, at 05:16, Rodrigo Peixoto <rodrigopex@...> wrote:

Hi fellows, I am developing an application that counts pulses from a source. I need this system to be the lowest power possible. I was wondering if I could use the GPREGRET register do store this counting. Can I? My concern is that, as the documentation says, the DFU feature from Nordic also uses that retention register. Is the mcumgr + MCUBoot (FOTA) using that as well? Note that I would like to use the FOTA feature in this project.

By the way, I took a look at the Zephyr repo and the only mentions to this register is on the NRFX Nordic hal. Is that a good signal?

Thank you. Best regards, Rodrigo Peixoto.




Re: nRF52832 General purpose retention register (GPREGRET) and Zephyr FOTA

Rodrigo Peixoto
 

Thank you very much. 

I was taking a look at the NVS system. 
Let's see if it could solve the problem to me. 

Best regards,

Rodrigo Peixoto
Co-founder and Technical guru

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



2018-05-20 21:26 GMT-03:00 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>:

Hi Rodrigo,

I am not an expert on persistent storage, but if your system undergoes frequent cold resets then the system will need to write to flash. You may refer to flash API, circular buffer or filesystem implementations in Zephyr.
More details to help you could be provided by Andrzej (cc-ed).

Regards,
Vinayak

On 21 May 2018, at 05:28, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi Rodrigo,

GPREGRET is general purpose retention register in the SoC, which only retains value across warm resets.


The value is lost for reset behaviours like watchdog reset, pin reset, etc. Do not use this register in applications requiring persistent storage.

Regards,
Vinayak

On 21 May 2018, at 05:16, Rodrigo Peixoto <rodrigopex@...> wrote:

Hi fellows, I am developing an application that counts pulses from a source. I need this system to be the lowest power possible. I was wondering if I could use the GPREGRET register do store this counting. Can I? My concern is that, as the documentation says, the DFU feature from Nordic also uses that retention register. Is the mcumgr + MCUBoot (FOTA) using that as well? Note that I would like to use the FOTA feature in this project.

By the way, I took a look at the Zephyr repo and the only mentions to this register is on the NRFX Nordic hal. Is that a good signal?

Thank you. Best regards, Rodrigo Peixoto.





Re: nRF52832 General purpose retention register (GPREGRET) and Zephyr FOTA

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Rodrigo,

GPREGRET is general purpose retention register in the SoC, which only retains value across warm resets.


The value is lost for reset behaviours like watchdog reset, pin reset, etc. Do not use this register in applications requiring persistent storage.

Regards,
Vinayak

On 21 May 2018, at 05:16, Rodrigo Peixoto <rodrigopex@...> wrote:

Hi fellows, I am developing an application that counts pulses from a source. I need this system to be the lowest power possible. I was wondering if I could use the GPREGRET register do store this counting. Can I? My concern is that, as the documentation says, the DFU feature from Nordic also uses that retention register. Is the mcumgr + MCUBoot (FOTA) using that as well? Note that I would like to use the FOTA feature in this project.

By the way, I took a look at the Zephyr repo and the only mentions to this register is on the NRFX Nordic hal. Is that a good signal?

Thank you. Best regards, Rodrigo Peixoto.



Re: nRF52832 General purpose retention register (GPREGRET) and Zephyr FOTA

Rodrigo Peixoto
 

Thank you very much, Vinayak. 

Any clue on persistent storage and ultra-low power?

Best regards,
Rodrigo Peixoto.  


Rodrigo Peixoto
Co-founder and Technical guru

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



2018-05-20 20:58 GMT-03:00 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>:

Hi Rodrigo,

GPREGRET is general purpose retention register in the SoC, which only retains value across warm resets.


The value is lost for reset behaviours like watchdog reset, pin reset, etc. Do not use this register in applications requiring persistent storage.

Regards,
Vinayak


On 21 May 2018, at 05:16, Rodrigo Peixoto <rodrigopex@...> wrote:

Hi fellows, I am developing an application that counts pulses from a source. I need this system to be the lowest power possible. I was wondering if I could use the GPREGRET register do store this counting. Can I? My concern is that, as the documentation says, the DFU feature from Nordic also uses that retention register. Is the mcumgr + MCUBoot (FOTA) using that as well? Note that I would like to use the FOTA feature in this project.

By the way, I took a look at the Zephyr repo and the only mentions to this register is on the NRFX Nordic hal. Is that a good signal?

Thank you. Best regards, Rodrigo Peixoto.




nRF52832 General purpose retention register (GPREGRET) and Zephyr FOTA

Rodrigo Peixoto
 

Hi fellows, I am developing an application that counts pulses from a source. I need this system to be the lowest power possible. I was wondering if I could use the GPREGRET register do store this counting. Can I? My concern is that, as the documentation says, the DFU feature from Nordic also uses that retention register. Is the mcumgr + MCUBoot (FOTA) using that as well? Note that I would like to use the FOTA feature in this project.

By the way, I took a look at the Zephyr repo and the only mentions to this register is on the NRFX Nordic hal. Is that a good signal?

Thank you. Best regards, Rodrigo Peixoto.


Re: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

Hi.

 

I Think it will be possible – (but can’t be sure). At last Jehudi Maes (the NVS author) is considering right now ho to provide nvs-back-end for the setting (I’m in touch with him).

 

Andrzej

 

From: devel@... [mailto:devel@...] On Behalf Of vikrant8051
Sent: Wednesday, May 16, 2018 11:51 AM
To: devel@...; users@...
Subject: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage

 

Hi,

 

will it be possible to choose between #FCB & #NVS for #BluetoothMesh persistence data storage using configuration options ?

 

Thank You !!

 

 

 

 

 


Clarity on subsystem definition and PMIC device

dhguja@gmail.com
 

Hello All,
          I am starting to design a driver for PMIC device in Zephyr. I am trying to figure out how to place this driver implementation. PMIC devices usually has multiple functionalities on single chip like Voltage Regulators, Battery Charger, Fuel Gauge, Display, Haptic, LED driver etc. 

My doubts are as following :

1. What will be the definition of a Subsystem in Zephyr (I am not able to find under documentation)? From what i understood, if a driver has multiple functionalities then instead of crowding the general include folder this get a separate directory structure under "subsys". 

2. Is there any API definitions planned for PMIC devices? or these PMIC devices can already be categorized under existing Driver structure. Since some of the functionalities like Fuel Gauge, Charger can already be implemented under "sensor.h" and LED under "led.h". But if i am implementing a PMIC driver i am not sure whether to handle them all separately under PMIC structure or spread across the existing APIs.? 

It would be helpful if you can point me to similar multi functional drivers currently in Zephyr. 

Thank you for the support.

Regards,
Dhananjay G J


Re: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Thu, May 17, 2018, vikrant8051 wrote:
Is #BluetoothMesh stack completely independent from persistence storage
mechanism used by #SettingLayer ?
Mesh will work with any settings backend (currently FCB and NFFS, and in
the future with NVS).

Johan


Re: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Andrzej,

Is #BluetoothMesh stack completely independent from persistence storage mechanism used by #SettingLayer ?

If yes, then only it will possible.  😃

Thank You !!

On Thu, May 17, 2018 at 1:28 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

Hi.

 

I Think it will be possible – (but can’t be sure). At last Jehudi Maes (the NVS author) is considering right now ho to provide nvs-back-end for the setting (I’m in touch with him).

 

Andrzej

 

From: devel@... [mailto:devel@lists.zephyrproject.org] On Behalf Of vikrant8051
Sent: Wednesday, May 16, 2018 11:51 AM
To: devel@...; users@...
Subject: [Zephyr-devel] switching from #FCB to #NVS for #BluetoothMesh persistent storage

 

Hi,

 

will it be possible to choose between #FCB & #NVS for #BluetoothMesh persistence data storage using configuration options ?

 

Thank You !!

 

 

 

 

 



Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Nathan Miller
 

Pawel,

this is what I'm seeing in dmesg:

[1281987.068423] usb 1-1-port4: unable to enumerate USB device
[1281987.760149] usb 1-1.4: new full-speed USB device number 86 using ehci-pci
[1281993.003844] usb 1-1.4: device descriptor read/all, error -110
[1281993.100525] usb 1-1.4: new full-speed USB device number 87 using ehci-pci
[1281998.224837] usb 1-1.4: device descriptor read/64, error -110
[1282025.058682] usb 1-1.4: new full-speed USB device number 88 using ehci-pci
[1282030.207060] usb 1-1.4: device descriptor read/64, error -110
[1282045.840180] usb 1-1.4: device descriptor read/64, error -110
[1282046.028229] usb 1-1.4: new full-speed USB device number 89 using ehci-pci
[1282051.216492] usb 1-1.4: device descriptor read/64, error -110

It definitely looks like something isn't right. This is what happens when I connect the device running the DFU sample compiled from your branch.

On Wed, May 16, 2018 at 9:16 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

What does dmesg say?

In my case it is detected, but I have noticed 2 issues:

  • selecting alternate interface does not work, so image-1 cannot be flashed
  • image erase takes over 10sec which cause timeout and dfu failure

 

 

From: Nathan Miller [mailto:nathan.miller@...]
Sent: Tuesday, May 15, 2018 4:49 PM
To: Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: Cufi, Carles <Carles.Cufi@...>; users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Pawel,

 

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available

 

On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:

Thanks Pawel and Carles. I'll pull that branch down and test it out!

 

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Carles Cufi
 

Hi Pawel,

 

The issue with the timeout is a well known one. I think Johann had a proposal, but first we need the stable driver to be on master.

 

Carles

 

From: Zadrożniak, Paweł
Sent: 16 May 2018 16:16
To: Nathan Miller <nathan.miller@...>
Cc: Cufi, Carles <carles.cufi@...>; users@...; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

What does dmesg say?

In my case it is detected, but I have noticed 2 issues:

  • selecting alternate interface does not work, so image-1 cannot be flashed
  • image erase takes over 10sec which cause timeout and dfu failure

 

 

From: Nathan Miller [mailto:nathan.miller@...]
Sent: Tuesday, May 15, 2018 4:49 PM
To: Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: Cufi, Carles <Carles.Cufi@...>; users@...; Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Pawel,

 

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available

 

On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:

Thanks Pawel and Carles. I'll pull that branch down and test it out!

 

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages: http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Zadrożniak, Paweł <Pawel.Zadrozniak@...>
 

What does dmesg say?

In my case it is detected, but I have noticed 2 issues:

  • selecting alternate interface does not work, so image-1 cannot be flashed
  • image erase takes over 10sec which cause timeout and dfu failure

 

 

From: Nathan Miller [mailto:nathan.miller@...]
Sent: Tuesday, May 15, 2018 4:49 PM
To: Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: Cufi, Carles <Carles.Cufi@...>; users@...; Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Pawel,

 

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available

 

On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:

Thanks Pawel and Carles. I'll pull that branch down and test it out!

 

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


switching from #FCB to #NVS for #BluetoothMesh persistent storage #fcb #nvs #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,

will it be possible to choose between #FCB & #NVS for #BluetoothMesh persistence data storage using configuration options ?

Thank You !!






Re: mcuboot + dfu-util on nRF52840 not able to update firmware

Nathan Miller
 

Pawel,

I tried out the DFU sample on your branch, and I'm not seeing the device show up as a DFU capable device. If I run sudo dfu-util -l it doesn't show up in the list, and if I run sudo dfu-util --alt 1 --download signed-hello.bin I see the error

dfu-util: No DFU capable USB device available


On Fri, May 11, 2018 at 10:47 AM Nathan Miller <nathan.miller@...> wrote:
Thanks Pawel and Carles. I'll pull that branch down and test it out!

On Fri, May 11, 2018 at 10:35 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

It’s an adaptation of existing USBD driver from nRF SDK 15, not DFU-specific.

I haven’t enough time today to look at the DFU example, but I have shared my temporary version (which works with CDC example, also with logs enabled on level 4, but it’s very slow in that case) of the driver here:

 

https://github.com/pawelzadrozniak/zephyr/tree/nrfx_usbd

 

Feel free to test your application with that if you like; I will try DFU as well when I’m back in office at Monday.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 5:26 PM
To: Nathan Miller <nathan.miller@...>; Zadrożniak, Paweł <Pawel.Zadrozniak@...>
Cc: users@...; Johann Fischer <j.fischer@...>


Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

The enumeration issue might be caused by enabling logging in the USB subsystem, if you are doing that. We know that is an issue due to the delays that logging introduces during enumeration.

 

Regards,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Date: Friday, 11 May 2018 at 16:33
To: "Zadrożniak, Paweł" <Pawel.Zadrozniak@...>
Cc: "Cufi, Carles" <Carles.Cufi@...>, "users@..." <users@...>, Johann Fischer <j.fischer@...>
Subject: Re: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Thanks for the update. I'm really interested to hear what your result is, Pawel. Is this the lower-level, generic USB driver that's in rework, or is it something specific to DFU? If it's the former, could that have any impact on the apparent transport issue I'm having with the HCI sample as well? (https://lists.zephyrproject.org/g/users/topic/zephyr_hci_usb_nrf52840/18134782)

 

On Fri, May 11, 2018 at 4:39 AM Zadrożniak, Paweł <Pawel.Zadrozniak@...> wrote:

Hi.

 

I’ll try to run the example later with my work-in-progress driver and check if it works.

 

From: Cufi, Carles
Sent: Friday, May 11, 2018 11:33 AM
To: Nathan Miller <
nathan.miller@...>; users@...
Cc: Zadrożniak, Paweł <
Pawel.Zadrozniak@...>; Johann Fischer <j.fischer@...>
Subject: RE: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi Nathan,

 

This is unfortunately a known issue. The USB driver for nRF52840 is currently undergoing some heavy rework by Pawel (on copy) and he should be able to give you more details about the particular state of USB DFU itself.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Nathan Miller
Sent: 10 May 2018 23:52
To:
users@...
Subject: [Zephyr-users] mcuboot + dfu-util on nRF52840 not able to update firmware

 

Hi all,

I'm attempting to run the Zephyr USB DFU sample on an nRF52840 (pca10056 dev board) and having a bit of trouble getting it to work. I've compiled mcuboot and can load it on the board without a problem. I compiled it with no configuration changes except setting the board to nrf52840_pca10056 (
export ZEPHYR_BOARD=nrf52840_pca10056 before running cmake). I then compiled the DFU sample (samples/subsys/usb/dfu), targeting the same board. I signed the image using the following command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.hex signed-zephyr.hex

and loaded it on the board using nrfjprog. I used the hex file for the first image so as to not overwrite mcuboot, which seems to work as in the console output from the board I see this:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****

after this, I tried compiling the hello world application and signing the bin file using this command:

~/mcuboot/scripts/imgtool.py sign --key ~/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.2 --included-header ./zephyr/zephyr.bin signed-hello.bin

and loading it using dfu-util:

sudo dfu-util --alt 1 --download signed-hello.bin

This unfortunately doesn't work. The error message seems intermittent, as sometimes I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
dfu-util: Cannot set alternate interface

and sometimes instead I see

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0100
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [                         ]   0%            0 bytesdfu-util: Error during download get_status

Regardless of which error I see, it never applies the new firmware. In the second case, I see this on the device console:

[MCUBOOT] [INF] main: Starting bootloader
[MCUBOOT] [INF] boot_status_source: Image 0: magic=unset, copy_done=0xff, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Scratch: magic=unset, copy_done=0x0, image_ok=0xff
[MCUBOOT] [INF] boot_status_source: Boot source: slot 0
[MCUBOOT] [INF] boot_swap_type: Swap type: none
[MCUBOOT] [INF] main: Bootloader chainload address offset: 0xc000
[MCUBOOT] [INF] main: Jumping to the first image slot
***** Booting Zephyr OS v1.11.0-952-gdc97fc2a6 *****
[usb/dc] [ERR] handle_ctrl_ep_data_state_events: invalid event 0 in data state for EP 0

Am I doing something wrong or missing a step? I'm attempting to follow the instructions on these pages:
http://docs.zephyrproject.org/samples/subsys/usb/dfu/README.html and https://mcuboot.com/mcuboot/readme-zephyr.html
I'm a bit stuck at this point and don't exactly know how to proceed.


Re: Setting a default public MAC address in Zephyr HCI samples

Nathan Miller
 

Yes Carles, that is what we're trying to do. I've gone ahead and forked the repo so that I can change the reset function to apply the public MAC stored in the UICR.

On Mon, May 14, 2018 at 10:58 AM Cufi, Carles <Carles.Cufi@...> wrote:

So let me get this straight, you program the address into the UICR during production, and then you want the controller to read it from there right?

 

In that case unfortunately you will need to modify the actual controller code. The only currently supported feature in that regard is for the Host to read the *FICR* address that comes with every Nordic chip. The other option is to also store the address in your Host IC during production of course.

 

Thanks,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Sent: 11 May 2018 19:52
To: Cufi, Carles <carles.cufi@...>
Cc: users@...


Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

That's correct Carles, we wanted the MCU to set the MAC instead of relying on the host, which cannot read the programmed MAC in the UICR. I was trying to avoid modifying the HCI code directly, hoping for something I could do from main.c, since the HCI spec makes mention of a non-volatile default value. If that's not possible, I can add the call to ll_addr_set into hci_init.

 

On Fri, May 11, 2018 at 10:33 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Nathan,

 

Sorry I think I might have misread your original email. You want to set the address directly from the controller image, without interaction from the Host? If that is the case then you can simply add a call to ll_addr_set() in the hci_* sample you need. Not sure if that is what you need.

 

Carles

 

 

From: <users@...> on behalf of "Cufi, Carles" <carles.cufi@...>
Date: Friday, 11 May 2018 at 17:31
To: Nathan Miller <nathan.miller@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>


Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>

Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?


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


Re: Setting a default public MAC address in Zephyr HCI samples

Carles Cufi
 

So let me get this straight, you program the address into the UICR during production, and then you want the controller to read it from there right?

 

In that case unfortunately you will need to modify the actual controller code. The only currently supported feature in that regard is for the Host to read the *FICR* address that comes with every Nordic chip. The other option is to also store the address in your Host IC during production of course.

 

Thanks,

 

Carles

 

From: Nathan Miller <nathan.miller@...>
Sent: 11 May 2018 19:52
To: Cufi, Carles <carles.cufi@...>
Cc: users@...
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

That's correct Carles, we wanted the MCU to set the MAC instead of relying on the host, which cannot read the programmed MAC in the UICR. I was trying to avoid modifying the HCI code directly, hoping for something I could do from main.c, since the HCI spec makes mention of a non-volatile default value. If that's not possible, I can add the call to ll_addr_set into hci_init.

 

On Fri, May 11, 2018 at 10:33 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Nathan,

 

Sorry I think I might have misread your original email. You want to set the address directly from the controller image, without interaction from the Host? If that is the case then you can simply add a call to ll_addr_set() in the hci_* sample you need. Not sure if that is what you need.

 

Carles

 

 

From: <users@...> on behalf of "Cufi, Carles" <carles.cufi@...>
Date: Friday, 11 May 2018 at 17:31
To: Nathan Miller <nathan.miller@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Hi Nathan,

 

You need to use the Zephyr Vendor-Specific extension for this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/subsystems/bluetooth/hci.txt#L408

 

This is currently implemented for the native Link Layer:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hci/hci.c#L1798

 

It is not stored non-volatile memory though. See the hci.txt spec for details.

 

Carles

 

From: <users@...> on behalf of Nathan Miller <nathan.miller@...>


Date: Friday, 11 May 2018 at 17:24
To: "users@..." <users@...>

Subject: [Zephyr-users] Setting a default public MAC address in Zephyr HCI samples

 

Is it possible, using the HCI samples (hci_uart, hci_spi, etc) to set a default public MAC address from within zephyr? We have a MAC we'd like to use, and in my exploration of documentation I found the HCI vendor specific command Write BD_ADDR. This seems similar to what I need but the host has no way to read the MAC address to be used from the UICR on the chip, so it's not actually a viable solution. In the documentation for that command, however, it states:

The vendor specific Reset command will reset the BD_ADDR to its non-volatile default if available. Otherwise the BD_ADDR shall be reset to the invalid / non-existent 00:00:00:00:00:00 address value.

This implies there is a way to set a non-volatile public MAC address, but doesn't give any hints on how to do that. I looked through the Bluetooth documentation (http://docs.zephyrproject.org/subsystems/bluetooth/bluetooth.html) as much as I can but I'm not having much luck finding anything. Is there a standard way to set a non-volatile, default public MAC address?


Re: [Zephyr-devel] 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: [Zephyr-devel] 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

1921 - 1940 of 2727