Date   

Re: [Zephyr-users] RPI 3 bluez recipe

Vikrant More <vikrant8051@...>
 

follow my steps on mailing list.

I also faced same problem initially.

Plz re-initiate the entire process as follow

2) rename it to bluez

3) cd bluez

4)./bootstrap-configure

5)make install

6)make

7)systemctl daemon-reload
8) systemctl restart bluetooth 
9) cd $bluez/mesh

10) now run meshctl command here


On Tue, Feb 6, 2018 at 12:43 PM, Hongjian Fan <fan@...> wrote:

Hi Vikrant,


Thanks. Yes I've seen your replies on the mailing list. Here's what I did on a newly setup RPi3


sudo apt-get update
sudo apt-get install -y libusb-dev libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev autotools-dev automake libtool elfutils libjson-c-dev git tree


./bootstrap
./configure --enable-mesh
make
sudo make install

# Raspbian was /usr/sbin/bluetoothd -> ../lib/bluetooth/bluetoothd
sudo rm /usr/sbin/bluetoothd
sudo ln -s /usr/local/libexec/bluetooth/bluetoothd /usr/sbin/bluetoothd

sudo systemctl daemon-reload
sudo systemctl restart bluetooth

pi@pi:~/bluez/mesh$ sudo ./meshctl
Local config directory not provided.
# netkeys = 1
Waiting to connect to bluetoothd...Failed to parse provisioning database file prov_db.json


Did you recompile kernel with crypto module? Or something else obvious? 




From: Vikrant More <vikrant8051@...>
Sent: Tuesday, February 6, 2018 2:58 PM
To: Hongjian Fan
Subject: Re: [Zephyr-users] RPI 3 bluez recipe
 
cd $bluez/mesh

Here you will find prov_db.json & local_node.json

Copy those in $(your_bluez)/mesh location & retry.



On Tue, Feb 6, 2018 at 12:16 PM, Hongjian Fan <fan@...> wrote:
Hi

Trying meshctl from latest bluez git checkout with latest raspbian on RPI 3,  Failed to parse provide.json. Wondered how you successfully run on it. Can please share detailed instructions?

Thanks!


_______________________________________________
Zephyr-users mailing list
Zephyr-users@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users




Re: Zephyr porting for Cortex R8

Carles Cufi
 

Hi Vladimir,

 

We’ve changed the way Kconfig is handled and now it should no longer prompt for new options at all, it should simply assign them empty.

This was done on the 3rd of January, so about a month ago:

https://github.com/zephyrproject-rtos/zephyr/commit/d92769b849a96c71fb425ea9c945ff8aa2c3aca2#diff-3a17f68c7317a0565fa6d10ecdd67c05

 

I am surprised that you get prompted for options, can you make sure you have the commit above?

 

That said the issue stands, although it is slightly different.

 

From: Vladimir Podbrezsky [mailto:vladp@...]
Sent: 05 February 2018 08:24
To: Cufi, Carles <Carles.Cufi@...>; zephyr-devel@...
Subject: RE: [Zephyr-devel] Zephyr porting for Cortex R8

 

Hi Carles,

 

Thank you for your prompt response.

Actually , I remove build folder and run cmake each time. I run the following commands

clear && rm -fr * && cmake -DBOARD=fabrico ../.. && make.

 

I cloned from master branch repository two weeks ago and zephyr version is 1.10.0.

 

Thanks,

     Vladimir.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Sunday, February 4, 2018 8:07 PM
To: Vladimir Podbrezsky <vladp@...>; zephyr-devel@...
Subject: [EXT] Re: [Zephyr-devel] Zephyr porting for Cortex R8

 

External Email


Hi Vladimir,

 

Try a fully clean build first. Remove your build  folder completey and run cmake on an empty folder.

 

Also, are you basing your changes on the latest master? If you don’t then you should.

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of Vladimir Podbrezsky <vladp@marvell.com>
Date: Sunday, 4 February 2018 at 18:15
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Zephyr porting for Cortex R8

 

Hello,

 

I try to port Zephyr RTOS for running on Cortex R8 processor and our privet board.

I created all needed files described in following links

http://docs.zephyrproject.org/porting/arch.html and http://docs.zephyrproject.org/porting/board_porting.html

 

But currently I have the following errors while trying to build “Hello world” application.

 

Q1:How to understand what is the problem?

Q2:How to debug this and the same issues?

 

Regards,

    Vlad.

 

 

vladp@fabrico-host1:~/work/zephyr/zephyr/samples/hello_world/build/fabrico$ cmake -DBOARD=fabrico ../..

 

CMake Deprecation Warning at /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:47 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4")

-- Selected BOARD fabrico

Zephyr version: 1.10.0

Using /home/vladp/work/zephyr/zephyr/boards/arm/fabrico/fabrico_defconfig as base

Merging /home/vladp/work/zephyr/zephyr/samples/hello_world/prj.conf

Merging /home/vladp/work/zephyr/zephyr/tests/include/test.config

#

# configuration written to /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config

#

-- Generating zephyr/include/generated/autoconf.h

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:123:warning: symbol value '' invalid for OSC_XTAL0_FREQ

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:134:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC

*

* Restart config...

*

*

* Board Configuration

*

Enable MPU (ARM_MPU_ENABLE) [N/y/?] n

Enable MPU on nRF52 (ARM_MPU_NRF52X) [N/y/?] n

Kinetis K6x MCU Selection

> 1. SOC_MK64F12 (SOC_MK64F12)

choice[1]: 1

Freescale K64 core clock divider (K64_CORE_CLOCK_DIVIDER) [1] 1

Freescale K64 bus clock divider (K64_BUS_CLOCK_DIVIDER) [2] 2

Freescale K64 FlexBus clock divider (K64_FLEXBUS_CLOCK_DIVIDER) [3] 3

Freescale K64 flash clock divider (K64_FLASH_CLOCK_DIVIDER) [5] 5

Enable MPU (HAS_SYSMPU) [N/y/?] n

Oscillator Mode Selection

> 1. External reference clock (OSC_EXTERNAL)

  2. Low power oscillator (OSC_LOW_POWER)

  3. High gain oscillator (OSC_HIGH_GAIN)

choice[1-3]: 1

External oscillator frequency (OSC_XTAL0_FREQ) [] (NEW) aborted!

 

Console input/output is redirected. Run 'make oldconfig' to update configuration.

 

-- Generating zephyr/include/generated/generated_dts_board.h

cc1: fatal error: /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/include/generated/autoconf.h: No such file or directory

compilation terminated.

CMake Error at /home/vladp/work/zephyr/zephyr/dts/dts.cmake:69 (message):

 command failed with return code: 1

Call Stack (most recent call first):

  /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:207 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!


Re: Zephyr porting for Cortex R8

Sebastian Boe
 

Hi,

you are running into these two issues:

https://github.com/zephyrproject-rtos/zephyr/issues/5426
https://github.com/zephyrproject-rtos/zephyr/issues/1464

The important line is:

"External oscillator frequency (OSC_XTAL0_FREQ) [] (NEW) aborted!"

Until they are resolved you are going to have to modify Kconfig sources
or one of the Kconfig fragments to ensure OSC_XTAL0_FREQ is set
appropriately.

________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Vladimir Podbrezsky <vladp@marvell.com>
Sent: Monday, 5 February 2018 8:23:31 AM
To: Cufi, Carles; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr porting for Cortex R8

Hi Carles,

Thank you for your prompt response.
Actually , I remove build folder and run cmake each time. I run the following commands
clear && rm -fr * && cmake -DBOARD=fabrico ../.. && make.

I cloned from master branch repository two weeks ago and zephyr version is 1.10.0.

Thanks,
Vladimir.

From: Cufi, Carles [mailto:Carles.Cufi@nordicsemi.no]
Sent: Sunday, February 4, 2018 8:07 PM
To: Vladimir Podbrezsky <vladp@marvell.com>; zephyr-devel@lists.zephyrproject.org
Subject: [EXT] Re: [Zephyr-devel] Zephyr porting for Cortex R8

External Email
________________________________
Hi Vladimir,

Try a fully clean build first. Remove your build folder completey and run cmake on an empty folder.

Also, are you basing your changes on the latest master? If you don’t then you should.

Regards,

Carles

From: <zephyr-devel-bounces@lists.zephyrproject.org<mailto:zephyr-devel-bounces@lists.zephyrproject.org>> on behalf of Vladimir Podbrezsky <vladp@marvell.com<mailto:vladp@marvell.com>>
Date: Sunday, 4 February 2018 at 18:15
To: "zephyr-devel@lists.zephyrproject.org<mailto:zephyr-devel@lists.zephyrproject.org>" <zephyr-devel@lists.zephyrproject.org<mailto:zephyr-devel@lists.zephyrproject.org>>
Subject: [Zephyr-devel] Zephyr porting for Cortex R8

Hello,

I try to port Zephyr RTOS for running on Cortex R8 processor and our privet board.
I created all needed files described in following links
http://docs.zephyrproject.org/porting/arch.html and http://docs.zephyrproject.org/porting/board_porting.html

But currently I have the following errors while trying to build “Hello world” application.

Q1:How to understand what is the problem?
Q2:How to debug this and the same issues?

Regards,
Vlad.


vladp@fabrico-host1:~/work/zephyr/zephyr/samples/hello_world/build/fabrico$ cmake -DBOARD=fabrico ../..

CMake Deprecation Warning at /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:47 (cmake_policy):
The OLD behavior for policy CMP0000 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
CMakeLists.txt:3 (include)


-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4")
-- Selected BOARD fabrico
Zephyr version: 1.10.0
Using /home/vladp/work/zephyr/zephyr/boards/arm/fabrico/fabrico_defconfig as base
Merging /home/vladp/work/zephyr/zephyr/samples/hello_world/prj.conf
Merging /home/vladp/work/zephyr/zephyr/tests/include/test.config
#
# configuration written to /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config
#
-- Generating zephyr/include/generated/autoconf.h
/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:123:warning: symbol value '' invalid for OSC_XTAL0_FREQ
/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:134:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC
*
* Restart config...
*
*
* Board Configuration
*
Enable MPU (ARM_MPU_ENABLE) [N/y/?] n
Enable MPU on nRF52 (ARM_MPU_NRF52X) [N/y/?] n
Kinetis K6x MCU Selection
1. SOC_MK64F12 (SOC_MK64F12)
choice[1]: 1
Freescale K64 core clock divider (K64_CORE_CLOCK_DIVIDER) [1] 1
Freescale K64 bus clock divider (K64_BUS_CLOCK_DIVIDER) [2] 2
Freescale K64 FlexBus clock divider (K64_FLEXBUS_CLOCK_DIVIDER) [3] 3
Freescale K64 flash clock divider (K64_FLASH_CLOCK_DIVIDER) [5] 5
Enable MPU (HAS_SYSMPU) [N/y/?] n
Oscillator Mode Selection
1. External reference clock (OSC_EXTERNAL)
2. Low power oscillator (OSC_LOW_POWER)
3. High gain oscillator (OSC_HIGH_GAIN)
choice[1-3]: 1
External oscillator frequency (OSC_XTAL0_FREQ) [] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update configuration.

-- Generating zephyr/include/generated/generated_dts_board.h
cc1: fatal error: /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/include/generated/autoconf.h: No such file or directory
compilation terminated.
CMake Error at /home/vladp/work/zephyr/zephyr/dts/dts.cmake:69 (message):
command failed with return code: 1
Call Stack (most recent call first):
/home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:207 (include)
CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!


Re: Zephyr porting for Cortex R8

Vladimir Podbrezsky <vladp@...>
 

Hi Carles,

 

Thank you for your prompt response.

Actually , I remove build folder and run cmake each time. I run the following commands

clear && rm -fr * && cmake -DBOARD=fabrico ../.. && make.

 

I cloned from master branch repository two weeks ago and zephyr version is 1.10.0.

 

Thanks,

     Vladimir.

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Sunday, February 4, 2018 8:07 PM
To: Vladimir Podbrezsky <vladp@...>; zephyr-devel@...
Subject: [EXT] Re: [Zephyr-devel] Zephyr porting for Cortex R8

 

External Email


Hi Vladimir,

 

Try a fully clean build first. Remove your build  folder completey and run cmake on an empty folder.

 

Also, are you basing your changes on the latest master? If you don’t then you should.

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of Vladimir Podbrezsky <vladp@marvell.com>
Date: Sunday, 4 February 2018 at 18:15
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Zephyr porting for Cortex R8

 

Hello,

 

I try to port Zephyr RTOS for running on Cortex R8 processor and our privet board.

I created all needed files described in following links

http://docs.zephyrproject.org/porting/arch.html and http://docs.zephyrproject.org/porting/board_porting.html

 

But currently I have the following errors while trying to build “Hello world” application.

 

Q1:How to understand what is the problem?

Q2:How to debug this and the same issues?

 

Regards,

    Vlad.

 

 

vladp@fabrico-host1:~/work/zephyr/zephyr/samples/hello_world/build/fabrico$ cmake -DBOARD=fabrico ../..

 

CMake Deprecation Warning at /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:47 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4")

-- Selected BOARD fabrico

Zephyr version: 1.10.0

Using /home/vladp/work/zephyr/zephyr/boards/arm/fabrico/fabrico_defconfig as base

Merging /home/vladp/work/zephyr/zephyr/samples/hello_world/prj.conf

Merging /home/vladp/work/zephyr/zephyr/tests/include/test.config

#

# configuration written to /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config

#

-- Generating zephyr/include/generated/autoconf.h

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:123:warning: symbol value '' invalid for OSC_XTAL0_FREQ

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:134:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC

*

* Restart config...

*

*

* Board Configuration

*

Enable MPU (ARM_MPU_ENABLE) [N/y/?] n

Enable MPU on nRF52 (ARM_MPU_NRF52X) [N/y/?] n

Kinetis K6x MCU Selection

> 1. SOC_MK64F12 (SOC_MK64F12)

choice[1]: 1

Freescale K64 core clock divider (K64_CORE_CLOCK_DIVIDER) [1] 1

Freescale K64 bus clock divider (K64_BUS_CLOCK_DIVIDER) [2] 2

Freescale K64 FlexBus clock divider (K64_FLEXBUS_CLOCK_DIVIDER) [3] 3

Freescale K64 flash clock divider (K64_FLASH_CLOCK_DIVIDER) [5] 5

Enable MPU (HAS_SYSMPU) [N/y/?] n

Oscillator Mode Selection

> 1. External reference clock (OSC_EXTERNAL)

  2. Low power oscillator (OSC_LOW_POWER)

  3. High gain oscillator (OSC_HIGH_GAIN)

choice[1-3]: 1

External oscillator frequency (OSC_XTAL0_FREQ) [] (NEW) aborted!

 

Console input/output is redirected. Run 'make oldconfig' to update configuration.

 

-- Generating zephyr/include/generated/generated_dts_board.h

cc1: fatal error: /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/include/generated/autoconf.h: No such file or directory

compilation terminated.

CMake Error at /home/vladp/work/zephyr/zephyr/dts/dts.cmake:69 (message):

 command failed with return code: 1

Call Stack (most recent call first):

  /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:207 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!


Re: Zephyr porting for Cortex R8

Carles Cufi
 

Hi Vladimir,

 

Try a fully clean build first. Remove your build  folder completey and run cmake on an empty folder.

 

Also, are you basing your changes on the latest master? If you don’t then you should.

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of Vladimir Podbrezsky <vladp@marvell.com>
Date: Sunday, 4 February 2018 at 18:15
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] Zephyr porting for Cortex R8

 

Hello,

 

I try to port Zephyr RTOS for running on Cortex R8 processor and our privet board.

I created all needed files described in following links

http://docs.zephyrproject.org/porting/arch.html and http://docs.zephyrproject.org/porting/board_porting.html

 

But currently I have the following errors while trying to build “Hello world” application.

 

Q1:How to understand what is the problem?

Q2:How to debug this and the same issues?

 

Regards,

    Vlad.

 

 

vladp@fabrico-host1:~/work/zephyr/zephyr/samples/hello_world/build/fabrico$ cmake -DBOARD=fabrico ../..

 

CMake Deprecation Warning at /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:47 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4")

-- Selected BOARD fabrico

Zephyr version: 1.10.0

Using /home/vladp/work/zephyr/zephyr/boards/arm/fabrico/fabrico_defconfig as base

Merging /home/vladp/work/zephyr/zephyr/samples/hello_world/prj.conf

Merging /home/vladp/work/zephyr/zephyr/tests/include/test.config

#

# configuration written to /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config

#

-- Generating zephyr/include/generated/autoconf.h

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:123:warning: symbol value '' invalid for OSC_XTAL0_FREQ

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:134:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC

*

* Restart config...

*

*

* Board Configuration

*

Enable MPU (ARM_MPU_ENABLE) [N/y/?] n

Enable MPU on nRF52 (ARM_MPU_NRF52X) [N/y/?] n

Kinetis K6x MCU Selection

> 1. SOC_MK64F12 (SOC_MK64F12)

choice[1]: 1

Freescale K64 core clock divider (K64_CORE_CLOCK_DIVIDER) [1] 1

Freescale K64 bus clock divider (K64_BUS_CLOCK_DIVIDER) [2] 2

Freescale K64 FlexBus clock divider (K64_FLEXBUS_CLOCK_DIVIDER) [3] 3

Freescale K64 flash clock divider (K64_FLASH_CLOCK_DIVIDER) [5] 5

Enable MPU (HAS_SYSMPU) [N/y/?] n

Oscillator Mode Selection

> 1. External reference clock (OSC_EXTERNAL)

  2. Low power oscillator (OSC_LOW_POWER)

  3. High gain oscillator (OSC_HIGH_GAIN)

choice[1-3]: 1

External oscillator frequency (OSC_XTAL0_FREQ) [] (NEW) aborted!

 

Console input/output is redirected. Run 'make oldconfig' to update configuration.

 

-- Generating zephyr/include/generated/generated_dts_board.h

cc1: fatal error: /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/include/generated/autoconf.h: No such file or directory

compilation terminated.

CMake Error at /home/vladp/work/zephyr/zephyr/dts/dts.cmake:69 (message):

 command failed with return code: 1

Call Stack (most recent call first):

  /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:207 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!


Zephyr porting for Cortex R8

Vladimir Podbrezsky <vladp@...>
 

Hello,

 

I try to port Zephyr RTOS for running on Cortex R8 processor and our privet board.

I created all needed files described in following links

http://docs.zephyrproject.org/porting/arch.html and http://docs.zephyrproject.org/porting/board_porting.html

 

But currently I have the following errors while trying to build “Hello world” application.

 

Q1:How to understand what is the problem?

Q2:How to debug this and the same issues?

 

Regards,

    Vlad.

 

 

vladp@fabrico-host1:~/work/zephyr/zephyr/samples/hello_world/build/fabrico$ cmake -DBOARD=fabrico ../..

 

CMake Deprecation Warning at /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:47 (cmake_policy):

  The OLD behavior for policy CMP0000 will be removed from a future version

  of CMake.

 

  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.

Call Stack (most recent call first):

  CMakeLists.txt:3 (include)

 

 

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.3", minimum required is "3.4")

-- Selected BOARD fabrico

Zephyr version: 1.10.0

Using /home/vladp/work/zephyr/zephyr/boards/arm/fabrico/fabrico_defconfig as base

Merging /home/vladp/work/zephyr/zephyr/samples/hello_world/prj.conf

Merging /home/vladp/work/zephyr/zephyr/tests/include/test.config

#

# configuration written to /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config

#

-- Generating zephyr/include/generated/autoconf.h

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:123:warning: symbol value '' invalid for OSC_XTAL0_FREQ

/home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/.config:134:warning: symbol value '' invalid for SYS_CLOCK_HW_CYCLES_PER_SEC

*

* Restart config...

*

*

* Board Configuration

*

Enable MPU (ARM_MPU_ENABLE) [N/y/?] n

Enable MPU on nRF52 (ARM_MPU_NRF52X) [N/y/?] n

Kinetis K6x MCU Selection

> 1. SOC_MK64F12 (SOC_MK64F12)

choice[1]: 1

Freescale K64 core clock divider (K64_CORE_CLOCK_DIVIDER) [1] 1

Freescale K64 bus clock divider (K64_BUS_CLOCK_DIVIDER) [2] 2

Freescale K64 FlexBus clock divider (K64_FLEXBUS_CLOCK_DIVIDER) [3] 3

Freescale K64 flash clock divider (K64_FLASH_CLOCK_DIVIDER) [5] 5

Enable MPU (HAS_SYSMPU) [N/y/?] n

Oscillator Mode Selection

> 1. External reference clock (OSC_EXTERNAL)

  2. Low power oscillator (OSC_LOW_POWER)

  3. High gain oscillator (OSC_HIGH_GAIN)

choice[1-3]: 1

External oscillator frequency (OSC_XTAL0_FREQ) [] (NEW) aborted!

 

Console input/output is redirected. Run 'make oldconfig' to update configuration.

 

-- Generating zephyr/include/generated/generated_dts_board.h

cc1: fatal error: /home/vladp/work/zephyr/zephyr/samples/hello_world/build/fabrico/zephyr/include/generated/autoconf.h: No such file or directory

compilation terminated.

CMake Error at /home/vladp/work/zephyr/zephyr/dts/dts.cmake:69 (message):

 command failed with return code: 1

Call Stack (most recent call first):

  /home/vladp/work/zephyr/zephyr/cmake/app/boilerplate.cmake:207 (include)

  CMakeLists.txt:3 (include)

 

 

-- Configuring incomplete, errors occurred!


(No subject)

AMIT GARG <amit.garg@...>
 


"can i built bluetooth mesh network with esp32 if i use zephyr os into it"


Re: Bluetooth Mesh: Bad values for continuous scan

Chettimada, Vinayak Kariappa
 

Every event has a 1.5ms preparation/idling, hence you are right 1.5ms of 10ms or 15% missed adv reports.

The reason for 10ms was to reduce the radio idling when advertising event would overlap in time with scan window,
in such cases scan will only resume every 10ms.
Imagine if using a scan interval and window of 2 seconds, and it where to be skipped due to a advertising event of mere 3 ms.
I am working on a newer architecture that would increase radio utilisation significantly, but its going to take sometime until I finish porting everything.

That said, there is an advanced Kconfig option CONFIG_BT_CTLR_XTAL_THRESHOLD
you can increase this to above 10 ms so that the 1.5ms idling reduces dynamically down, reducing the miss percentage down.

Also, there is a controller bug, which I will fix soon. If the scan window is more than twice the advertising interval, the controller asserts.

-Vinayak

On 1 Feb 2018, at 18:15, Johan Hedberg <johan.hedberg@...> wrote:

Hi Paul,

On Thu, Feb 01, 2018, Gavrikov Paul wrote:
the default MESH_SCAN_INTERVAL and MESH_SCAN_WINDOW
(/subsys/bluetooth/host/mesh/adv.c) are both set to 0x10, thus
enabling a continuous scan which switches the channel every 10ms.
However as you may know, most radios can't switch channels immediately
and thus cause a delay period in which no advertisement can be
detected. (see e.g.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5375785/).
I did some experiments with a Nordic Semicon nRF52-PCA100400 and saw
that with the default Zephyr values I miss 15% of all advertisements
in an almost inactive radio environment.  Increasing
MESH_SCAN_INTERVAL to 0x100 (i.e. 160ms) results in 1.5%, 0x4000 (the
max)  <0.5% miss rate. (Measurement: Sending 5x 1000 advertisements
with 20ms interval).

Thus I'd propose increasing these values or exposing them to config.

Thanks for analyzing this. I picked 0x10 after consulting with the
Nordic Semiconductor engineers who are behind Zephyr's controller
implementation. I'll let them comment before doing the change.

Johan
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Error in Doc for CONFIG_BT_MESH_LPN_POLL_TIMEOUT

Johan Hedberg
 

Hi Paul,

On Thu, Feb 01, 2018, Johan Hedberg wrote:
On Thu, Feb 01, 2018, Gavrikov Paul wrote:
http://docs.zephyrproject.org/reference/kconfig/CONFIG_BT_MESH_LPN_POLL_TIMEOUT.html

"[...] The value is in units of 100 milliseconds, so e.g. a value of
300 means 3 seconds." is wrong. 300 * 100ms = 30 seconds
Thanks for reporting, but please always check with the latest master
branch first - this is actually already fixed there. That said, I just
noticed that the same error is still in the description for the
BT_MESH_LPN_INIT_POLL_TIMEOUT variable (which I presume it mostly a
copy-paste from the BT_MESH_LPN_POLL_TIMEOUT description).
Sorry, I got that the wrong way around. The INIT one was already fixed
but the one you reported was not. Anyway, I've pushed a pull request to
fix this:

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

Johan


Re: Error in Doc for CONFIG_BT_MESH_LPN_POLL_TIMEOUT

Johan Hedberg
 

Hi Paul,

On Thu, Feb 01, 2018, Gavrikov Paul wrote:
http://docs.zephyrproject.org/reference/kconfig/CONFIG_BT_MESH_LPN_POLL_TIMEOUT.html

"[...] The value is in units of 100 milliseconds, so e.g. a value of
300 means 3 seconds." is wrong. 300 * 100ms = 30 seconds
Thanks for reporting, but please always check with the latest master
branch first - this is actually already fixed there. That said, I just
noticed that the same error is still in the description for the
BT_MESH_LPN_INIT_POLL_TIMEOUT variable (which I presume it mostly a
copy-paste from the BT_MESH_LPN_POLL_TIMEOUT description).

Johan


Re: Bluetooth Mesh: Bad values for continuous scan

Johan Hedberg
 

Hi Paul,

On Thu, Feb 01, 2018, Gavrikov Paul wrote:
the default MESH_SCAN_INTERVAL and MESH_SCAN_WINDOW
(/subsys/bluetooth/host/mesh/adv.c) are both set to 0x10, thus
enabling a continuous scan which switches the channel every 10ms.
However as you may know, most radios can't switch channels immediately
and thus cause a delay period in which no advertisement can be
detected. (see e.g.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5375785/).
I did some experiments with a Nordic Semicon nRF52-PCA100400 and saw
that with the default Zephyr values I miss 15% of all advertisements
in an almost inactive radio environment. Increasing
MESH_SCAN_INTERVAL to 0x100 (i.e. 160ms) results in 1.5%, 0x4000 (the
max) <0.5% miss rate. (Measurement: Sending 5x 1000 advertisements
with 20ms interval).

Thus I'd propose increasing these values or exposing them to config.
Thanks for analyzing this. I picked 0x10 after consulting with the
Nordic Semiconductor engineers who are behind Zephyr's controller
implementation. I'll let them comment before doing the change.

Johan


Re: undefined reference to `bt_uuid_str'

Gavrikov Paul <Paul.Gavrikov@...>
 

Hi Johan,

it appears to be working with the latest commits. It was a custom app.

Best
Paul

-----Ursprüngliche Nachricht-----
Von: Johan Hedberg [mailto:johan.hedberg@intel.com]
Gesendet: Montag, 29. Januar 2018 22:19
An: Gavrikov Paul <Paul.Gavrikov@newtec.de>
Cc: zephyr-devel@lists.zephyrproject.org
Betreff: Re: [Zephyr-devel] undefined reference to `bt_uuid_str'

Hi Paul,

On Mon, Jan 29, 2018, Gavrikov Paul wrote:
builing a mesh app with debug logs for provisioning fails, due to a
missing ref. HEAD is at dbba22397c439ff4675de61407635ae4b5e5ac38

Log:

subsys/bluetooth/host/mesh/libsubsys__bluetooth__host__mesh.a(prov.c.obj): In function `bt_mesh_prov_init':
C:/Users/pgavrikov/Desktop/zephyr/subsys/bluetooth/host/mesh/prov.c:1568: undefined reference to `bt_uuid_str'
collect2.exe: error: ld returned 1 exit status %
make[3]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:106:
zephyr/zephyr_prebuilt.elf] Fehler 1
make[2]: *** [CMakeFiles/Makefile2:600:
zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:2119:
zephyr/cmake/flash/CMakeFiles/flash.dir/rule] Fehler 2
make: *** [Makefile:430: flash] Fehler 2
I'm unable to reproduce this. Is this your own app and a custom configuration, or a sample from the Zephyr tree? If it's your custom app, could you provide the output of the following:

grep CONFIG_BT_ <build dir>/zephyr/.config

Johan


Bluetooth Mesh: Bad values for continuous scan

Gavrikov Paul <Paul.Gavrikov@...>
 

Hello,

 

the default MESH_SCAN_INTERVAL and MESH_SCAN_WINDOW (/subsys/bluetooth/host/mesh/adv.c) are both set to 0x10, thus enabling a continuous scan which switches the channel every 10ms. However as you may know, most radios can’t switch channels immediately and thus cause a delay period in which no advertisement can be detected. (see e.g. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5375785/).

I did some experiments with a Nordic Semicon nRF52-PCA100400 and saw that with the default Zephyr values I miss 15% of all advertisements in an almost inactive radio environment.

Increasing MESH_SCAN_INTERVAL to 0x100 (i.e. 160ms) results in 1.5%, 0x4000 (the max)  <0.5% miss rate. (Measurement: Sending 5x 1000 advertisements with 20ms interval).

 

Thus I’d propose increasing these values or exposing them to config.

 

Best,

Paul Gavrikov

 

eMail: Paul.Gavrikov@...

web:  www.newtec.de

 

NewTec GmbH

Heinrich-von-Stephan-Straße 8

D-79100 Freiburg

Geschäftsführer: Johannes Werbach, Harald Molle, Ulrich Schwer, Michael Tröscher Registergericht Memmingen - HRB 7236 USt.-IdNr. DE130850199

 


Error in Doc for CONFIG_BT_MESH_LPN_POLL_TIMEOUT

Gavrikov Paul <Paul.Gavrikov@...>
 

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

 

„[…] The value is in units of 100 milliseconds, so e.g. a value of 300 means 3 seconds.“ is wrong. 300 * 100ms = 30 seconds

 

Best

Paul Gavrikov

 

eMail: Paul.Gavrikov@...

web:  www.newtec.de

 

NewTec GmbH

Heinrich-von-Stephan-Straße 8

D-79100 Freiburg

Geschäftsführer: Johannes Werbach, Harald Molle, Ulrich Schwer, Michael Tröscher Registergericht Memmingen - HRB 7236 USt.-IdNr. DE130850199

 


Re: FW: support for NFFS file system

Vikrant More <vikrant8051@...>
 

Hello World !!

What to do so that every fs_write( ) will save data on next new line ?
Similarly what to do so that every fs_read() will read data from next new line ?

Thank You !!

On Wed, Jan 31, 2018 at 3:17 PM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Vikrant,

 

Yes, we would like the sample to be merged, but you need to send a Pull Request using GitHub.

Please read through the Contribution Guidelines: http://docs.zephyrproject.org/contribute/contribute_guidelines.html.

 

Feel free to ask questions about those here or on IRC (#zephyrproject on freenode.net)

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Vikrant More <vikrant8051@...>
Date: Wednesday, 31 January 2018 at 06:04
To: "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no>
Cc: "zephyr-users@lists.zephyrproject.org" <zephyr-users@lists.zephyrproject.org>, "zephyr-devel@lists.zephyrproject.org" <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

 

On Tue, Jan 30, 2018 at 8:07 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@nordicsemi.no> wrote:

> I request Zephyr OS maintainer to create & add following attached main.c under $zephyr_base/samples/boards/nrf52/nffs/src

& prj.conf under $zephyr_base/samples/boards/nrf52/nffs/ on Github.

 

Great, so I’m waiting for a PR with this.

 

Andrzej

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Monday, January 29, 2018 7:49 AM
To: Michael Hope <
michaelh@...>; zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org


Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

Thanks Michael !!

Now I can access flash of nRF52840 using NFFS file system APIs.

 

I request Zephyr OS maintainer to create & add following attached main.c under $zephyr_base/samples/boards/nrf52/nffs/src

& prj.conf under $zephyr_base/samples/boards/nrf52/nffs/ on Github.

Thank You !!

 

On Fri, Jan 26, 2018 at 1:43 AM, Michael Hope <michaelh@...> wrote:

You can look up the error numbers to see what they mean in:

 

 

-19 is ENODEV which suggests you have a flash driver configuration problem.

 

I put together a little sample at https://github.com/nzmichaelh/zephyr_mini_samples  I tested it on an Arduino Zero, not a NRF5 board, so you will need to update prj.conf but I hope it helps.

 

-- Michael

 

On Thu, 25 Jan 2018 at 05:37 Vikrant More <vikrant8051@...> wrote:

fs_open( ) returns -19 instead of 0.

 

On Thu, Jan 25, 2018 at 12:10 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  I'm pretty sure you're reading past the end of the file - you'll need to close and reopen it before you can read back what you just wrote.  Try something like:

 

fs_open(...)

fs_write(...)

fs_close(...)

 

fs_open(...)

fs_read(...)

 

I also recommend checking the return value when you're experimenting.  In this case, you'll find that fs_read() is returning zero, i.e. it read zero bytes which is a good clue as to why there's no data in the buffer.

 

-- Michael

 

On Wed, 24 Jan 2018 at 13:29 Vikrant More <vikrant8051@...> wrote:

Hi Vinayak, it works !!

I make following changes .....

    fs_file_t my_zfp;
    unsigned char ptr[32];

    for(cntr=0;cntr<=31;cntr++)
    {
        ptr[cntr]='@';
    }

    fs_open(&my_zfp,"mesh.prv");
    fs_write(&my_zfp,"0123456789ABCDEF",16);
    fs_read(&my_zfp,ptr,32);
    fs_close(&my_zfp);

    for(cntr=0;cntr<=31;cntr++)
    {
        printk("%c",ptr[cntr]);
    }

 

But it prints --> @@@@@@@@@@@@@@@@

instead of --> 0123456789ABCDEF

Any clue ??

Thanks !!

 

On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <
michaelh@...>
Cc:
zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

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

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

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

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To:
zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 

 

 

On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <
michaelh@...>
Cc:
zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

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

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

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

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@nordicsemi.no> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To:
zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 

 

 

 

 



Re: USB: Question about usb_write() API

Sundar Subramaniyan
 

Hi Loic,

On Wed, Jan 31, 2018 at 4:13 PM, Loic Poulain <loic.poulain@...> wrote:

Today there is no transfer concept at usb device driver level, you
only read/write the TX/RX hardware FIFO (usb_dw), this is up to each
class driver to manage packet splitting and transfer start/end,
including short/zero packet management.
This also means that class drivers need to know the endpoint FIFO size
to delineate packets and transfers. This is significant extra work for
each class driver and not really agnostic.

I agree with you on this one. In the long term, packet fragmentation and blocking (if required)
should be taken care at a higher level.

This is why I would like to introduce transfer concept, letting the
device drivers deal with transfer management.
The interface could be something like: usb_transfer(endpoint, buffer,
buffer_len, callback, flags)
The implementation is hardware specific but usb controller usually
have registers to program transfer size, packet count and IRQ to
indicate transfer completion, FIFO empty...
This is a simplified version of Linux USB Request Block (URB).

This is a good thing and much needed one.
I'll need to look at your implementation to understand how it's done on the driver side.
But why do we need a new driver API to do this?

Thanks,
Sundar
 


On 31 January 2018 at 09:28, andrei.emeltchenko@...
<andrei.emeltchenko.news@gmail.com> wrote:
> Hi,
>
> On Wed, Jan 31, 2018 at 08:09:12AM +0530, Sundar Subramaniyan wrote:
>>    Hi Paul,
>>    On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky
>>    <[1]paul.sokolovsky@...> wrote:
>>
>>
>>        A good clarification thus would be:
>>
>>        1. bytes_ret is always not-NULL.
>>        2. There can always be short writes, number of bytes written is
>>        returned in *bytes_ret, caller must retry with remaining data as
>>        needed.
>>
>>        Note that this doesn't call for updates to existing drivers - they can
>>        keep accepting bytes_ret as NULL, and loop/block inside. But clients
>>        of this API definitely need to be updated, because otherwise they
>>        simply won't work with some drivers.
>>
>>    I think the same too. For now, new drivers should handle both the methods
>>    to be coherent with the API definition. If ret_bytes is NULL, then it
>>    shall to
>>    a blocked write taking care of fragmentation of the packet internally
>>    within
>>    the driver. Otherwise if it is != NULL, it can let the upper layer do the
>>    fragmentation
>>    and shall *not* block-wait for the completion of the current write on the
>>    USB bus,
>>    since we have write callback for notification purpose.
>
> I think we do not have now this requirement not to block-wait. When
> working with sending fragmented packets you would prefer to block until all
> fragments are sent.
>
> Best regards
> Andrei Emeltchenko
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@lists.zephyrproject.org
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: USB: Question about usb_write() API

Sundar Subramaniyan
 

Hi Andrei,

On Wed, Jan 31, 2018 at 1:58 PM, andrei.emeltchenko@... <andrei.emeltchenko.news@...> wrote:
I think we do not have now this requirement not to block-wait. When
working with sending fragmented packets you would prefer to block until all
fragments are sent.
 
If block wait is mandated, we can call usb_write() only on one endpoint at a time which will hamper performance.
Although USB bus transactions are sequential we can however queue the write buffers to a fifo and process them
later from a work queue independently after previous completion which might help design the driver in a better way.

w.r.t callbacks, well there are two cases:

Application has:
1. set a valid callback function
2. set callback as NULL

If the callback is NULL then does that implicitly mean we have to block till write is complete?
I would prefer the driver implementation be simple rather complicating with all the synchronization and fragmentation stuff.

Thanks,
Sundar


Re: USB: Question about usb_write() API

Loic Poulain
 

Hi,

As defined by the documentation, write is asynchronous, you can only
be sure write is complete when usb_ep_callback is called.
In practice, there are some hacks in current drivers to make write
block if previous one is not completed (active polling on FIFO for the
dw driver, semaphore for stm32 one).

Today there is no transfer concept at usb device driver level, you
only read/write the TX/RX hardware FIFO (usb_dw), this is up to each
class driver to manage packet splitting and transfer start/end,
including short/zero packet management.
This also means that class drivers need to know the endpoint FIFO size
to delineate packets and transfers. This is significant extra work for
each class driver and not really agnostic.

This is why I would like to introduce transfer concept, letting the
device drivers deal with transfer management.
The interface could be something like: usb_transfer(endpoint, buffer,
buffer_len, callback, flags)
The implementation is hardware specific but usb controller usually
have registers to program transfer size, packet count and IRQ to
indicate transfer completion, FIFO empty...
This is a simplified version of Linux USB Request Block (URB).

Regards,
Loic


On 31 January 2018 at 09:28, andrei.emeltchenko@intel.com
<andrei.emeltchenko.news@gmail.com> wrote:
Hi,

On Wed, Jan 31, 2018 at 08:09:12AM +0530, Sundar Subramaniyan wrote:
Hi Paul,
On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky
<[1]paul.sokolovsky@linaro.org> wrote:


A good clarification thus would be:

1. bytes_ret is always not-NULL.
2. There can always be short writes, number of bytes written is
returned in *bytes_ret, caller must retry with remaining data as
needed.

Note that this doesn't call for updates to existing drivers - they can
keep accepting bytes_ret as NULL, and loop/block inside. But clients
of this API definitely need to be updated, because otherwise they
simply won't work with some drivers.

I think the same too. For now, new drivers should handle both the methods
to be coherent with the API definition. If ret_bytes is NULL, then it
shall to
a blocked write taking care of fragmentation of the packet internally
within
the driver. Otherwise if it is != NULL, it can let the upper layer do the
fragmentation
and shall *not* block-wait for the completion of the current write on the
USB bus,
since we have write callback for notification purpose.
I think we do not have now this requirement not to block-wait. When
working with sending fragmented packets you would prefer to block until all
fragments are sent.

Best regards
Andrei Emeltchenko
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: FW: support for NFFS file system

Carles Cufi
 

Hi Vikrant,

 

Yes, we would like the sample to be merged, but you need to send a Pull Request using GitHub.

Please read through the Contribution Guidelines: http://docs.zephyrproject.org/contribute/contribute_guidelines.html.

 

Feel free to ask questions about those here or on IRC (#zephyrproject on freenode.net)

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of Vikrant More <vikrant8051@...>
Date: Wednesday, 31 January 2018 at 06:04
To: "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@...>
Cc: "zephyr-users@..." <zephyr-users@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

 

On Tue, Jan 30, 2018 at 8:07 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

> I request Zephyr OS maintainer to create & add following attached main.c under $zephyr_base/samples/boards/nrf52/nffs/src

& prj.conf under $zephyr_base/samples/boards/nrf52/nffs/ on Github.

 

Great, so I’m waiting for a PR with this.

 

Andrzej

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Monday, January 29, 2018 7:49 AM
To: Michael Hope <
michaelh@...>; zephyr-users@...; zephyr-devel@...


Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

Thanks Michael !!

Now I can access flash of nRF52840 using NFFS file system APIs.

 

I request Zephyr OS maintainer to create & add following attached main.c under $zephyr_base/samples/boards/nrf52/nffs/src

& prj.conf under $zephyr_base/samples/boards/nrf52/nffs/ on Github.

Thank You !!

 

On Fri, Jan 26, 2018 at 1:43 AM, Michael Hope <michaelh@...> wrote:

You can look up the error numbers to see what they mean in:

 

 

-19 is ENODEV which suggests you have a flash driver configuration problem.

 

I put together a little sample at https://github.com/nzmichaelh/zephyr_mini_samples  I tested it on an Arduino Zero, not a NRF5 board, so you will need to update prj.conf but I hope it helps.

 

-- Michael

 

On Thu, 25 Jan 2018 at 05:37 Vikrant More <vikrant8051@...> wrote:

fs_open( ) returns -19 instead of 0.

 

On Thu, Jan 25, 2018 at 12:10 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  I'm pretty sure you're reading past the end of the file - you'll need to close and reopen it before you can read back what you just wrote.  Try something like:

 

fs_open(...)

fs_write(...)

fs_close(...)

 

fs_open(...)

fs_read(...)

 

I also recommend checking the return value when you're experimenting.  In this case, you'll find that fs_read() is returning zero, i.e. it read zero bytes which is a good clue as to why there's no data in the buffer.

 

-- Michael

 

On Wed, 24 Jan 2018 at 13:29 Vikrant More <vikrant8051@...> wrote:

Hi Vinayak, it works !!

I make following changes .....

    fs_file_t my_zfp;
    unsigned char ptr[32];

    for(cntr=0;cntr<=31;cntr++)
    {
        ptr[cntr]='@';
    }

    fs_open(&my_zfp,"mesh.prv");
    fs_write(&my_zfp,"0123456789ABCDEF",16);
    fs_read(&my_zfp,ptr,32);
    fs_close(&my_zfp);

    for(cntr=0;cntr<=31;cntr++)
    {
        printk("%c",ptr[cntr]);
    }

 

But it prints --> @@@@@@@@@@@@@@@@

instead of --> 0123456789ABCDEF

Any clue ??

Thanks !!

 

On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <
michaelh@...>
Cc:
zephyr-users@...; zephyr-devel@...
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

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

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

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

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@...> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To:
zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 

 

 

On Wed, Jan 24, 2018 at 5:41 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

Its:

 

fs_file_t my_zfp; // no * please;

 

and

 

fs_open(&my_zfp,"mesh.prv"); // & please J

 

That said, I am not expert on FS!

 

-Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Wednesday, January 24, 2018 1:06 PM
To: Michael Hope <
michaelh@...>
Cc:
zephyr-users@...; zephyr-devel@...
Subject: Re: [Zephyr-devel] FW: support for NFFS file system

 

I copied & pasted $zephyr/ext/fs/nffs directory into $zephyr_base/include
----------------------------------------------------------------------------------------------------------------------

& edit $zephyr_base/include/fs/nffs_fs.h as follow

/*
 * Copyright (c) 2017 Codecoup
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#ifndef _NFFS_FS_H_
#define _NFFS_FS_H_

#include <sys/types.h>
#include <nffs/include/nffs/nffs.h>

#ifdef __cplusplus
extern "C" {
#endif

FS_FILE_DEFINE(struct nffs_file *fp);
FS_DIR_DEFINE(struct nffs_dir *dp);

#define MAX_FILE_NAME 256

#ifdef __cplusplus
}
#endif

#endif /* _NFFS_FS_H_ */

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

& add following config into my prj.conf

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_SOC_FLASH_NRF5=y
CONFIG_SOC_FLASH_NRF5_DEV_NAME="NRF52_FLASH"
CONFIG_SOC_FLASH_NRF5_RADIO_SYNC=y
CONFIG_ZTEST_STACKSIZE=2048
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_HEAP_MEM_POOL_SIZE=1024


CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FILE_SYSTEM_NFFS=y
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12

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

& add following lines in main.c

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

After all this every thing gets compiled with warning :

 

warning: ‘my_zfp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  fs_open(my_zfp,"mesh.prv");

Could you please help me, how to initialized my_zfp here ?

 

 

On Tue, Jan 23, 2018 at 1:15 AM, Michael Hope <michaelh@...> wrote:

Hi Vikrant.  You also need to enable NFFS in your configuration - try 'make menuconfig' > File Systems > File system support = y; Supported file systems -> NFFS.

You can also check out the NFFS test case under tests/subsys/fs and especially the configuration in https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/subsys/fs/nffs_fs_api/nrf5x.conf

-- Michael

 

On Fri, 19 Jan 2018 at 11:46 Vikrant More <vikrant8051@...> wrote:

#include <fs.h>

void main( )
{
    fs_file_t *my_zfp;
    unsigned char ptr[32];


    fs_open(my_zfp,"mesh.prv");
    fs_write(my_zfp,"Hello World !! ",16);
    fs_read(my_zfp,ptr,32);
    fs_close(my_zfp);

    printk("%s",ptr);
}

I've edited main.c in my project as mentioned above.

And add CONFIG_FILE_SYSTEM_NFFS=y in prj.conf

 

1st time I got following error,

 

In file included from /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:3:0:
/home/vikrant/projects/zephyr/zephyr/include/fs.h:66:12: error: ‘MAX_FILE_NAME’ undeclared here (not in a function)
  char name[MAX_FILE_NAME + 1];
            ^~~~~~~~~~~~~
CMakeFiles/app.dir/build.make:302: recipe for target 'CMakeFiles/app.dir/src/main.c.obj' failed
make[2]: *** [CMakeFiles/app.dir/src/main.c.obj] Error 1
CMakeFiles/Makefile2:259: recipe for target 'CMakeFiles/app.dir/all' failed
make[1]: *** [CMakeFiles/app.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

To overcome it I added ,    #define MAX_FILE_NAME 10   in zephyr/include/fs.h

 

After this I got following error,

 

../libapp.a(main.c.obj): In function `main':
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:226: undefined reference to `fs_open'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:227: undefined reference to `fs_write'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:228: undefined reference to `fs_read'
/home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh/src/main.c:229: undefined reference to `fs_close'
collect2: error: ld returned 1 exit status
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:104: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:569: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

 

 

 

 

Following line are already present in zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts

 


#if defined(CONFIG_FILE_SYSTEM_NFFS)
        nffs_partition: partition@fc000 {
            label = "nffs";
            reg = <0x000fc000 0x00004000>;
        };
#endif

 

Could you please tell me what I'm missing ?

 

Thank You !!

 

On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:

 

1. Ensure the board has a nffs partition defined in Device Tree.  See here for an example.

2. Turn on CONFIG_FILE_SYSTEM_NFFS in the config

3. Use the APIs in include/fs.h such as fs_open() etc

If you turn on CONFIG_FILE_SYSTEM_SHELL then you'll also get a simple interactive shell where you can list directories etc.

-- Michael

 

On Thu, 18 Jan 2018 at 15:16 Vikrant More <vikrant8051@...> wrote:

Thanks for reply.

 

Where I will find APIs & sample codes based on it to access internal flash of nrf52840 ?

 

 

On Jan 18, 2018 3:38 PM, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@...> wrote:

NFFS Is supported since 1.10 release:

https://www.zephyrproject.org/releases/1-10-release-december-2017/

 

Andrzej

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Vikrant More
Sent: Thursday, January 18, 2018 10:09 AM
To:
zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] support for NFFS file system

 

Hello World !!

 

My question is related to this link's requirement,
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-July/007888.html

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?

Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

 

 

 

 

 


Re: USB: Question about usb_write() API

Andrei
 

Hi,

On Wed, Jan 31, 2018 at 08:09:12AM +0530, Sundar Subramaniyan wrote:
Hi Paul,
On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky
<[1]paul.sokolovsky@linaro.org> wrote:
 

A good clarification thus would be:

1. bytes_ret is always not-NULL.
2. There can always be short writes, number of bytes written is
returned in *bytes_ret, caller must retry with remaining data as
needed.

Note that this doesn't call for updates to existing drivers - they can
keep accepting bytes_ret as NULL, and loop/block inside. But clients
of this API definitely need to be updated, because otherwise they
simply won't work with some drivers.

I think the same too. For now, new drivers should handle both the methods
to be coherent with the API definition. If ret_bytes is NULL, then it
shall to
a blocked write taking care of fragmentation of the packet internally
within
the driver. Otherwise if it is != NULL, it can let the upper layer do the
fragmentation
and shall *not* block-wait for the completion of the current write on the
USB bus,
since we have write callback for notification purpose.
I think we do not have now this requirement not to block-wait. When
working with sending fragmented packets you would prefer to block until all
fragments are sent.

Best regards
Andrei Emeltchenko

3961 - 3980 of 8033