Date   

Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi Vinayak,

Sorry - just getting back to this problem now.

I have double-checked that SB2 is intact and that VBUS_nRF (measured at SB2) is at ~5.20V.
I have a hard time measuring if VBUS_nRF is connected to VDDH since the pin is located underneath the chip.

Could this be faulty hardware?

Regards,
Brix
--
Henrik Brix Andersen

On 29 Aug 2018, at 05.00, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH." Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 10:57 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi,

Neither. I am applying the 3V briefly to the SWDCLK input to generate a low-to-high transition on that pin.
I have just retested. Applying 3V briefly to VDD_nRF has the same effect; the board starts up and the application springs to life.

VBUS_nRF is 5.19V when plugged into USB and VDD_nRF is 0.47V (when the application isn’t running for whatever reason).
After applying ~3V briefly to SWDCLK or VDD_nRF, the application springs to life. VBUS_nRF is the same as before (5.19V) but VDD_nRF is now ~3V (as expected from the initialisation code in boards/arm/nrf52840_pca10059/board.c).

After this, the board continues to function as expected (even after resets, reflashing, etc.) until the next cold-boot (removing VBUS and restoring it).

All help is much appreciated.

Regards,
Brix
--
Henrik Brix Andersen

On 28 Aug 2018, at 22.02, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Where are you applying the 3V? to VDD_nRF or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?

I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.


From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen












Zephyr 1.13.0 Released

Nashif, Anas
 

Hi,

 

We are pleased to announce the release of Zephyr kernel version 1.13.0.

 

Major enhancements with this release include:

 

·       Extensible and Pluggable Tracing Support

·       Compartmentalized application memory organization

·       Logging System Overhaul

·       Introduce system calls for BSD socket APIs

·       Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)

·       Link Layer Discovery Protocol (LLDP) TX support

·       Support for TLS and DTLS using BSD socket API

·       Support for Link Layer Multicast Name Resolution (LLMNR)

·       Introduced reworked ADC API and updated Nordic, NXP, Atmel, and

Synopsys DesignWare drivers

·       Support OS driven Power Management framework

·       Basic support for Arm TrustZone in Armv8-M

 

The detailed release notes can be found here:

 

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.13.0

 

I would like to thank all the contributors to this release. In total 140 contributors participated in the development of 1.13.

 

Starting now, the tree is open for new features targeting 1.14 and we already have a few great features lined up and ready to be merged.

 

Thank you again,

 

Anas Nashif

 

 

 


Fw: Re: New submission from Contact Us

Saurabh Pandey <saurabh_0711@...>
 



----- Forwarded message -----

From: Thea Aldrich <aldrich.thea@...>
To: "saurabh_0711@..." <saurabh_0711@...>
Cc: Brett Preston <bpreston@...>; "thea@..." <thea@...>
Sent: Saturday, 8 September, 2018, 8:36:34 PM IST
Subject: Re: New submission from Contact Us

Hi Saurabh,
Thanks for reaching out to the Zephyr Project. For technical questions, please post to users@... or devel@...

Thank you,
Thea Aldrich 

On Sat, Sep 8, 2018, 9:58 AM Zephyr Project - General Contact Form <webmaster@...> wrote:
Name
  saurabh
Email
  saurabh_0711@...
Comment
  CMake Warning at CMakeLists.txt:4 (find_package):
By not providing
finding below issue with boilerplate. Kindly help
"Find/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake.cmake" in
CMAKE_MODULE_PATH this project has asked CMake to find a package
configuration file provided by
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake", but CMake did
not find one.

Could not find a package configuration file provided by
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake" with any of the
following names:

/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmakeConfig.cmake
/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake-config.cmake

Add the installation prefix of
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake" to
CMAKE_PREFIX_PATH or set
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake_DIR" to a
directory containing one of the above files. If
"/home/saurabh/zephyr/zephyr/cmake/app/boilerplate.cmake" provides a
separate development package or SDK, be sure it has been installed.


Re: Enable SPI driver on nrf52840

Jan Van Winkel
 

Chuck,

The only thing I needed to configure is the spi config struct (freq, spi mode of operation & cs) and it just worked out of the box.
But to be honest the only place where I used the NRF SPI is in the ILI9340 display driver[1] and that was a couple of months ago, maybe you can have a look at the SPI code in the display driver.

Regards,
Jan



On Sat, Sep 8, 2018 at 8:05 PM <cpmcparland@...> wrote:
Jan,

Thanks, missed that typo.  Fixed that, but same result.  For the moment,
I'm not worried about the data or behavior of the SPI device.  Just want to
see a driver transaction complete...data comes next.

Not very familiar with the "easy" part of easyDMA.  Do I need to configure
anything outside of the spim driver (besides the CS device and pin I'm handing to the
spi config structure)?

Regards,
Chuck


Re: Enable SPI driver on nrf52840

cpmcparland@...
 

Jan,

Thanks, missed that typo.  Fixed that, but same result.  For the moment,
I'm not worried about the data or behavior of the SPI device.  Just want to
see a driver transaction complete...data comes next.

Not very familiar with the "easy" part of easyDMA.  Do I need to configure
anything outside of the spim driver (besides the CS device and pin I'm handing to the
spi config structure)?

Regards,
Chuck


Re: Enable SPI driver on nrf52840

Jan Van Winkel
 

Hi Chuck,

Looks like you configured MOSI & MISO to the same pin (8) is this intentional?
As far as I know the NRF52840 does not support 3-wire (shared MISO/MOSI pin) SPI mode.

Regards,
Jan

On Sat, Sep 8, 2018 at 2:54 AM <cpmcparland@...> wrote:
Vinayak, Jan, et. al.

Thanks again for your combined help on this.  Just ran into a pothole and I thinks its
a simple config issue on my part.  I have a simple spi write set up and it appears
to be functional.  Am using the following prj.conf.

ONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=1
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=7
CONFIG_SPI_0_NRF_MOSI_PIN=8
CONFIG_SPI_0_NRF_MISO_PIN=8
CONFIG_SPI_0_NRF_ORC=0xff

Having some problems w/debug, so I'm salting driver code with printk's.  Ok,
that's a bit of a hack, but will get debug up after this is running.  The problem is
that the driver is not returning on completion.  Its starting up and then it waits in
the sem take call -- as it should.  But, it never completes.  I have checked the
code that loads the event handler - that's executing at os start up.  I don't have
the ASYNC flag defined in config, so I would expect it to wait until the completion
event shows up from easyDMA.  Any suggestions?

Regards,
Chuck


Re: Enable SPI driver on nrf52840

cpmcparland@...
 

Vinayak, Jan, et. al.

Thanks again for your combined help on this.  Just ran into a pothole and I thinks its
a simple config issue on my part.  I have a simple spi write set up and it appears
to be functional.  Am using the following prj.conf.

ONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=1
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=7
CONFIG_SPI_0_NRF_MOSI_PIN=8
CONFIG_SPI_0_NRF_MISO_PIN=8
CONFIG_SPI_0_NRF_ORC=0xff

Having some problems w/debug, so I'm salting driver code with printk's.  Ok,
that's a bit of a hack, but will get debug up after this is running.  The problem is
that the driver is not returning on completion.  Its starting up and then it waits in
the sem take call -- as it should.  But, it never completes.  I have checked the
code that loads the event handler - that's executing at os start up.  I don't have
the ASYNC flag defined in config, so I would expect it to wait until the completion
event shows up from easyDMA.  Any suggestions?

Regards,
Chuck


Can´t compile usign virtual machine on VirtualBox

IosuGorostiza <balcalde@...>
 

Hi evebody:
Last days I was working with Zephyr testing some samples. In the beggining I started in a PC of 64bits with a Windows 8.1 Enterprise 32bits and I found some problems that I can´t solve. Then I changed to another PC of 64bits and Windows 8.1 Enterprise 64bits. In this PC I found some problems as well, but with your help I was able to run examples and debug them. By life things, I was back to the first PC and I install a virtual machine with Virtual Box and a Windows 8.1 64bits. I started to install all the things and when try to install CMake from Chocolatey I get the next error:

"Chocolatey v0.10.11
Installing the following packages:
cmake
By installing you accept licenses for the packages.
[NuGet] An error occurred while loading packages from 'https://chocolatey.org/api/v2/': No se puede escribir datos de en la conexi¢n de transporte: Se ha forzado la interrupci¢n de una conexi¢n existente por el host remoto.
cmake not installed. The package was not found with the source(s) listed.
 Source(s): 'https://chocolatey.org/api/v2/'
 NOTE: When you specify explicit sources, it overrides default sources.
If the package version is a prerelease and you didn't specify `--pre`,
 the package may not be found.
Please see https://chocolatey.org/docs/troubleshooting for more 
 assistance.
 
Chocolatey installed 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
 
Failures
 - cmake - cmake not installed. The package was not found with the source(s) listed.
 Source(s): 'https://chocolatey.org/api/v2/'
 NOTE: When you specify explicit sources, it overrides default sources.
If the package version is a prerelease and you didn't specify `--pre`,
 the package may not be found.
Please see https://chocolatey.org/docs/troubleshooting for more 
 assistance."

I thought it´s a problem with the virtual machine and the connection to internet, so I download cmake-3.12.1-win64-x64.msi from Cmake.org and install it. When the installer ask me I choose the option "Add CMake to the system PATH for all users".
CMake installed without problems and everything else too.

Then I tried to compile the hello_world example for nrf51_pca10028 and I get the next error:

"C:\Users\usuario1\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf51_pca10028 ..
-- Selected BOARD nrf51_pca10028
Zephyr version: 1.13.0
Parsing Kconfig tree in C:/Users/usuario1/zephyr//Kconfig
Traceback (most recent call last):
  File "C:/Users/usuario1/zephyr//scripts/kconfig/kconfig.py", line 210, in <module>main()
  File "C:/Users/usuario1/zephyr//scripts/kconfig/kconfig.py", line 44, in main
    kconf = Kconfig(args.kconfig_root, warn_to_stderr=False)
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 836, in __init__
    self._parse_block(None, self.top_node, self.top_node)
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 2352, in _parse_block
    prev = self._parse_block(None, parent, prev)
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 2352, in _parse_block
    prev = self._parse_block(None, parent, prev)
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 2352, in _parse_block
    prev = self._parse_block(None, parent, prev)
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 2282, in _parse_block
    while self._has_tokens or self._next_line():
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 1677, in _next_line
    self._tokens = self._tokenize(self._line)
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 1742, in _tokenize
    self._parse_error("unknown token at start of line")
  File "C:\Users\usuario1\zephyr\scripts\kconfig\kconfiglib.py", line 3079, in _parse_error
    "{}couldn't parse '{}': {}".format(loc, self._line.rstrip(), msg))
kconfiglib.KconfigError: subsys\usb\Kconfig:1: couldn't parse '
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                       ': unknown token at start
 of line
CMake Error at C:/Users/usuario1/zephyr/cmake/kconfig.cmake:149 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  C:/Users/usuario1/zephyr/cmake/app/boilerplate.cmake:251 (include)
  CMakeLists.txt:3 (include)
 
 
-- Configuring incomplete, errors occurred!"

I don´t know where this problem is comming from. Theoretically the virtual machine has to work like the physical PC where I can compile and run the examples.
Could it be a problem with the installation of CMake?
Thanks in advance.
Best regards





Re: MPU protection falut

Jiří Kubias <jiri.kubias@...>
 

Sorry once again.

Im trying to work with DMA. How ever when I try to bind the dma I receive MPU FAULT. 

Platform is SAME70 - custom board.

My code:

    printk("a0 %s\n", CONFIG_SPI_SAM_DMA_NAME);
    dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
if (!dev_cfg->dev_dma) {
SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
return -ENODEV;
}
printk("a1\n");


and the console output  is 
a0 DMA_0
***** MPU FAULT *****
 Data Access Violation
 MMFAR Address: 0x412198
***** Hardware exception *****
Current thread ID = 0x204024b4
Faulting instruction address = 0x40e376
Fatal fault in essential thread! Spinning...

In attachment is kernel config. DMA is configured.

Any help is appreciated.

Regards, 
Jiri 




2018-09-07 9:19 GMT+02:00 Jiří Kubias <jiri.kubias@...>:

Hi,
Im trying to work with DMA. How ever when I try to bind the dma I receive MPU FAULT. 

My code:

    printk("a0 %s\n", CONFIG_SPI_SAM_DMA_NAME);
    dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
if (!dev_cfg->dev_dma) {
SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
return -ENODEV;
}
printk("a1\n");




--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================




--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


MPU protection falut

Jiří Kubias <jiri.kubias@...>
 

Hi,
Im trying to work with DMA. How ever when I try to bind the dma I receive MPU FAULT. 

My code:

    printk("a0 %s\n", CONFIG_SPI_SAM_DMA_NAME);
    dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
if (!dev_cfg->dev_dma) {
SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
return -ENODEV;
}
printk("a1\n");




--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Zephyr RC3 tagged

Nashif, Anas
 

Hi,

We are almost there, RC3 was just tagged. From a bug count perspective we are ready to release, from now on only high priority bug fixes will be merged, in addition to any documentation and release related changes.

 

The changes since RC2 can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.13.0-rc3.

 

If all goes well with this release candidate we should be able to release by Monday next week.

 

Thank you for contributing to Zephyr,

 

Anas

 

 


Zephyr Development News, 05 Sept 2018

Marti Bolivar <marti@...>
 

Hello,

This is the (day late) email for the 5 September 2018 Zephyr Development News.

HTML is available here:

https://foundries.io/insights/2018/09/05/zephyr-news-20180905/

As usual, contents are broken down as follows:

- Highlights
- Important changes
- New features
- Bug fixes
- Individual changes: a complete list of patches, sorted chronologically
and categorized into areas, like:
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

This newsletter covers the following inclusive commit range, which is
all of the patches merged between v1.13.0-rc1 and v1.13.0-rc2:

- d67095ba Kconfiglib: Make header symbol order match .config files again,
merged 22 August 2018
- 8f7990de release: Zephyr 1.13rc2, merged 30 August 2018

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

New ADC Framework:

Zephyr's ADC support has been heavily reworked, with new device drivers,
DT bindings, and board support.

New features include asynchronous usage, channel configuration, and
multi-channel sampling.

This significant change past the release candidate period was approved
by the technical steering committee on the grounds that the pull request
which included it has been open for several months. (It wasn't merged in
time for rc1 due to a few remaining issues which have since been fixed.)

The new ADC framework includes support for Nordic- and NXP Kinetis-based
devices and boards, ARC devices using DesignWare ADC IP blocks, and
Atmel SAM devices. The quark_d2000_crb board no longer has ADC support,
however.

In-tree sample applications were updated, showing how to use the new
API, which is still defined in include/adc.h and was introduced in
commit f1891e9.

One notable (and late-breaking) review comment, while agreeing that the
new API is a definite improvement, lamented the lack of trigger support.

Features
--------

Arches:

Instruction and data caches were enabled on STM32F7 SoCs.

Bluetooth:

Mirroring a change made to the PHY update code merged earlier in the
cycle, the connection update procedure now avoids an assert when
confronted with protocol errors related to procedure collision rules
observed in certain cell phones. In a related change, a new Kconfig
option, CONFIG_BT_AUTO_PHY_UPDATE, was added, which can be disabled to
allow the remote device to initiate PHY update, rather than doing so at
connection establishment time.

Boards:

The nrf52840_pca10059 and nrf52_adafruit_feather boards now support
flashing and debugging with PyOCD.

The nucleo_l432kc now has a flash storage partition.

Build:

Users can now set QEMU_BIN_PATH in their environment to specify the path
to their own QEMU binaries, rather than using those provided by the
Zephyr SDK.

They can also set the CMake variable DTS_APP_BINDINGS to specify a
directory containing out-of-tree DTS bindings.

Drivers:

A new CONFIG_ENABLE_HID_INT_OUT_EP option was added, which adds support
for an OUT interrupt endpoint in the USB HID driver. It is disabled by
default, so its merge should not affect applications using this driver.

The sensor subsystem's Kconfig choice options now have names. This
allowed board-specific support files to enable available sensors using
Kconfig default settings for these choices, instead of setting them
explicitly in defconfigs. This is useful as defaults can be easily
overridden by applications.

Scripts:

Piggy-backing on the Kconfiglib update discussed below, the
ninja menuconfig interface now shows how the Kconfig file of each symbol
was sourced in its help for each symbol, roughly like so (for
CONFIG_NET_UDP):

At subsys/net/ip/Kconfig:256
Included via some-app/KCONFIG_ROOT:86 ->
ZEPHYR_BASE/Kconfig.zephyr:35 -> subsys/Kconfig:22 ->
subsys/net/Kconfig:91
Menu path: (top menu) -> Networking -> IP stack

Bug Fixes (and Documentation)
-----------------------------

Arches:

GPIO interrupt handling on STM32L4 SoCs now works properly.

Bluetooth:

A fix to an internal procedure affecting configurations which use the
(new to v1.13) feature enabling multiple identities was merged.

Boards:

Documentation was added for qemu_nios2.

ARC boards' Kconfig files were cleaned up and updated.

The nrf52_pca10040 board now declare Flash erase block sizes properly in
DTS.

The arduino_101 Kconfig default for CONFIG_DISK_FLASH_MAX_RW_SIZE was
fixed.

The mimxrt1050_evk and udoo_neo_full_m4 got Kconfig warning fixes.

Build:

Documentation for Kconfig symbols now includes the path to access the
symbol in ninja menuconfig.

Continuous Integration:

An issue causing CI to miss fault-related output was fixed.

Device Tree:

The STM32L4 SoC family got several fixes:

- a missing flash erase block size is now declared
- the fixup file now includes the necessary definitions for using I2C3
- the gpioh and gpioi node addresses were fixed

Documentation:

The documentation itself can now be generated in PDF form if a LaTeX
installation is found.

Drivers:

The Kconfig options for the SX1509B I2C GPIO chip got dependency fixes.

Two bugs affecting the nRF GPIO driver were fixed.

The "v1" I2C driver available for some STM32 SoC families now properly
handles NACKed transactions. (The "v1" refers to the I2C IP block
itself, not a software version.)

External:

Kconfiglib was updated to upstream a28bc4da9762e, which was used to add
menu path information to the documentation and fix some bugs.

Kernel:

Fixes were merged for:

- a significant bug affecting timeout handling
- memory pools (mempool) for pools with large numbers of maximum-size
blocks
- use of interrupts when CONFIG_MULTITHREADING=n
- time slice accounting in tickless mode (with a band-aid; more
changes affecting the interaction of these two areas are expected)
- k_pipe_block_put() behavior when memory runs out
- k_poll() behavior when waiting on queues that subsequently have
waiting canceled

Libraries:

Several fixes were merged for Zephyr's CMSIS RTOS support shim.

Logging:

Fixes for out-of-bounds reads and null dereferences were merged.

Networking:

Fixes were merged affecting:

- net_udp_append_raw() timeout handling
- LWM2M formatter usage
- memory exhaustion during TCP segment creation
- retransmission of FIN packets
- handling of multiple hop-by-hop option headers
- DTLS connection closure
- polling on sockets

Samples:

Patches include fixes for the following samples:

- peripheral_hids: connection with a previously bonded device
- nvs: interoperation with MPUs, flash block erase size
- grove_light, grove_temperature: printing floats with newlib, missing
respect for CONFIG_GROVE_LIGHT_SENSOR_NAME

All samples using mbedTLS directly were removed. These were
mbedtls_sslclient, mbedtls_dtlsserver, and mbedtls_dtlsclient. This
follows from the move to socket-based TLS support.

Scripts:

A menuconfig fix for visible symbols not being shown was merged.

Storage:

NVS writes now work when the underlying flash device cannot be written
with byte-level granularity.

Testing:

Numerous enhancements and fixes were merged as the testing period
continues; refer to the individual changes for details.

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

Patches by area (154 patches total):

- Arches: 6
- Bluetooth: 8
- Boards: 13
- Build: 3
- Continuous Integration: 2
- Device Tree: 5
- Documentation: 8
- Drivers: 17
- Kernel: 12
- Libraries: 5
- Logging: 2
- Miscellaneous: 1
- Networking: 36
- Samples: 10
- Scripts: 1
- Storage: 1
- Testing: 24

Arches (6):

- 069d409b arch: arm: stm32: enable instruction and data caches on STM32F7
- c0907762 sam_e70: enable instruction and data caches on sam_e70
- 511edf01 Revert "sam_e70: enable instruction and data caches on sam_e70"
- 64b13068 arch: arm: stm32l4: add missing I2C_3 to dts.fixup
- 32a6fa1c arch: st_stm32: Remove I2C and SPI instances from common defconfig
- d2e713f9 arch: stm32l4: Enable gpio interrupts correctly

Bluetooth (8):

- 94d7669c Bluetooth: controller: Fix assert on different transaction collision
- 76599ec2 Bluetooth: Add HCI Error Code definitions required by LE controller
- f232643f Bluetooth: controller: Use HCI Error Code definitions
- 021b1232 Bluetooth: Kconfig the Auto PHY Update Procedure initiation
- f3be6316 Bluetooth: controller: Fix compile error when PHY update disabled
- c3118e66 subsys: bluetooth: host: Ensure PDUs are not allocated in ISR
- 643c8abe Bluetooth: Fix using correct IRK when generating RPA
- 4e208b24 Bluetooth: IPSP: Fix pointing to invalid file

Boards (13):

- 32652b4e boards: nios2: qemu_nios2: Add board documentation
- 0be1875e boards: cleanup and update the default config of arc boards
- 12a77e50 boards: nrf52_adafruit_feather: Add pyOCD configuration
- b92436a1 boards: nrf52840_pca10059: Add pyOCD configuration
- 9a5fdefa boards: nrf52840_pca10059: Fix pyOCD configuration
- c73f15a4 boards: nucleo_l432kc: add a storage flash partition
- 4f59c624 boards: nucleo_l432kc: mark nvs sample as supported
- 6a01c69f nrf52_pca10040: get the erase block size from dts
- 8c91001a boards: x86: arduino_101: set DISK_FLASH_MAX_RW_SIZE to 256
- 5a1ef7b1 boards: nrf: Enable ADC nodes in DTS for nRF boards
- c83769f8 boards: quark_se_c1000_ss_devboard: Enable ADC node
- ea4305a4 boards: quark_d2000_crb: Remove adc support
- 4f0f8dde boards: Remove CONFIG_OSC_EXTERNAL defconfigs from non-kinetis boards

Build (3):

- 1d4e0894 qemu: support alternate path of qemu binaries
- c1f54cc5 Kconfig: Show include paths in menuconfig and documentation
- 9f8d4290 menuconfig: Fix a case of visible symbols not being shown

Continuous Integration (2):

- 39ae72b4 sanitycheck: capture delayed faults
- 77837e81 sanitycheck: do not abort logging on faults

Device Tree (5):

- 5a16b902 dts: bindings: scan application dir for bindings
- cdbbdcae dts: stm32l4: add flash erase block size entry
- 68823b50 dts/st: fix stm32l4 gpioh gpioi node addresses
- 0a97b5bf dts: nrf: Add ADC nodes and bindings for nRF SoCs
- c995c4b4 dts: arc: Use dts tree for designware driver

Documentation (8):

- 7b548c42 doc: fix misspellings in API documentation
- 1c29bff0 doc: fix kconfig misspellings
- 1d1a4b32 doc: fix misspellings in reST files
- 9945e7fd doc: add ability to generate PDF
- 7c08fdac doc: fix wrong board name in NXP LPCXpresso54114 doc
- e6f2dff7 doc: DRAFT start for 1.13 release notes
- 1f1307e1 doc: enhance multi-level interrupts diagram
- 350026e8 doc: Add networking information to 1.13 release note

Drivers (17):

- 79836063 drivers: gpio: sx1509b: Kconfig options depend on GPIO_SX1509B
- fb10377e drivers: gpio: Fix two bugs in nrfx gpio
- 32d159e3 drivers: i2c_ll_stm32_v1: Generate STOP condition if NACK
- 7b063282 drivers: i2c_ll_stm32_v1: Handle NACK during address tranmsission
- 6b44a003 subsys: usb: class: hid: Add OUT interrupt endpoint
- 9255bf5f gpio: Use GPIO_FLAGS instead of GPIO_INT_CONF
- 18b8a633 sensors: introduce kconfig named choices
- f1891e94 drivers: adc: Introduce reworked API
- aad21ecb drivers: adc: Add shims for nrfx ADC and SAADC drivers
- 62fcfb72 drivers: adc: Select HAS_DTS_ADC for all ADC drivers
- c0ce7d02 adc: Convert mcux adc16 driver to the new adc api
- 4e551aab sam: adc: Updated SAM ADC driver.
- ef839433 drivers: Use Designware driver for sensor subsystem
- 353a69cb drivers: adc: Update new ADC APIs
- b98aeab5 drivers: Kconfig.dw: Remove unnecessary Kconfig
- a490a846 drivers: grove: Modify light sensor
- 003f0176 drivers: grove: Update temperature driver

Kernel (12):

- 71ca6530 mempool: Fix bit pointer state for N_MAX > 31
- 69d8c1c0 syscalls: Correct the type of _k_syscall_table
- 8b651492 kernel: Remove unused variable
- d8d5ec3f kernel: Fix double-list-removal corruption case in timeout handling
- bc6fb65c sched: Properly account for timeslicing in tickless mode
- 17e9d623 kernel: Enable interrupts for MULTITHREADING=n on supported arch's
- 0e07f8e9 Revert "sched: Properly account for timeslicing in tickless mode"
- 9ecc4ead sched: Properly account for timeslicing in tickless mode
- 1c6d202e kernel: pipes: fix k_pipe_block_put() when not enough space
- 45c0b204 kernel: k_poll: Introduce separate status for cancelled events
- 8daafd4f kernel: Final spin in !MULTITHREADING should be locked
- 8dcd5f8c kernel: Disable tick handling when !MULTITHREADING

Libraries (5):

- 845fdbb7 lib: cmsis_rtos_v1: replace an else case
- f72c4c52 lib/cmsis_rtos_v1: Remove redundant stack size check
- 0b8792c0 lib/cmsis_rtos_v1: Check if osKernelStart() is called from ISR
- ac787e0e lib/posix: Use static allocation for posix_thread objects
- a0879409 lib: cmsis_rtos_v1: remove unhit return case

Logging (2):

- 9624593a subsys: logging: Fix possible out-of-bounds read
- 59198514 subsys: logging: Fix possible null dereference

Miscellaneous (1):

- 8f7990de release: Zephyr 1.13rc2

Networking (36):

- 8d3510c5 net: pkt: Cleanup validation of min fragment size based on
max headers
- 8ccac9f7 net: context: Move/rename net_context_set_appdata_values()
to net_pkt.c
- 2af8dc96 net: sockets: close: Call net_context_accept only for
listening socket
- ab9f3948 net: udp: Check return value when appending UDP data
- 4fedec2e net: tcp: Handle out-of-buf properly when preparing segment
- 338dc8a9 net: tcp: Properly queue FIN packets for retransmission
- 45a394e8 net: tcp: Remove NET_TCP_FINAL_* flags
- 3b80998f net: lwm2m: correct Copyright to Foundries.io
- be2b361b net: lwm2m: check for read permission on observe
- 881fae33 net: lwm2m: fix typo in observe error message
- a166ba77 net: lwm2m: return observe errors immediately
- 6dae106d net: ipv6: Drop packet with multiple HBHO
- b0c3b357 net: tcp: Add comment of func prototype for NET_CONN_CB macro usages
- cfe27b39 net: app: Notify peers properly when DTLS connection is closed
- a2d12527 net: sockets: poll: Handle EINTR return from k_poll
- feed6bfb net: dhcpv4: Do not debug print IP address using NULL pointer
- 0f0455e0 net: lwm2m: simplify MATCH_ logic in do_read_op()
- 280f159b net: lwm2m: fix logic for lwm2m_next_engine_obj_inst()
- 485bf7a7 net: lwm2m: fix reading multiple objects that don't start at 0
- 34a135b6 net: lwm2m: allow formatters to perform processing prior to read_op
- a4001f02 net: lwm2m: plain-text: process only reads for a specific resource
- fff8422f net: lwm2m: introduce output context user_data
- 4fb29949 net: lwm2m: json formatter use private data
- 4a344e7d net: lwm2m: tlv formatter use private data
- f21b2055 net: lwm2m: remove unused members from lwm2m_output_context
- 1821c274 net: lwm2m: optimize variable order in lwm2m_perform_read_op()
- 658cb193 net: lwm2m: correct placement of put_begin/put_end in READ op
- 0561887b net: lwm2m: fix JSON format for multi-instance reads
- 019b24f1 net: lwm2m: optimize lwm2m_perform_read_op()
- 3d2c1b7d net: lwm2m: introduce put_begin/end for object instance and resources
- 90b0986b net: lwm2m: store a backup of the entire path in perform_read_op
- 24e63f12 net: lwm2m: implement begin/end processing for obj inst and resources
- 4ba19494 net: lwm2m: refactor put_begin_ri/put_end_ri into generic functions
- 7345023d net: lwm2m: TLV: mark object instance boundry when needed
- e4261161 net: lwm2m: in oma_tlv_put don't re-add value when insert is true
- d30f2abb net: lwm2m: fix formatter reader/writer initialization syntax

Samples (10):

- a4cc88ad samples: net: sockets: echo-client: fix sock fd test, allow zero.
- 0d0b221e samples: bluetooth: peripheral_hids: Add settings module
- f2662acd samples: nvs: Allow mpu flash write
- 9039d6fd samples: nvs: Use depends_on to select platforms
- 7976d2b5 samples: nvs: Use flash erase block size from dts
- 3ef2cc66 samples: mpu_stack_guard_test: Fix yaml regexes
- 42c5d519 samples: mpu_stack_guard_test: Update console output in README
- 52339f4b samples: grove_light: Provide device name from Kconfig
- 094531bf samples: grove_temperature: Use device name from Kconfig
- 38534521 samples: net: mbedtls: Remove apps using raw mbedtls APIs

Scripts (1):

- d67095ba Kconfiglib: Make header symbol order match .config files again

Storage (1):

- d47fada3 subsys: fs/nvs: fix writes when write_block_size != 1

Testing (24):

- 871cc323 tests: kernel: sched: schedule_api: Increase stack size.
- 5c3198e3 tests: power: exclude arduino_101
- 9dd63f7d tests: cmsis_rtos_v1: Add more test scenarios in mutex
- dc537eb6 tests: cmsis_rtos_v1: add semaphore negative tests
- f17b111e tests: kernel: init: Fix integer overflow issue
- 1b5db96a tests: benchmark: Check for return values
- d2b4d8f0 tests: thread_api: increase stack for test
- 3f2f6dda tests: a fix for ARC and MPU VER 3
- baabe645 tests: cmsis_rtos_v1: Wait for longer duration in k_busy_wait
- 70f85fee tests: net: mqtt: Fix rc check in mqtt_publisher test
- 24c96a8a tests: benchmarks: sys_kernel: Enable benchmark for slower SoCs
- a81aad97 tests: net: Run networking tests only for selected platforms
- 44498e6c tests: net: websocket: Fix crash when tearing down tests
- 9e161a5a tests: adc_api: Add configurations for nRF5 boards
- c68e41df tests: adc_api: Add support for kinetis boards
- 1bfa34f4 tests: adc_api: Add ARC related parameters for ADC
- 108b5398 tests: adc_api: Remove sample width test scenario
- 4a2ba0dd tests/kernel: pipes: add tests for smaller pipe buffers
- 3e41864e tests: gen_isr_table: Add barriers after triggering the irq
- 30d478a5 tests: cmsis_rtos_v1: add and enhance msgq tests
- 14742d79 tests: k_poll: Add testcase to poll fifo which gets
k_fifo_cancel_wait
- 9c68c469 tests: crypto: sha256: Add the missing test case for execution
- 2f95e240 tests/kernel/threads/no-multithreading: Disable USERSPACE
- af17c195 tests: syscalls: ignore faults, they are intentional


Re: 6LoWPAN and Zephyr

Michael Scott
 

Hello Joakim,


On 09/05/2018 12:52 PM, Joakim Eriksson wrote:
Hello,

I am going to try out the 6LoWPAN/802.15.4 stack on Zephyr OS - what boards would be reasonable
picks for testing that? I can see the EFR32 board is supported - is that a good choice and would
I be able to run the RPL-node and 6LoWPAN on that?
Looks like the nRF52840-DK board is supported for the RPL-node sample.

- Mike

Best regards,
— Joakim Eriksson, RISE SICS


Re: Private: Re: MPU fault while testing Bluetooth Mesh Sample demos

Finke Philipp (lesswire GmbH) <finke@...>
 

Hey Carles,

it’s been a while since I encountered this issue, so I don’t know the exact commit I used. I tried to run the Peripheral Bluetooth samples on a nrf52840_pca10056 board. I also got problems using the arm-zephyr-eabi toolchain built with sdk-ng on my MacBook with the v1.12.0 tag (https://lists.zephyrproject.org/g/users/topic/24152484#1017).

Mit freundlichen Grüßen / best regards,

Philipp Finke
Development Engineer
Contract Development 
lesswire GmbH | PRETTL Electronics GmbH 
 
lesswire GmbH 
Emmy-Noether-Strasse 2 
D-79110 Freiburg, Germany 
 
Phone +49 (0) 761 708 399-22 
E-Mail: finke@...








   www.lesswire.com              www.prettl-electronics.com
 
Sitz der GmbH: Rudower Chausse 30, D-12489 Berlin, Germany
Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 164706 B
Geschäftsführer: Germar Rocco Mertsching, Christian Federspiel
EU-USt.ID: DE200593545

Am 05.09.2018 um 20:45 schrieb Cufi, Carles <Carles.Cufi@...>:

Right, but we need to get to the bottom of this faults and what is causing them on master.
 
Vikrant, Phil, can you please share with us how to reproduce the issue?
 
Carles
 
From: <devel@...> on behalf of vikrant8051 <vikrant8051@...>
Date: Wednesday, 5 September 2018 at 20:33
To: Phil Hipp <finke@...>, "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Private: Re: MPU fault while testing Bluetooth Mesh Sample demos
 
Hi Phil,
Yes, you are right. If we used v1.12.99 then didn't get any MPU fault or Kernel OOPS.
 
Thanks !!
 
On Wed, Sep 5, 2018 at 4:51 PM, Phil Hipp <finke@...> wrote:
I had similar issues. Don't use the master branch, but the v1.12.0 tag.
 


6LoWPAN and Zephyr

Joakim Eriksson <joakim.eriksson@...>
 

Hello,

I am going to try out the 6LoWPAN/802.15.4 stack on Zephyr OS - what boards would be reasonable
picks for testing that? I can see the EFR32 board is supported - is that a good choice and would
I be able to run the RPL-node and 6LoWPAN on that?

Best regards,
— Joakim Eriksson, RISE SICS


Bluetooth: Mesh: issue with provisioning with #meshctl

vikrant8051 <vikrant8051@...>
 

Hi,
I'm not able to provision any sample code using Bluez v5.49 #meshctl in case of latest master branch i.e v1.13rc2.

Other observations:

1) Using #nRFMesh App (iOS) everything is Ok.

2) In case of Zephyr v1.12.99, able to provision using #meshctl as well as #nRFMesh

Thank You !!


Re: SPI driver development

Jiří Kubias <jiri.kubias@...>
 

Hi Justin,
actually I made it yesterday (adopted stm32 code), at least it is looks like that it is working somehow (both direction), but also it need some testing. However Im still missing IRQ and DMA support.  So if your code support IRQ and DMA I would like to take look at it as I need DMA support.  Im also still missing some initialization part check... Lot of stuff to do. 

Im still dont know how to handle the possibility to have various configuration for different chip select under one peripheral in Zephyr.  But I dont need this functionality and Zephyr is not ready for this.... 

Just to be clear Im using SPI peripheral not USART. 

Regards,
Jiri


2018-09-06 6:17 GMT+02:00 Justin Watson <jwatson5@...>:

Hi Jiri,

I have a good bit of a SPI driver done. It needs the reading side completed and tested. For my purposes I only did the writing side. Would you like to take it from where I left off or do you want to do your own? You are welcome either way to message me on IRC. I have written a portion of the SAM supporting code.

On Wed, Sep 5, 2018 at 12:15 AM Tomasz Bursztyka <tomasz.bursztyka@....com> wrote:
Hi Jiri,

One thing is common over all drivers is how it iterates through the r/w
buffers (drivers/spi/spi_context.h) but rest depends on hardware and
whether or not you use a HAL to access it (nrfx, stm32 are doing it for
instance).

Up to you to decide if you want to use a HAL (from Atmel's ASF) or not
then.

Br,

Tomasz

> Hi,
> I would like to try develop SPI driver for SAME70. However by looking
> to ./drivers/spi/ it seems that every driver is implemented by its
> own way (some needs workarounds in dts.fixup). Is there some spi
> driver which I can take as reference? Im quite new to this so any
> help is appreciate.
>
> Best regards,
> Jiri 
>
>







--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Re: SPI driver development

Justin
 

Hi Jiri,

I have a good bit of a SPI driver done. It needs the reading side completed and tested. For my purposes I only did the writing side. Would you like to take it from where I left off or do you want to do your own? You are welcome either way to message me on IRC. I have written a portion of the SAM supporting code.

On Wed, Sep 5, 2018 at 12:15 AM Tomasz Bursztyka <tomasz.bursztyka@...> wrote:
Hi Jiri,

One thing is common over all drivers is how it iterates through the r/w
buffers (drivers/spi/spi_context.h) but rest depends on hardware and
whether or not you use a HAL to access it (nrfx, stm32 are doing it for
instance).

Up to you to decide if you want to use a HAL (from Atmel's ASF) or not
then.

Br,

Tomasz

> Hi,
> I would like to try develop SPI driver for SAME70. However by looking
> to ./drivers/spi/ it seems that every driver is implemented by its
> own way (some needs workarounds in dts.fixup). Is there some spi
> driver which I can take as reference? Im quite new to this so any
> help is appreciate.
>
> Best regards,
> Jiri 
>
>





Re: Private: Re: MPU fault while testing Bluetooth Mesh Sample demos

Carles Cufi
 

Right, but we need to get to the bottom of this faults and what is causing them on master.

 

Vikrant, Phil, can you please share with us how to reproduce the issue?

 

Carles

 

From: <devel@...> on behalf of vikrant8051 <vikrant8051@...>
Date: Wednesday, 5 September 2018 at 20:33
To: Phil Hipp <finke@...>, "devel@..." <devel@...>
Subject: Re: [Zephyr-devel] Private: Re: MPU fault while testing Bluetooth Mesh Sample demos

 

Hi Phil,

Yes, you are right. If we used v1.12.99 then didn't get any MPU fault or Kernel OOPS.

 

Thanks !!

 

On Wed, Sep 5, 2018 at 4:51 PM, Phil Hipp <finke@...> wrote:

I had similar issues. Don't use the master branch, but the v1.12.0 tag.

 


Re: Private: Re: MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

Hi Phil,
Yes, you are right. If we used v1.12.99 then didn't get any MPU fault or Kernel OOPS.

Thanks !!

On Wed, Sep 5, 2018 at 4:51 PM, Phil Hipp <finke@...> wrote:
I had similar issues. Don't use the master branch, but the v1.12.0 tag.

2941 - 2960 of 8033