Date   

Re: DFU via UART

Carles Cufi
 

Hi Phil,

 

the smp_svr sample already enables DFU over the console:

https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/subsys/mgmt/mcumgr/smp_svr/prj.conf#L16

You can use a simpler alternative by disabling the shell and enabling direct UART transport:

https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/subsys/mgmt/mcumgr/smp_svr/prj.conf#L17

 

The difference is just using BASE64 encoding in the shell transport.

 

Regarding the mcumgr parameters:

https://mynewt.apache.org/latest/newtmgr/command_list/newtmgr_conn.html

 

You can use a connection profile like:

mcumgr conn add myserial03 type=serial connstring="dev=/dev/ttys003, baud=115200"

 

Carles

 

From: users@... <users@...> On Behalf Of Phil Hipp
Sent: 04 September 2018 16:02
To: users@...
Subject: [Zephyr-users] DFU via UART

 

Hey,

I had a look at the smp_svr sample and was able to flash the bootloader and the sample applications (via bootloader). Now I'm wondering how to use the same Management subsystem to perform a DFU via UART. The sample just explains how to update via BLE.

What config parameters do I have to set in my .conf file and what is the correct call of the mcumgr command line tool?

Best

Phil


MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

Hi,
I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.

***** MPU FAULT *****                                                                                                            
  Instruction Access Violation                                                                                                   
***** Hardware exception *****                                                                                                   
Current thread ID = 0x2000188c                                                                                                   
Faulting instruction address = 0x20001c5c                                                                                        
Fatal fault in ISR! Spinning...


Thank You !!



DFU via UART

Phil Hipp
 

Hey,

I had a look at the smp_svr sample and was able to flash the bootloader and the sample applications (via bootloader). Now I'm wondering how to use the same Management subsystem to perform a DFU via UART. The sample just explains how to update via BLE.

What config parameters do I have to set in my .conf file and what is the correct call of the mcumgr command line tool?

Best

Phil


Re: How to use TRACEDATA pins as GPIO - #nrf52832 #customboard

Rodrigo Peixoto
 

Vinayak,
That is ok. I will open the issue on github.

After removing the code directly on the system_nrf52.c the board had stopped to answer the nrfjprog. I thought that was independent of the tracedata, but it seems to be dependent. Any idea of how can I recover the board? It is not responding on the jlink interface. 

Rodrigo Peixoto
Co-founder and Technical advisor

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




Em seg, 3 de set de 2018 às 09:29, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> escreveu:

Hi Rodrigo,


The Trace Port Interface Unit is ARM supplied component in nRF52, could you please open a GitHub issue asking for support of the same in Zephyr OS?

Also, an explain of its use in your applications requirement.

That is ok. 
 

We can then better co-ordinate with the community in adding a ARM feature support and its support in nRF52 series.


Regards,

Vinayak


From: Rodrigo Peixoto <rodrigopex@...>
Sent: Monday, September 3, 2018 11:59:19 AM
To: Chettimada, Vinayak Kariappa
Cc: users@...; Głąbek, Andrzej; Cufi, Carles
Subject: Re: [Zephyr-users] How to use TRACEDATA pins as GPIO - #nrf52832 #customboard
 
Thank you Vinayak.

For now, I will change the HAL file to solve that. When you have news about it please let me know.

Best regards,
Rodrigo Peixoto
On Mon, 3 Sep 2018 at 05:04 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Hi Rodrigo,


Glad to hear your success with first custom board made to run Zephyr.


You are right, the ENABLE_TRACE in the Nordic external MDK is not a Kconfig option in Zephyr.


This will need a new MDK release to be integrated. I will inform our team regarding this.


Regards,

Vinayak



From: users@... <users@...> on behalf of Rodrigo Peixoto <rodrigopex@...>
Sent: Sunday, September 2, 2018 4:54:59 PM
To: users@...
Subject: [Zephyr-users] How to use TRACEDATA pins as GPIO - #nrf52832 #customboard
 
Hi,
I have developed a custom board based on the nrf52832. Everything is running properly and I am glad to have my first board made to run Zephyr on it.

The only issue I am facing right now is that we have used some pins that are shared with TRACEDATA and I could not see any straightforward way of disabling it on Zephyr. Is there any? I have already disabled the CONFIG_SEGGER_SYSTEMVIEW config on my board files but it is still being used as TRACEDATA and not as GPIO. I have found the ext/hal/nordic/nrfx/mdk/system_nrf52.c file that has information related to that and says if we define ENABLE_TRACE the pins will be attached to TRACEDATA. I could not find any point where the ENABLE_TRACE is being defined. I could change the cited file in HAL directly, but I think it is not a sustainable solution.

Any clue on that?

Thank you very much.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

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


--
Rodrigo Peixoto
Co-founder and Technical guru

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

.


Re: How to use TRACEDATA pins as GPIO - #nrf52832 #customboard

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

Hi Rodrigo,


The Trace Port Interface Unit is ARM supplied component in nRF52, could you please open a GitHub issue asking for support of the same in Zephyr OS?

Also, an explain of its use in your applications requirement.


We can then better co-ordinate with the community in adding a ARM feature support and its support in nRF52 series.


Regards,

Vinayak


From: Rodrigo Peixoto <rodrigopex@...>
Sent: Monday, September 3, 2018 11:59:19 AM
To: Chettimada, Vinayak Kariappa
Cc: users@...; Głąbek, Andrzej; Cufi, Carles
Subject: Re: [Zephyr-users] How to use TRACEDATA pins as GPIO - #nrf52832 #customboard
 
Thank you Vinayak.

For now, I will change the HAL file to solve that. When you have news about it please let me know.

Best regards,
Rodrigo Peixoto
On Mon, 3 Sep 2018 at 05:04 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Hi Rodrigo,


Glad to hear your success with first custom board made to run Zephyr.


You are right, the ENABLE_TRACE in the Nordic external MDK is not a Kconfig option in Zephyr.


This will need a new MDK release to be integrated. I will inform our team regarding this.


Regards,

Vinayak



From: users@... <users@...> on behalf of Rodrigo Peixoto <rodrigopex@...>
Sent: Sunday, September 2, 2018 4:54:59 PM
To: users@...
Subject: [Zephyr-users] How to use TRACEDATA pins as GPIO - #nrf52832 #customboard
 
Hi,
I have developed a custom board based on the nrf52832. Everything is running properly and I am glad to have my first board made to run Zephyr on it.

The only issue I am facing right now is that we have used some pins that are shared with TRACEDATA and I could not see any straightforward way of disabling it on Zephyr. Is there any? I have already disabled the CONFIG_SEGGER_SYSTEMVIEW config on my board files but it is still being used as TRACEDATA and not as GPIO. I have found the ext/hal/nordic/nrfx/mdk/system_nrf52.c file that has information related to that and says if we define ENABLE_TRACE the pins will be attached to TRACEDATA. I could not find any point where the ENABLE_TRACE is being defined. I could change the cited file in HAL directly, but I think it is not a sustainable solution.

Any clue on that?

Thank you very much.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

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


--
Rodrigo Peixoto
Co-founder and Technical guru

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

.


Re: How to use TRACEDATA pins as GPIO - #nrf52832 #customboard

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

Hi Rodrigo,


Glad to hear your success with first custom board made to run Zephyr.


You are right, the ENABLE_TRACE in the Nordic external MDK is not a Kconfig option in Zephyr.


This will need a new MDK release to be integrated. I will inform our team regarding this.


Regards,

Vinayak



From: users@... <users@...> on behalf of Rodrigo Peixoto <rodrigopex@...>
Sent: Sunday, September 2, 2018 4:54:59 PM
To: users@...
Subject: [Zephyr-users] How to use TRACEDATA pins as GPIO - #nrf52832 #customboard
 
Hi,
I have developed a custom board based on the nrf52832. Everything is running properly and I am glad to have my first board made to run Zephyr on it.

The only issue I am facing right now is that we have used some pins that are shared with TRACEDATA and I could not see any straightforward way of disabling it on Zephyr. Is there any? I have already disabled the CONFIG_SEGGER_SYSTEMVIEW config on my board files but it is still being used as TRACEDATA and not as GPIO. I have found the ext/hal/nordic/nrfx/mdk/system_nrf52.c file that has information related to that and says if we define ENABLE_TRACE the pins will be attached to TRACEDATA. I could not find any point where the ENABLE_TRACE is being defined. I could change the cited file in HAL directly, but I think it is not a sustainable solution.

Any clue on that?

Thank you very much.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

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



Re: SPI slave support for nRF52-PCA10040 #nrf52-pca10040 #spi

Carles Cufi
 

I am not an expert on SPI, but shouldn’t you enable this:

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/spi/Kconfig#L25

 

In your .conf:

CONFIG_SPI_SLAVE=y

 

From: users@... <users@...> On Behalf Of moritzgerlich@...
Sent: 03 September 2018 14:50
To: users@...
Subject: [Zephyr-users] SPI slave support for nRF52-PCA10040 #nRF52-PCA10040 #SPI

 

Hello at all,

i am trying to configure a nrf52-PCA10040 board to act as Slave for SPI but i am running into an issue.

When i try to setup the spi device as slave as shown at the end of the post, the spi device is Not set up as a spi slave in drivers/spi/spi_nrfx_spis.c but as master in drivers/spi/spi_nrfx_spi.c

Does someone know, how to correctly set up the spi device as a slave for the nrf-boards?

Thank you very much!

Config file:

CONFIG_SPI_NRFX=y
CONFIG_NRFX_SPIS=y
CONFIG_SPI=y
CONFIG_SPI_1_OP_MODES=2
CONFIG_SPI_1=y
CONFIG_SPI_1_IRQ_PRI=1
CONFIG_SPI_1_NRF_SPIS=y
CONFIG_SPI_1_NRF_SCK_PIN=29
CONFIG_SPI_1_NRF_MOSI_PIN=31
CONFIG_SPI_1_NRF_MISO_PIN=30


/home/stefan/Desktop/Screenshot at 2018-09-03 14:32:39.png


SPI slave support for nRF52-PCA10040 #nrf52-pca10040 #spi

moritzgerlich@...
 

Hello at all,

i am trying to configure a nrf52-PCA10040 board to act as Slave for SPI but i am running into an issue.

When i try to setup the spi device as slave as shown at the end of the post, the spi device is Not set up as a spi slave in drivers/spi/spi_nrfx_spis.c but as master in drivers/spi/spi_nrfx_spi.c

Does someone know, how to correctly set up the spi device as a slave for the nrf-boards?

Thank you very much!

Config file:

CONFIG_SPI_NRFX=y
CONFIG_NRFX_SPIS=y
CONFIG_SPI=y
CONFIG_SPI_1_OP_MODES=2
CONFIG_SPI_1=y
CONFIG_SPI_1_IRQ_PRI=1
CONFIG_SPI_1_NRF_SPIS=y
CONFIG_SPI_1_NRF_SCK_PIN=29
CONFIG_SPI_1_NRF_MOSI_PIN=31
CONFIG_SPI_1_NRF_MISO_PIN=30


/home/stefan/Desktop/Screenshot at 2018-09-03 14:32:39.png


Re: How to use TRACEDATA pins as GPIO - #nrf52832 #customboard

Rodrigo Peixoto
 

Thank you Vinayak.

For now, I will change the HAL file to solve that. When you have news about it please let me know.

Best regards,
Rodrigo Peixoto

On Mon, 3 Sep 2018 at 05:04 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Hi Rodrigo,


Glad to hear your success with first custom board made to run Zephyr.


You are right, the ENABLE_TRACE in the Nordic external MDK is not a Kconfig option in Zephyr.


This will need a new MDK release to be integrated. I will inform our team regarding this.


Regards,

Vinayak



From: users@... <users@...> on behalf of Rodrigo Peixoto <rodrigopex@...>
Sent: Sunday, September 2, 2018 4:54:59 PM
To: users@...
Subject: [Zephyr-users] How to use TRACEDATA pins as GPIO - #nrf52832 #customboard
 
Hi,
I have developed a custom board based on the nrf52832. Everything is running properly and I am glad to have my first board made to run Zephyr on it.

The only issue I am facing right now is that we have used some pins that are shared with TRACEDATA and I could not see any straightforward way of disabling it on Zephyr. Is there any? I have already disabled the CONFIG_SEGGER_SYSTEMVIEW config on my board files but it is still being used as TRACEDATA and not as GPIO. I have found the ext/hal/nordic/nrfx/mdk/system_nrf52.c file that has information related to that and says if we define ENABLE_TRACE the pins will be attached to TRACEDATA. I could not find any point where the ENABLE_TRACE is being defined. I could change the cited file in HAL directly, but I think it is not a sustainable solution.

Any clue on that?

Thank you very much.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

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


--
Rodrigo Peixoto
Co-founder and Technical guru

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

.


How to setup a spi flash? #spi #flash #sst26

Stefan Jaritz
 

Hey,

I am playing a bit around with Zephyr and a custom board. This board is based on a stm32f4 arm and connects a Mircochip Flash(SST26) via spi1. I like to figure out how to setup this spi flash?

Because of lack of knowledge I took a my old Yocto dts file from an other project as template. When doing a own device tree in Linux it looks like:

"""

 spi1: spi@f8008000 {
        cs-gpios = <&pioC 25 GPIO_ACTIVE_HIGH>;
        status = "okay";

        m25p80@0 {
            compatible = "spansion,s25fl164k";
            spi-max-frequency = <50000000>;
            reg = <0>;
        };
    };

"""

Now try something similar in Zephyr OS!

As far as I got:

1.) add in pinmux.c the pin function setup

"""

static const struct pin_config pinconf[] = {

...

// SPI 1 for Flash
#ifdef CONFIG_SPI_STM32
    // MEM CS(SS)
    {STM32_PIN_PA4, STM32F4_PINMUX_FUNC_PA4_SPI1_NSS},
    // MEM CLK
    {STM32_PIN_PA5, STM32F4_PINMUX_FUNC_PA5_SPI1_SCK},
    // MEM MISO
    {STM32_PIN_PA6, STM32F4_PINMUX_FUNC_PA6_SPI1_MISO},
    // MEM MOSI
    {STM32_PIN_PA7, STM32F4_PINMUX_FUNC_PA7_SPI1_MOSI},
#endif
"""

2.) activate spi1 in myboard.dts

"""

/dts-v1/;
#include <st/stm32f412.dtsi>

/ {
    model = "myboard";
    compatible = "test,myboard", "st,stm32f412";

    chosen {
        zephyr,console = &usart1;
        zephyr,sram = &sram0;
        zephyr,flash = &flash0;
    };

    soc {
        pinctrl: pin-controller@40020000 {
            usart1_pins_d: usart1@3 {
                rx_tx {
                    rx = <STM32_PIN_PA10 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
                    tx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
                };
            };
        };
    };
};

// test uart
&usart1 {
    current-speed = <115200>;
    pinctrl-0 = <&usart1_pins_d>;
    pinctrl-names = "default";
    status = "ok";
};

// activate spi1 to access the SST26 flash
&spi1 {
    status = "ok";
};
"""

3.) now try to connect the spi with the flash.
3.1) How is the syntax for that?
3.2) Is there a generic driver for that? (like the m25p80 in Linux)
3.2.1) how to write an own driver if there is no driver?

Greetings from UK!

Stefan


How to use TRACEDATA pins as GPIO - #nrf52832 #customboard

Rodrigo Peixoto
 

Hi,
I have developed a custom board based on the nrf52832. Everything is running properly and I am glad to have my first board made to run Zephyr on it.

The only issue I am facing right now is that we have used some pins that are shared with TRACEDATA and I could not see any straightforward way of disabling it on Zephyr. Is there any? I have already disabled the CONFIG_SEGGER_SYSTEMVIEW config on my board files but it is still being used as TRACEDATA and not as GPIO. I have found the ext/hal/nordic/nrfx/mdk/system_nrf52.c file that has information related to that and says if we define ENABLE_TRACE the pins will be attached to TRACEDATA. I could not find any point where the ENABLE_TRACE is being defined. I could change the cited file in HAL directly, but I think it is not a sustainable solution.

Any clue on that?

Thank you very much.
Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

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



Zephyr Development News, 28 August 2018

Marti Bolivar <marti@...>
 

Hello,

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

HTML is available here:

https://foundries.io/insights/2018/08/28/zephyr-news-20180828/

We're experimenting with using Pandoc to help generate the plain text
email version that follows; please bear with us in case of formatting issues.


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:

- f5026a11 ("samples/mesh: Fix dev_uuid initialization from identity
address"), merged 16 August 2018
- 00bb7136 ("release: bump version to 1.13-rc1"), merged 22 August 2018

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

v1.13 Release Candidate 1:

With v1.13.0-rc1 tagged and bagged, the merge window is closed. Only
pull requests which fix bugs or add documentation will be merged until
the next window opens (with the usual exceptions for pull requests
deemed special enough to bend the rules).


Tracing Framework:

Zephyr has long supported tool-specific means for tracing execution,
particularly support for Segger's (proprietary, and popular) tools. It
now includes an initial tool-agnostic trace framework.

Official documentation is a bit thin, but the relevant header
(<include/tracing.h>) is essentially a shim layer which allows
implementing additional tracing mechanisms. These will receive the same
trace notifications that Zephyr's Segger SystemView integration
supports. This replaces the old "event logger" mechanism as well as
other SoC-specific tracing code (so long, CONFIG_SOC_WATCH) in a unified
framework.

Support can be enabled via CONFIG_TRACING and enabling a backend (or,
cutting to the chase, by setting CONFIG_SEGGER_SYSTEMVIEW=y, which is
the only backend and selects CONFIG_TRACING). Here is an example of the
dining philosophers sample run under SystemView, showing the types of
events that are generated and associated metadata:

https://foundries.io/uploads/2018/08/28/segger_systemview_zephyr.png

Some of the edges are still a bit rough (the tracing API is not set in
stone, and details like thread IDs shown in the timeline view are not
especially human-readable), but it seems that with the addition of this
framework, generic and improving support for tracing is arriving in
Zephyr.


(Semi-)Automated Benchmarking:

Zephyr now supports gathering data for a variety of benchmarking
results, including for userspace operations. Support for benchmarking
implies a footprint and execution time penalty, so it must be enabled
with CONFIG_EXECUTION_BENCHMARKING. Test suites exercising this are part
of Zephyr's CI, and can also be run locally using sanitycheck.

Here are results and steps to reproduce a userspace-enabled benchmark
test suite on the frdm_k64f board:

https://gist.github.com/mbolivar/ff6db89181bde285f52ab32d5393f4e0

(Note that some userspace-specific issues are still being ironed out
on nRF devices; see issue 9676.) Unfortunately, the generated result
files are in (various different) custom text file formats, rather than
something like CSV or JSON. Thus, some extra parsing has to be done to
process the results.

To run benchmarks on a QEMU x86 Zephyr target (Linux hosts only), use
these instead:

# Run timing benchmarks:
$ sanitycheck -N -p qemu_x86 --test
tests/benchmarks/timing_info/benchmark.timing.userspace

# Run all tests with the "benchmark" tag:
$ sanitycheck -N -p qemu_x86 -t benchmark

As in the "real hardware" case, QEMU results are printed out in various
handler.log files in per-test sanity-out subdirectories.


Nordic GPIO/GPIOTE Changes:

The GPIO driver (drivers/gpio/gpio_nrfx.c) for Nordic nRF SoCs was
reimplemented as a shim over the nrfx vendor HAL, replacing the old
driver (drivers/gpio/gpio_nrf5.c).

Device tree GPIO nodes for nRF51 devices were added, affecting board
device trees.

These changes implied renaming of various GPIO-related Kconfig options.

Out of tree boards will need updates.


Power Management Improvements:

Zephyr has had power management support for quite some time
(http://docs.zephyrproject.org/subsystems/power_management.html), but
up until now, it has essentially been entirely up to the application
to manage power states in response to events. This is in contrast to
other operating systems, where the kernel can automatically initiate
device and SoC power state changes, often as a result of updating data
it's already using to track system state.

Needless to say, "do it yourself, have fun" tends to be less turnkey
than "the OS handles it for you", so it's a welcome sight to see the
initial merge of an "OS-managed" extension to Zephyr's power management
subsystem, which can be enabled by setting CONFIG_PM_CONTROL_OS=y.

Like much else in Zephyr, support is currently limited to nRF devices.
There also appear to be a few hard-coded data structures in the initial
commit limiting the available peripherals and supported functionality.
However, we're excited to see this new addition.

Features
--------

Arches:

The intel_s1000 target now initializes resource ownership for DMA and
I2S, as well as power gating and clock configuration, at SoC init time.

The Arm MPU driver framework was refactored and extended to add support
for v8-M SoCs.

Various internals were refactored for generic tracing support across
architectures.


Bluetooth:

The controller implementation (CONFIG_BT_CTLR) is now included by
default when CONFIG_BT is selected.

Zephyr's PHY update handler more gracefully manages protocol violations
observed with some cell phones available on the market.


Boards:

Support for the nRF-based board to be used at an upcoming Zephyr
hackathon was added as the reel_board configuration.

Support was added for the i.MX7 Solo WaRP7 board (as warp7_m4), with the
initial commit including GPIO, UART, and I2C support.

The intel_s1000_crb board now supports the TLV320DAC audio codec in its
device tree.

STM32L4 boards now support the RTC peripheral in their DTs.

nRF51 boards were refactored for DT-based GPIO support.


Device Tree:

Bindings were added for STM32 real time clocks (RTCs) in
dts/bindings/rtc/st,stm32-rtc.yaml.

The first audio codec binding (for the TI TLV320DAC) was added in
dts/bindings/audio/ti,tlv320dac.yaml.


Documentation:

The Kconfig documentation now makes it clearer which symbols are
selected by an option, and under what conditions. Here is an example for
CONFIG_SEGGER_SYSTEMVIEW:

http://docs.zephyrproject.org/reference/kconfig/CONFIG_SEGGER_SYSTEMVIEW.html#symbols-selected-by-this-symbol


Drivers:

New external device drivers/APIs:

- Analog devices ADXL372 3-axis accelerometer
- Avago APDS9960 digital proximity, ambient light, RGB and gesture
sensor
- TI TLV320DAC310x audio DAC (this is the first audio driver, which
has spawned a drivers/audio directory)
- TI HDC1008 temperature and humidity sensor
- A new driver API for digital microphone controllers was added as
include/audio/dmic.h.

STM32 devices now include support for the RTC peripheral; it was tested
on STM32L4.

The SiFive GPIO driver's IRQ bindings now respect the configured number
of pins.

i.MX devices can now retrieve frequency information for all UARTs.


Kernel:

Various internals were refactored for generic tracing support described
above.


Networking:

Various areas within the networking stack were refactored to avoid
allocating unnecessary struct k_delayed_work instances, resulting in
memory savings mostly affecting IPv6.


Samples:

- samples/sensor/adxl372, for the new ADXL372 accelerometer driver
- samples/subsys/power, for the new power management framework


Testing:

Additional test description and requirements traceability matrix
metadata were merged, along with improved test coverage in various
cases.


Bug Fixes
---------

Arches:

Some undefined signed integer shift operation behavior was corrected in
Arm's MPU framework.

On ARC, CONFIG_STACK_CHECK now works in secure mode as well, along with
other fixes related to thread initialization.

The SiLabs efr32fg1p SoC clock initialization code no longer attempts to
enable external oscillators which are already on.

The native_posix pseudo-architecture saw some segfault fixes in shell
argument handling, and a trace log message fix related to process
killing.


Bluetooth:

Mesh PB-GATT advertising data is initialized on demand, rather than at
initialization time, as the data it depends on may have changed since
initialization. Some PTS-related fixes were also merged.


Build:

A limitation on the number of kernel-space libraries to link into the
final binary has been removed.


Continuous Integration:

The check-compliance.py script no longer crashes when checking Kconfig
symbols for external projects.

sanitycheck internals related to job management were fixed and cleaned
up.

The Shippable configuration now fails when sanitycheck exits with an
error code, which it now does when Python exceptions are raised.


Drivers:

i.MX7 platforms now support GPIO7 and UART6.

Pinmux completions and bug fixes were merged affecting a variety of
STM32 families.

The i.MX I2C driver waits for the bus to be released before starting a
transaction.


External:

Kconfiglib was updated to a new version, fixing an issue related to
parsing the top-level Kconfig file.


Kernel:

The implementations of the k_{enable,disable}_sys_clock_always_on()
macros were fixed.

Various bitwise operations now correctly use unsigned integers. This is
an example of an emerging pattern of using the Coccinelle tool used in
the Linux kernel to perform automatic refactoring of Zephyr code; the
relevant script is scripts/coccinelle/unsigned_shift.cocci.

Thread-specific data is reserved at the top of the stack when
CONFIG_THREAD_USERSPACE_LOCAL_DATA is enabled. The first use case is
errno storage; use of errno from userspace now relies on this option.
This can be extended using the new struct _thread_userspace_local_data.


Libraries:

A couple of bug fixes for the recently merged CMSIS RTOS v1 support were
merged, affecting message and mail queues.


Miscellaneous:

Incorrect combinations of signed integers with irq_lock() were fixed,
also using a Cocinelle script, scripts/coccinelle/irq_lock.cocci.


Networking:

Renewed IPv6 addresses are now available for reuse. IPv6 addresses
related to a removed network prefix are now also removed.

The newly-merged LLDP support saw a timeout-related fix.

A bug causing spurious transmission of TCP retries was fixed.


Samples:

The samples/drivers/watchdog application was updated to use the new
watchdog API.


Testing:

Various issues identified by Coverity were fixed.

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

Patches by area (149 patches total):

- Arches: 23
- Bluetooth: 5
- Boards: 6
- Build: 4
- Continuous Integration: 8
- Device Tree: 6
- Documentation: 1
- Drivers: 25
- External: 1
- Kernel: 9
- Libraries: 2
- Miscellaneous: 5
- Networking: 16
- Power Management: 1
- Samples: 10
- Scripts: 1
- Testing: 26

Arches (23):

- 21e63ed2 arch: arm: kconfig: Remove redundant FLOAT dependencies
- 824bcaca xtensa: intel_s1000: Add SoC level SYS_INIT
- c8ea3653 arch: arm: type definition for arm mpu attribute container
- ff919d5f arch: arm: adapt region_init(.) to use arm_mpu_region_attr structure
- 829781d5 arch: arm: refactor _get_region_attr_by_type() function
- 5a696480 arch: arm: refactor _get_region_attr_by_conf(.) function
- 2f0e7221 arch: arm: mpu: move ARMv7m-specific functions in internal header
- 2a1fe6e2 arch: arm: implement ARMv8-M MPU driver
- b9566905 arch: arm: mpu: explicitly add UL in numerical shift operations
- 6ee0ad29 arch: arm: add ASSERT in _get_region_attr_by_type
- db0c5ca0 arch: arc: Added benchmark related hooks.
- e861661c native_posix: argparsing: Fix possible segfault
- 3ac2dc92 native_posix: Minor fix in message printed on kill
- 671cb652 arch/mcimx7_m4: Add pad, clock and gate config for GPIO7 and UART6
- d1219f4e arch/mcimx7_m4: Add i.MX7 Solo Kconfig SoC partnumber define
- f3d28933 arch: arc: stack check will be disabled in exception
- d68c0167 arch: arc: enable stack check when arc is in secure mode
- a1504c3c arch: arc: set the right init status for user space
- fa9fb831 arch: arc: re-orgnize the code in _new_thread
- eab5ff72 arch: arc: put the init context into privileged stack
- 506f21b6 arch: arc: small optimization in mpu driver
- 1301cc63 arch: arm: nordic_nrf: Add an API to check for valid PM state
- f6919977 soc: efr32fg1p: correct clock initialization sequence

Bluetooth (5):

- bb576f61 Bluetooth: Mesh: Move Device UUID log to bt_mesh_prov_enable()
- c0371277 Bluetooth: Mesh: Initialize PB-GATT advertising data at the
right time
- bf023d62 Bluetooth: Mesh: Fix heartbeat subscription state handling
- 8b3fd696 Bluetooth: controller: Fix assert on different transaction collision
- 871859a0 Bluetooth: GATT: Make CCC cfg_changed optional

Boards (6):

- 78a9daaa boards/arm: Enable RTC on STM32L4 boards
- 15813d34 boards: nrf: Changed GPIO default driver to NRFX shim
- bff5f470 boards: add basis support for the reel board
- 950c3466 boards: reel_board: Remove old reference to GPIO_NRF5
- 3c2a56bd boards: intel_s1000: audio codec in device tree
- c17fcf53 boards: Add support for WaRP7 board

Build (4):

- 964f6dc6 linker: Minor refactor of the APP_SMEM_SECTION macro
- cbe7b4fb linker: Re-implement {APP,KERNEL}_INPUT_SECTION
- 9e18b4f0 kconfig: BT: Default to using BT_CTLR when BT
- f2acdffe genrest: List symbols selected by each symbol

Continuous Integration (8):

- b4bdd669 sanitycheck: exit on exceptions
- 27b9e2ef ci: Handle errors and exit on them
- 94acc18b coverage: tests: poll: Add test to validate multiple polling threads
- 4fe581cc check-compliance: Fix undef. Kconfig symbol check for
external projects
- 42822083 sanitycheck: Get ZEPHYR_BASE only once
- c97054c1 sanitycheck: Fix the logic for jobs
- 99aacd98 sanitycheck: Rename CPU_COUNTS to JOBS
- f3bc967e sanitycheck: Overcommit the default number of jobs

Device Tree (6):

- 945ef745 dts/rtc: Introduce binding for STM32 RTC
- e99e363c dts: nrf: Added DTS support for nRF51
- 4f6aac1a dts: nrf5: Changed GPIO and GPIOTE define names
- 03da2f5c dts: audio: device tree support for audio devices
- 41d5a942 include: dt-bindings: pinctrl: stm32-pinctrlf1.h complete
stm32f1 header
- a25c273f dts: Fix cmake warning about missing id field for fsl,imx7d-i2c

Documentation (1):

- 469bd39b doc: add tracing section

Drivers (25):

- 0d47ae4f drivers: rtc: add support for STM32 RTC
- 6d8220d2 drivers: gpio: Add shim for nrfx GPIO and GPIOTE drivers
- d25c887f drivers: nrf: Remove redundant gpio_nrf5 shim
- acc5312b drivers: hdc1008: do not use hardcoded I2C address
- 6c9eb734 drivers: hdc1008: add dt bindings
- 7a507d3e drivers: apds9960: add dt bindings
- ca12b3f7 drivers: gpio: SiFive GPIO allows <32 pins
- 73c10932 drivers: audio: Add audio support in Kconfig
- d9a283d9 drivers: audio: TLV320DAC310x audio DAC driver
- 1864ba55 drivers: audio: add audio to cmake system
- bc332d76 drivers: dmic: APIs for digital microphones
- dc88fa6a drivers: i2s_cavs: Remove resource owner config
- e9c0f7e4 drivers: dma_cavs: Remove resource owner config
- 502d9189 drivers: pinmux: stm32: complete stm32f2 header
- 0ad9b3f8 drivers: pinmux: stm32: complete stm32f0 header
- 30045e4f drivers: pinmux: stm32: complete stm32f3 header
- 3fdf984a drivers: pinmux: stm32: complete stm32f4 header
- 4b9388f4 drivers: pinmux: stm32: complete stm32f7 header
- cc4f992b drivers: pinmux: stm32: complete stm32l0 header
- 425aca24 drivers: pinmux: stm32: complete stm32l4x header
- 96784dff include: console: Include kernel.h for struct k_fifo
- 2d269bb1 drivers: pwm_nrf5_sw: Perform static initialization only once
- 4eee8a67 drivers/i2c/i2c_imx: Check for I2C bus busy before starting
transaction
- 22b61c7f sensors: add WaRP7 board listing for fxos8700 and fxas21002
- a3e7cea1 drivers: sensors: adxl372: Add driver for ADXL372 high-g
accelerometer

External (1):

- 636d5451 ext/hal/nxp/imx: Add all UARTs clock frequency information

Kernel (9):

- f23a8cdd kernel: Fix k_*_sys_clock_always_on macro
- ec462f87 kernel: Remove unused definition
- 8aec0872 kernel: Fix bitwise operators with unsigned operators
- cc74ad08 kernel: Explicitly ignoring results of queue_insert
- 6699423a kernel: Explicitly ignoring memcpy return
- fc182430 kernel: userspace: reserve stack space to store local data
- a8b0b0d5 benchmarks: timing_info: Add hooks in the kernel for userspace.
- b6304e66 tracing: support generic tracing hooks
- a2248782 kernel: event_logger: remove kernel_event_logger

Libraries (2):

- 5c79101f constants: Use uppercase to indicate long
- 411662d3 lib: cmsis_rtos_v1: fix couple of nonconformities

Miscellaneous (5):

- 0866d18d irq: Fix irq_lock api usage
- 2626dda0 assert: Explicitly ignoring printk() return
- 030a65c4 util: Add WRITE_BIT macro to util.h
- 483910ab systemview: add support natively using tracing hooks
- 00bb7136 release: bump version to 1.13-rc1

Networking (16):

- 1a7e365f net: ip: Remove unused function
- 37837f5b net: ip: Add net_sprint_addr()
- 9d7711f0 net: ip: Redirect net_sprint_ipv*_addr() invocations
- 99dc5aef net: ip: Refactor usage of net_sprint_ip*()
- eeabc2ba net: if: Lower ram usage for IP address lifetime handling
- d529aef9 net: tls: Apply DTLS review fixes
- e3002751 net: ipv6: Centralize IPv6 send NS timeout through one k_delayed_work
- 51aa291f net: ipv6: Centralize ND reachable timeout through one k_delayed_work
- 58f3e183 net: ipv6: Separate IPv6 Neighbor functionality
- 8ddb3ba3 net: ipv6: Separate IPv6 MLD functionality
- 7aff94dc net: ipv6: Separate IPv6 fragment functionality
- 3bfc1385 net: if: Mark IPv6 address as preferred if lifetime is renewed
- 57a41a23 net: if: Remove IPv6 auto addresses if the prefix is removed
- a5f7e334 net: lldp: Fix timeout triggering if multiple workers
- 52126598 net: tcp: fix spurious TCP retries
- 49732b27 net: Move CONFIG_NET_OFFLOAD definition to net/ip/

Power Management (1):

- 2ad64785 subsys: power: Add OS managed Power Management framework

Samples (10):

- f5026a11 samples/mesh: Fix dev_uuid initialization from identity address
- 5d9e8189 samples: hello_world: remove single thread variant
- 1f19078e samples: apds9960: whitelist arduino_101_sss
- c9c8bbf2 samples: apds9960: whitelist reel board
- bd01344a samples/net/lldp/Kconfig: Get rid of leftover 'option env'
- 6c669ace samples: watchdog: Update watchdog example to new API
- 3f02e0d5 samples: remove kernel_event_logger sample
- 457fc799 samples: debug: remove sysview sample
- 84c352d0 samples: sensor: adxl372: Add ADXL372 sample application
- b69d2861 samples: subsys: Add sample app to demo OS managed PM

Scripts (1):

- a56be6f5 Kconfiglib: Fix $srctree behavior for the top-level Kconfig file

Testing (26):

- 9956dfc7 tests: update test identifier
- 57db4151 tests: remove subsys from test identifier
- 1c721217 tests: smp: Additional tests to verify SMP functionality
- ba6763a1 tests: disable HDC1008 from build tests
- fe1797f6 tests: net: ethernet_mgmt: Don't recalculate deltaBW with no link
- aaaf20e6 tests: net: ptp: Check max number of interfaces
- db2cbe7e tests: net: iface: Initialize port number
- 47889cd1 tests: fatal: Add description and RTM links
- b468b24d tests: gpio: Added nRF board to gpio test
- d36aae15 tests: cmsis_rtos_v1: add negative tests for timer api
- f3e05666 tests: kernel: fp_sharing: Added support for Cortex-M7
- ce88792a tests: fp_sharing: use filter
- 8c456f75 tests: mempool: Enhance tests to improve code coverage
- c9e3c938 tests/samples: watchdog: Update projects' configuration
- 667ad040 tests: benchmarks: timing_info: Add userspace related KPIs.
- 022588e8 tests: benchmarks: timing_info: Enable benchmarks for ARC.
- 43af891a tests: include: Add implementation of timestamp_serialize()
- 30b569e8 tests: benchmarks: timing_info: Discard selected measurements.
- bb918d85 tests: benchmarks: timing_info: Enable benchmarks for xtensa.
- 79f65d4d tests: benchmarks: timing_info: Enable benchmarks for nios2.
- 1d27b404 tests: benchmarks: timing_info: Enable benchmarks for riscv32.
- a4d1e36a tests: benchmarks: timing_info: Cleanup testcase.yaml
- 2a72f500 tests: smp: Modify test to verify thread delay
- 9038416b tests: net: ipv6: Add tests for verifying DAD timers
- ac47070d tests: qmsi: remove soc watch sample
- aa81a922 tests: build philosophers sample with systemview


Re: NRF52 : use of NFFS file system

Carles Cufi
 

Hi Laurence,

 

I am copying a couple of people that might be able to help with NFFS config.

 

Carles

 

From: users@... <users@...> On Behalf Of Laurence Pasteau
Sent: 27 August 2018 10:06
To: users@...; devel@...
Subject: [Zephyr-users] NRF52 : use of NFFS file system

 

Hi everybody,

 

I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.

 

I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.

 

I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.

 

I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.

 

Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.

 

 

Here is my configuration (I don't use MCU_BOOT) :

 

In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };

 

In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: [Zephyr-devel] Enable SPI driver on nrf52840

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

https://youtu.be/vioi4OsmB_U

Hope the above video helps :-)

Summary: Kconfig options for one board may require new dependencies be met for another board.

- Vinayak

PS: added users mailing list, hope helps them too.

On 28 Aug 2018, at 04:07, cpmcparland@... wrote:

Vinayak,

Thanks.  I thought that the creation the driver source directories was only done at cmake time.... so that's where I was looking
for a problem.  Clearly I was wrong about that.  Did just what you suggested using the arduino_101 board as target (that seems
to be the example always used) and things worked as you desicribed.  However all is not well yet with the nrf pca10056, so I
have taken a page from your note and am trying again from a clean dist.

I just cloned rc13 and am attempting to build the i2c_fujitsu_fram sample program.  Sourced the appropriate
zephyr_end.sh script.  Created build/arduino_101 in the sample
directory and executed cmake -DBOARD=arduino_101 ../..    All went well.  Also issued make command and sample
compiled and linked without a problem.  NO changes to anything in the repo - just cmake and make.

Then created a clean build/nrf52840_pca10056 directory in the sample directory and executed cmake -DBOARD=nrf52840_pca10056.
NO changes to the repo - just create directories and executed cmake.  REceived the following output and error:

cmake -DBOARD=nrf52840_pca10056 ../..
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.3", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
Zephyr version: 1.13.0
Parsing Kconfig tree in /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/Kconfig
Using /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/samples/drivers/i2c_fujitsu_fram/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
-- Cache files will be written to: /home/mcp/.cache/zephyr
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__i2c' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.


-- Configuring incomplete, errors occurred!

Any comments would be welcome.  Also, thanks for posting the menuconfig issue...am following that
closely.

Regards,
Chuck


Re: PTP over BLE

Jukka Rissanen
 

Hi David,

I have not heard anyone trying to use PTP over BLE. Patches are welcome
of course if there are good use cases for this. Is there a spec that
specifies how to run PTP over BLE?


Cheers,
Jukka

On Mon, 2018-08-27 at 16:12 +0200, via Lists.Zephyrproject.Org wrote:
Hi,

I saw that Precision Time Protocol was just added, great!

Has anyone been looking at a "generic" way to achieve a distributed
precision clock over BLE?

In my use-case it would be ok to limit it to the nordics, similar to
what could be done with the time-slot API (using BLE for
data/commands) and raw radio for sync.. But perhaps there are smarter
ways to achieve the same.


best David


PTP over BLE

david <david@...>
 

Hi,

I saw that Precision Time Protocol was just added, great!

Has anyone been looking at a "generic" way to achieve a distributed precision clock over BLE?

In my use-case it would be ok to limit it to the nordics, similar to what could be done with the time-slot API (using BLE for data/commands) and raw radio for sync.. But perhaps there are smarter ways to achieve the same.


best David


NRF52 : use of NFFS file system

Laurence Pasteau
 

Hi everybody,


I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.


I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.


I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.


I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.


Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.



Here is my configuration (I don't use MCU_BOOT) :


In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };


In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y


In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)


Thanks in advance for any help.


Regards,

Laurence






Re: [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

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

Why don’t you use tests/bluetooth/mesh_shell ? and add your commands?

Johan may be of assistance.

On 24 Aug 2018, at 13:08, Vikrant More <vikrant8051@...> wrote:

Hi Vinayak,
My sim is to create commands & send it to PDK where PDK process them & help onboard #BluetoothMesh clients to create data packets.

Currently using thread triggered by button interrupt to send Bluetooth Mesh Client mesaages like
Gen_OnOff_Set/ Gen_OnOff_Set_Unack/Gen_Level_Set/Gen_Level_Set_Unack

Thank You !!

On Fri, Aug 24, 2018 at 4:32 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!





Re: [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

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

if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!




Re: [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

vikrant8051 <vikrant8051@...>
 

Hi Vinayak,
My sim is to create commands & send it to PDK where PDK process them & help onboard #BluetoothMesh clients to create data packets.

Currently using thread triggered by button interrupt to send Bluetooth Mesh Client mesaages like
Gen_OnOff_Set/ Gen_OnOff_Set_Unack/Gen_Level_Set/Gen_Level_Set_Unack

Thank You !!

On Fri, Aug 24, 2018 at 4:32 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!



1641 - 1660 of 2707