Date   

Re: FW: support for NFFS file system

Vikrant More <vikrant8051@...>
 

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@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 Johann,

On Tue, Jan 30, 2018 at 9:12 PM, Johann Fischer <johann_fischer@...> wrote:
Please use subsys/usb/class for testing and as reference.

The IN endpoint callback just informs that a endpoint buffer was transmitted to
the host.

I used the DW driver as a reference,
see https://github.com/zephyrproject-rtos/zephyr/pull/542
The Kinetis USB controller is a bit similar to NRF52, btw I would be glad
about review.

Thanks, will take a look at it.
 
There is an effort to implement the transfer method. This is very convenient
from the function point of view, but may complicate the drivers.
Please review https://github.com/zephyrproject-rtos/zephyr/pull/5231

Thanks, will look into this. I need to understand the transfer method. So after it's
been pulled, does the driver need to support it by default? Since there's no driver
registration using f_ops to the USB subsystem, there would be linking issues, no?
 
Regards,
Johann Fischer


Thanks,
Sundar


Re: USB: Question about usb_write() API

Sundar Subramaniyan
 

Hi Andrei,

On Tue, Jan 30, 2018 at 9:01 PM, andrei.emeltchenko@... <andrei.emeltchenko.news@...> wrote:
I think API states it supports both methods:
https://github.com/zephyrproject-rtos/zephyr/blob/master/include/usb/usb_device.h#L209

Yes, it does support both of them. So new drivers should support both of them to be inline with the API definition?
As Paul pointed out, some old drivers might need to be modified since some applications assume the drivers' fragmentation support.
 
Fragmentation to USB packets is done on a higher level, in function_ecm
and finction_rndis files.


Thanks for pointing this. I'll look how this is being used.
 
Please also look to usb_dc_ep_transfer() implemented for DW and STM32:

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

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

Will look into it. Thanks.
 
Best regards
Andrei Emeltchenko

Thanks,
Sundar


Re: USB: Question about usb_write() API

Sundar Subramaniyan
 

Hi Paul,

On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky <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.

Is this a fair understanding?

Thanks,
Sundar


Re: USB: Question about usb_write() API

Paul Sokolovsky
 

On Tue, 30 Jan 2018 14:36:40 +0000
"Cufi, Carles" <Carles.Cufi@nordicsemi.no> wrote:

[]

I'd suggest to look at this as a generic problem, not specific to
USB subsystem (e.g., there's the same issue in networking
subsystem, etc.), and consider the known best practices dealing
with it. For example, POSIX, when dealing with streams-of-bytes,
[]

Although you raise a good point, I'm not convinced that this applies
here. I think that what Sundar wants to know is whether this
particular API call, usb_write(), was originally designed to be able
to buffer data and fragment it into smaller USB-sized packets or
instead it should mirror the state of whatever hardware FIFO it is
using below, returning a number of bytes written different from the
ones the caller asked to send. Beyond that there's the issue of the
API call being blocking or not, which seems unclear given the
different ways it is used in Zephyr. To sum up, I thin he's trying to
clarify the original intentions of the API designer in order to adapt
the driver he's working on to it, not looking to modify the API
itself.
But clarification of the API is also what I'm talking about. Other
points are also collinear, for example, POSIX supports concept of short
reads/writes exactly to let drivers avoid blocking (or avoid extensive
resource usage in general).

usb_write() is described as:

* @brief write data to the specified endpoint
*
* Function to write data to the specified endpoint. The supplied
* usb_ep_callback will be called when transmission is done.
*
* @param[in] ep Endpoint address corresponding to the one listed in the
* device configuration table
* @param[in] data Pointer to data to write
* @param[in] data_len Length of data requested to write. This may be zero for
* a zero length status packet.
* @param[out] bytes_ret Bytes written to the EP FIFO. This value may be NULL if
* the application expects all bytes to be written

That's not explicit enough. The best reading I can get of it is that it
supports *both* of the scenarios above: a) if bytes_ret is non-NULL, it
may perform short write; b) if it's non-NULL, short write is not
allowed. But in all fairness, there's a bit of "reading between the
lines" in that. And such specification puts additional burden on a
driver: it must support both not-looping/not-blocking and
looping-blocking operation. Besides problems with testing these both
modes, we'd find that some drivers simply omit implementation of one or
another case (I see that in Zephyr all the time).

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.


Thanks,

Carles


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: USB: Question about usb_write() API

Johann Fischer
 

Hi,

Here's what bt_usb does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/bluetooth/hci_usb/src/main.c#L665

When I looked at other drivers to see how they are implemented, the
designware USB driver seems to assume
the application/class drivers always support the "write in parts" method.
I'm not blaming the driver or it's
implementation but I just wanted to point out that there are drivers which
do not support handling chunked
write within them.
This sample was written for the DW driver, there was no other device driver
recently.

Another class driver, netusb does it a little differently by writing in
parts, but this too assumes the usb_write()
to be synchronous.

Here's what it does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/netusb/netusb.c#L189
Please use subsys/usb/class for testing and as reference.

One more thing to consider is the write callbacks. In most cases, the
application/class driver is the one that registers
the Bulk/Interrupt endpoint callbacks and the device stack has no way of
knowing when to perform the next write, even
if it wants to handle this in the USB device stack.
The IN endpoint callback just informs that a endpoint buffer was transmitted to
the host.


My question now is, what is the ideal place to take care of truncation and
chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and synchronization?
I used the DW driver as a reference,
see https://github.com/zephyrproject-rtos/zephyr/pull/542
The Kinetis USB controller is a bit similar to NRF52, btw I would be glad
about review.

There is an effort to implement the transfer method. This is very convenient
from the function point of view, but may complicate the drivers.
Please review https://github.com/zephyrproject-rtos/zephyr/pull/5231

Regards,
Johann Fischer


Re: USB: Question about usb_write() API

Andrei
 

Hi,

On Tue, Jan 30, 2018 at 02:31:46PM +0000, Cufi, Carles wrote:
+ Andrei

 

Carles

 

From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Sundar
Subramaniyan
Sent: 30 January 2018 13:18
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] USB: Question about usb_write() API

 

Hi,

While developing a USB device controller driver for the Nordic nRF52840
SoC,
I ran into the problem of handling chunked/partial write() while coding
the usb_dc_ep_write() function.

From what I could gather, the usb_write() API documentation states that
the application calling
this function may choose to write all the data buffer at once even if it
is larger than the maximum
packet size supported by the USB endpoint to which we're writing to.
Let's call this method "write all at once".

If the application or the class driver can manage to write in parts, then
it must use the "bytes_ret" argument
to know how much data is written on the bus so as to know if there's
anymore data remaining to be written in
the subsequent call. Let's call this method "write in parts".
I think API states it supports both methods:
https://github.com/zephyrproject-rtos/zephyr/blob/master/include/usb/usb_device.h#L209


In my case, I'm using bt_usb and it tries to write all at once - i.e.
there's no handling of remaining data.
This mandates the USB device controller driver to take care of the writing
in parts within the driver itself.
While this can be done in a simple loop if the driver talks synchronously
to the USBD HW and do a poll and
a yield or use a semaphore till the HW completes the DMA and there's room
to write more.

Here's what bt_usb does:
[1]https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/bluetooth/hci_usb/src/main.c#L665

When I looked at other drivers to see how they are implemented, the
designware USB driver seems to assume
the application/class drivers always support the "write in parts" method.
I'm not blaming the driver or it's
implementation but I just wanted to point out that there are drivers which
do not support handling chunked
write within them.

Here's the DW driver implementation:
[2]https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L1004
[3]https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L423

Another class driver, netusb does it a little differently by writing in
parts, but this too assumes the usb_write()
to be synchronous.

Here's what it does:
[4]https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/netusb/netusb.c#L189
Fragmentation to USB packets is done on a higher level, in function_ecm
and finction_rndis files.

One more thing to consider is the write callbacks. In most cases, the
application/class driver is the one that registers
the Bulk/Interrupt endpoint callbacks and the device stack has no way of
knowing when to perform the next write, even
if it wants to handle this in the USB device stack.

My question now is, what is the ideal place to take care of truncation and
chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and synchronization?

I understand that there are not going to be multiple USBD controllers on a
given chip and taking care of this in the
driver won't cost much from memory/CPU cycles point of view but from USB
DC driver implementation perspective
this might save a lot of time if the stack can abstract them.
Please also look to usb_dc_ep_transfer() implemented for DW and STM32:

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

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

Best regards
Andrei Emeltchenko


Re: FW: support for NFFS file system

Puzdrowski, Andrzej
 

> 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

Carles Cufi
 

Hi Paul,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: 30 January 2018 15:21
To: Sundar Subramaniyan <sundar.subramaniyan@gmail.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] USB: Question about usb_write() API

Hello Sundar,

On Tue, 30 Jan 2018 17:48:03 +0530
Sundar Subramaniyan <sundar.subramaniyan@gmail.com> wrote:

[]


My question now is, what is the ideal place to take care of truncation
and chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and
synchronization?

I understand that there are not going to be multiple USBD controllers
on a given chip and taking care of this in the driver won't cost much
from memory/CPU cycles point of view but from USB DC driver
implementation perspective this might save a lot of time if the stack
can abstract them.

Please let me know your opinions.
I'd suggest to look at this as a generic problem, not specific to USB
subsystem (e.g., there's the same issue in networking subsystem, etc.),
and consider the known best practices dealing with it. For example,
POSIX, when dealing with streams-of-bytes, always mandates possibility
of short reads/short writes (what you called "write in parts"). That
means that not drivers, but higher levels should take care of repeating
"long" operations.

This approach allows to implement simpler drivers (== easier to write,
less bugs), and allows for more flexibility on the higher levels.
But yes, the drawback of this approach is that it requires higher levels
to deal with repeating operations (POSIX passes that responsibility all
the way up to the application level, so each and every application needs
to have repetition loops*).

* Of course, that can be abstracted to a library. Different libraries
actually, because as mentioned, that's a flexible approach allowing to
implement different data flows and handling policies.
Although you raise a good point, I'm not convinced that this applies here. I think that what Sundar wants to know is whether this particular API call, usb_write(), was originally designed to be able to buffer data and fragment it into smaller USB-sized packets or instead it should mirror the state of whatever hardware FIFO it is using below, returning a number of bytes written different from the ones the caller asked to send. Beyond that there's the issue of the API call being blocking or not, which seems unclear given the different ways it is used in Zephyr.
To sum up, I thin he's trying to clarify the original intentions of the API designer in order to adapt the driver he's working on to it, not looking to modify the API itself.

Thanks,

Carles


Re: USB: Question about usb_write() API

Carles Cufi
 

+ Andrei

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Sundar Subramaniyan
Sent: 30 January 2018 13:18
To: zephyr-devel@...
Subject: [Zephyr-devel] USB: Question about usb_write() API

 

Hi,

While developing a USB device controller driver for the Nordic nRF52840 SoC,
I ran into the problem of handling chunked/partial write() while coding the usb_dc_ep_write() function.

From what I could gather, the usb_write() API documentation states that the application calling
this function may choose to write all the data buffer at once even if it is larger than the maximum
packet size supported by the USB endpoint to which we're writing to.
Let's call this method "write all at once".

If the application or the class driver can manage to write in parts, then it must use the "bytes_ret" argument
to know how much data is written on the bus so as to know if there's anymore data remaining to be written in
the subsequent call. Let's call this method "write in parts".

In my case, I'm using bt_usb and it tries to write all at once - i.e. there's no handling of remaining data.
This mandates the USB device controller driver to take care of the writing in parts within the driver itself.
While this can be done in a simple loop if the driver talks synchronously to the USBD HW and do a poll and
a yield or use a semaphore till the HW completes the DMA and there's room to write more.

Here's what bt_usb does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/bluetooth/hci_usb/src/main.c#L665

When I looked at other drivers to see how they are implemented, the designware USB driver seems to assume
the application/class drivers always support the "write in parts" method. I'm not blaming the driver or it's
implementation but I just wanted to point out that there are drivers which do not support handling chunked
write within them.

Here's the DW driver implementation:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L1004
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L423

Another class driver, netusb does it a little differently by writing in parts, but this too assumes the usb_write()
to be synchronous.

Here's what it does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/netusb/netusb.c#L189

One more thing to consider is the write callbacks. In most cases, the application/class driver is the one that registers
the Bulk/Interrupt endpoint callbacks and the device stack has no way of knowing when to perform the next write, even
if it wants to handle this in the USB device stack.

My question now is, what is the ideal place to take care of truncation and chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and synchronization?

I understand that there are not going to be multiple USBD controllers on a given chip and taking care of this in the
driver won't cost much from memory/CPU cycles point of view but from USB DC driver implementation perspective
this might save a lot of time if the stack can abstract them.

Please let me know your opinions.


Thanks,
Sundar


Re: USB: Question about usb_write() API

Paul Sokolovsky
 

Hello Sundar,

On Tue, 30 Jan 2018 17:48:03 +0530
Sundar Subramaniyan <sundar.subramaniyan@gmail.com> wrote:

[]


My question now is, what is the ideal place to take care of
truncation and chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and
synchronization?

I understand that there are not going to be multiple USBD controllers
on a given chip and taking care of this in the
driver won't cost much from memory/CPU cycles point of view but from
USB DC driver implementation perspective
this might save a lot of time if the stack can abstract them.

Please let me know your opinions.
I'd suggest to look at this as a generic problem, not specific to USB
subsystem (e.g., there's the same issue in networking subsystem, etc.),
and consider the known best practices dealing with it. For example,
POSIX, when dealing with streams-of-bytes, always mandates possibility
of short reads/short writes (what you called "write in parts"). That
means that not drivers, but higher levels should take care of repeating
"long" operations.

This approach allows to implement simpler drivers (== easier to
write, less bugs), and allows for more flexibility on the higher levels.
But yes, the drawback of this approach is that it requires higher levels
to deal with repeating operations (POSIX passes that responsibility
all the way up to the application level, so each and every application
needs to have repetition loops*).

* Of course, that can be abstracted to a library. Different libraries
actually, because as mentioned, that's a flexible approach allowing
to implement different data flows and handling policies.


Thanks,
Sundar


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Saving #BluetoothMesh Provisioning & Configuration related data on flash of nRF52 using NFFS #bluetoothmesh

Vikrant More <vikrant8051@...>
 

As per this document ....

nrf5_SDK_for_Mesh_v1.0.1_src/doc/introduction/mesh_hw_resources.md

(I've attached this file for reference......very informative)

The mesh stack uses flash to store the following states:
- Encryption keys
- Mesh addresses
- Access model composition
- Access model configuration
- Network message sequence number
- Network IV index state
- DFU metadata (it is not part of #BluetoothMesh Specs)

Link to download latest Nordic Mesh SDK v1.0.1 --> https://www.nordicsemi.com/eng/nordic/download_resource/62377/26/71116706/126781
Is other than this, anything else we have to save on flash  ?

Thank You !!

On Tue, Jan 30, 2018 at 5:22 PM, Vikrant More <vikrant8051@...> wrote:
After testing I found that it is necessary to add
__attribute__((packed)) after structure defination
Why ??  This will be helpful --> http://www.avabodh.com/cin/structure.html

So I edit above mentioned structure definition as (in both locations)

struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    }__attribute__((packed));



On Tue, Jan 30, 2018 at 3:49 PM, Vikrant More <vikrant8051@...> wrote:
Hello World !!

By including NFFS support into #BluetoothMesh project, now I can access flash of nRF52.

{
  Some useful links:

  http://docs.zephyrproject.org/api/file_system.html
  https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/thread.html (threads related to NFFS will be helpful to others )
}

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

I've edited prov_data( ) function which is available at $zephyr_base/subssy/bluetooth/host/mesh/prov.c as follow,

static void prov_data(const u8_t *data)
{
    struct net_buf_simple *msg = PROV_BUF(1);
    u8_t session_key[16];
    u8_t nonce[13];
    u8_t dev_key[16];
    u8_t pdu[25];
    u8_t flags;
    u32_t iv_index;
    u16_t addr;
    u16_t net_idx;
    int err;

    BT_DBG("");

    err = bt_mesh_session_key(link.dhkey, link.prov_salt, session_key);
    if (err) {
        BT_ERR("Unable to generate session key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("SessionKey: %s", bt_hex(session_key, 16));

    err = bt_mesh_prov_nonce(link.dhkey, link.prov_salt, nonce);
    if (err) {
        BT_ERR("Unable to generate session nonce");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("Nonce: %s", bt_hex(nonce, 13));

    err = bt_mesh_prov_decrypt(session_key, nonce, data, pdu);
    if (err) {
        BT_ERR("Unable to decrypt provisioning data");
        close_link(PROV_ERR_DECRYPT, CLOSE_REASON_FAILED);
        return;
    }

    err = bt_mesh_dev_key(link.dhkey, link.prov_salt, dev_key);
    if (err) {
        BT_ERR("Unable to generate device key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("DevKey: %s", bt_hex(dev_key, 16));

    net_idx = sys_get_be16(&pdu[16]);
    flags = pdu[18];
    iv_index = sys_get_be32(&pdu[19]);
    addr = sys_get_be16(&pdu[23]);

    BT_DBG("net_idx %u iv_index 0x%08x, addr 0x%04x",
           net_idx, iv_index, addr);

    prov_buf_init(msg, PROV_COMPLETE);
    prov_send(msg);

    /* Ignore any further PDUs on this link */
    link.expect = 0;

    bt_mesh_provision(pdu, net_idx, flags, iv_index, 0, addr, dev_key);


//------------------------------------------------------------------------------------------------------------------------------------------

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }foo;
   
     int i;

    for(i=0;i<=24;i++)
    {
        foo.a.pdu[i]=pdu[i];
    }

    for(i=0;i<=15;i++)
    {
        foo.a.dev_key[i]=dev_key[i];
    }

    foo.a.flags = flags;
    foo.a.net_idx = net_idx;
    foo.a.addr = addr;   
    foo.a.iv_index = iv_index;
 
    fs_file_t fp;   

    err = fs_open(&fp,"/prov.txt");
    if (err != 0)
    {
        printk("\n\rerror %d while opening prov_cfg.txt for write\n\r", err);
    }

    err = fs_write(&fp, foo.array, 50);
    if (err != 50)
    {
        printk("\n\rerror %d while writing PDU\n\r", err);
    }

    err = fs_close(&fp);
    if (err != 0)
    {
        printk("\n\rerror %d while closing prov_cfg.txt after write\n\r", err);
    }

//------------------------------------------------------------------------------------------------------------------------------------------


}


Similarly, edit bt_ready( ) from $zephyr_base/samples/bluetooth/mesh/src/main.c as follow

static void bt_ready(int err)
{
    .
    .
    .
    .
    printk("Mesh initialized\n\r");

    struct fs_dirent entry;

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }test;

    if(fs_stat("/prov.txt",&entry)==0)
    {
        printk("\n\rprov.txt is available\n\r");

        fs_file_t fp;

        err = fs_open(&fp,"/prov.txt");
        if (err != 0) {
            printk("error %d while opening for read\n\r", err);
        }

        err = fs_read(&fp, test.array, 50);
        if (err < 0) {
            printk("error %d while reading\n\r", err);
        }

        err = fs_close(&fp);
        if (err != 0) {
            printk("error %d while closing after read\n\r", err);
        }

        err = bt_mesh_provision(test.a.pdu, test.a.net_idx, test.a.flags, test.a.iv_index, 0, test.a.addr, test.a.dev_key);
   
        if(err)
        {
            printk("Provisioning failed (err %d)\n", err);
            return;
        }

        printk("Provisioning completed\n\r");
   
    }

}

So after reset if prov.txt is available then DEVICE will automatically provision itself.
And as per my testing it is working perfectly.

But is it right approach since I've dare to touch stack ? 🤔

Now I wanna save data related to configuration which happens just after provisioning.

Where I will find that function ?

I'm aware about bt_mesh_cfg_app_key_add( ) this function but for that we've to enable CONFIG_BT_MESH_CFG_CLI=y
Is it necessary ? ...because even we disable it, provisioner APP trigger some function which does every thing like bt_mesh_cfg_app_key_add( ) does.

So please tell me where I will find that function, so that I can save ALL data related configuration into cfg.txt ?

As per my understanding once we complete, Provisioning & Configuration process, then there is no need to touch prov.txt & cfg.txt
in future for writing ? Am I right ?

Besides prov.txt & cfg.txt , how many files we have to create ?

If there will be standard for creating files for #BluetoothMesh then that will helpful for all.

Thank You !!




USB: Question about usb_write() API

Sundar Subramaniyan
 

Hi,

While developing a USB device controller driver for the Nordic nRF52840 SoC,
I ran into the problem of handling chunked/partial write() while coding the usb_dc_ep_write() function.

From what I could gather, the usb_write() API documentation states that the application calling
this function may choose to write all the data buffer at once even if it is larger than the maximum
packet size supported by the USB endpoint to which we're writing to.
Let's call this method "write all at once".

If the application or the class driver can manage to write in parts, then it must use the "bytes_ret" argument
to know how much data is written on the bus so as to know if there's anymore data remaining to be written in
the subsequent call. Let's call this method "write in parts".

In my case, I'm using bt_usb and it tries to write all at once - i.e. there's no handling of remaining data.
This mandates the USB device controller driver to take care of the writing in parts within the driver itself.
While this can be done in a simple loop if the driver talks synchronously to the USBD HW and do a poll and
a yield or use a semaphore till the HW completes the DMA and there's room to write more.

Here's what bt_usb does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/bluetooth/hci_usb/src/main.c#L665

When I looked at other drivers to see how they are implemented, the designware USB driver seems to assume
the application/class drivers always support the "write in parts" method. I'm not blaming the driver or it's
implementation but I just wanted to point out that there are drivers which do not support handling chunked
write within them.

Here's the DW driver implementation:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L1004
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L423

Another class driver, netusb does it a little differently by writing in parts, but this too assumes the usb_write()
to be synchronous.

Here's what it does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/netusb/netusb.c#L189

One more thing to consider is the write callbacks. In most cases, the application/class driver is the one that registers
the Bulk/Interrupt endpoint callbacks and the device stack has no way of knowing when to perform the next write, even
if it wants to handle this in the USB device stack.

My question now is, what is the ideal place to take care of truncation and chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and synchronization?

I understand that there are not going to be multiple USBD controllers on a given chip and taking care of this in the
driver won't cost much from memory/CPU cycles point of view but from USB DC driver implementation perspective
this might save a lot of time if the stack can abstract them.

Please let me know your opinions.

Thanks,
Sundar


Re: Saving #BluetoothMesh Provisioning & Configuration related data on flash of nRF52 using NFFS #bluetoothmesh

Vikrant More <vikrant8051@...>
 

After testing I found that it is necessary to add
__attribute__((packed)) after structure defination
Why ??  This will be helpful --> http://www.avabodh.com/cin/structure.html

So I edit above mentioned structure definition as (in both locations)

struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    }__attribute__((packed));



On Tue, Jan 30, 2018 at 3:49 PM, Vikrant More <vikrant8051@...> wrote:
Hello World !!

By including NFFS support into #BluetoothMesh project, now I can access flash of nRF52.

{
  Some useful links:

  http://docs.zephyrproject.org/api/file_system.html
  https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/thread.html (threads related to NFFS will be helpful to others )
}

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

I've edited prov_data( ) function which is available at $zephyr_base/subssy/bluetooth/host/mesh/prov.c as follow,

static void prov_data(const u8_t *data)
{
    struct net_buf_simple *msg = PROV_BUF(1);
    u8_t session_key[16];
    u8_t nonce[13];
    u8_t dev_key[16];
    u8_t pdu[25];
    u8_t flags;
    u32_t iv_index;
    u16_t addr;
    u16_t net_idx;
    int err;

    BT_DBG("");

    err = bt_mesh_session_key(link.dhkey, link.prov_salt, session_key);
    if (err) {
        BT_ERR("Unable to generate session key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("SessionKey: %s", bt_hex(session_key, 16));

    err = bt_mesh_prov_nonce(link.dhkey, link.prov_salt, nonce);
    if (err) {
        BT_ERR("Unable to generate session nonce");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("Nonce: %s", bt_hex(nonce, 13));

    err = bt_mesh_prov_decrypt(session_key, nonce, data, pdu);
    if (err) {
        BT_ERR("Unable to decrypt provisioning data");
        close_link(PROV_ERR_DECRYPT, CLOSE_REASON_FAILED);
        return;
    }

    err = bt_mesh_dev_key(link.dhkey, link.prov_salt, dev_key);
    if (err) {
        BT_ERR("Unable to generate device key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("DevKey: %s", bt_hex(dev_key, 16));

    net_idx = sys_get_be16(&pdu[16]);
    flags = pdu[18];
    iv_index = sys_get_be32(&pdu[19]);
    addr = sys_get_be16(&pdu[23]);

    BT_DBG("net_idx %u iv_index 0x%08x, addr 0x%04x",
           net_idx, iv_index, addr);

    prov_buf_init(msg, PROV_COMPLETE);
    prov_send(msg);

    /* Ignore any further PDUs on this link */
    link.expect = 0;

    bt_mesh_provision(pdu, net_idx, flags, iv_index, 0, addr, dev_key);


//------------------------------------------------------------------------------------------------------------------------------------------

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }foo;
   
     int i;

    for(i=0;i<=24;i++)
    {
        foo.a.pdu[i]=pdu[i];
    }

    for(i=0;i<=15;i++)
    {
        foo.a.dev_key[i]=dev_key[i];
    }

    foo.a.flags = flags;
    foo.a.net_idx = net_idx;
    foo.a.addr = addr;   
    foo.a.iv_index = iv_index;
 
    fs_file_t fp;   

    err = fs_open(&fp,"/prov.txt");
    if (err != 0)
    {
        printk("\n\rerror %d while opening prov_cfg.txt for write\n\r", err);
    }

    err = fs_write(&fp, foo.array, 50);
    if (err != 50)
    {
        printk("\n\rerror %d while writing PDU\n\r", err);
    }

    err = fs_close(&fp);
    if (err != 0)
    {
        printk("\n\rerror %d while closing prov_cfg.txt after write\n\r", err);
    }

//------------------------------------------------------------------------------------------------------------------------------------------


}


Similarly, edit bt_ready( ) from $zephyr_base/samples/bluetooth/mesh/src/main.c as follow

static void bt_ready(int err)
{
    .
    .
    .
    .
    printk("Mesh initialized\n\r");

    struct fs_dirent entry;

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }test;

    if(fs_stat("/prov.txt",&entry)==0)
    {
        printk("\n\rprov.txt is available\n\r");

        fs_file_t fp;

        err = fs_open(&fp,"/prov.txt");
        if (err != 0) {
            printk("error %d while opening for read\n\r", err);
        }

        err = fs_read(&fp, test.array, 50);
        if (err < 0) {
            printk("error %d while reading\n\r", err);
        }

        err = fs_close(&fp);
        if (err != 0) {
            printk("error %d while closing after read\n\r", err);
        }

        err = bt_mesh_provision(test.a.pdu, test.a.net_idx, test.a.flags, test.a.iv_index, 0, test.a.addr, test.a.dev_key);
   
        if(err)
        {
            printk("Provisioning failed (err %d)\n", err);
            return;
        }

        printk("Provisioning completed\n\r");
   
    }

}

So after reset if prov.txt is available then DEVICE will automatically provision itself.
And as per my testing it is working perfectly.

But is it right approach since I've dare to touch stack ? 🤔

Now I wanna save data related to configuration which happens just after provisioning.

Where I will find that function ?

I'm aware about bt_mesh_cfg_app_key_add( ) this function but for that we've to enable CONFIG_BT_MESH_CFG_CLI=y
Is it necessary ? ...because even we disable it, provisioner APP trigger some function which does every thing like bt_mesh_cfg_app_key_add( ) does.

So please tell me where I will find that function, so that I can save ALL data related configuration into cfg.txt ?

As per my understanding once we complete, Provisioning & Configuration process, then there is no need to touch prov.txt & cfg.txt
in future for writing ? Am I right ?

Besides prov.txt & cfg.txt , how many files we have to create ?

If there will be standard for creating files for #BluetoothMesh then that will helpful for all.

Thank You !!



Saving #BluetoothMesh Provisioning & Configuration related data on flash of nRF52 using NFFS #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hello World !!

By including NFFS support into #BluetoothMesh project, now I can access flash of nRF52.

{
  Some useful links:

  http://docs.zephyrproject.org/api/file_system.html
  https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/thread.html (threads related to NFFS will be helpful to others )
}

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

I've edited prov_data( ) function which is available at $zephyr_base/subssy/bluetooth/host/mesh/prov.c as follow,

static void prov_data(const u8_t *data)
{
    struct net_buf_simple *msg = PROV_BUF(1);
    u8_t session_key[16];
    u8_t nonce[13];
    u8_t dev_key[16];
    u8_t pdu[25];
    u8_t flags;
    u32_t iv_index;
    u16_t addr;
    u16_t net_idx;
    int err;

    BT_DBG("");

    err = bt_mesh_session_key(link.dhkey, link.prov_salt, session_key);
    if (err) {
        BT_ERR("Unable to generate session key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("SessionKey: %s", bt_hex(session_key, 16));

    err = bt_mesh_prov_nonce(link.dhkey, link.prov_salt, nonce);
    if (err) {
        BT_ERR("Unable to generate session nonce");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("Nonce: %s", bt_hex(nonce, 13));

    err = bt_mesh_prov_decrypt(session_key, nonce, data, pdu);
    if (err) {
        BT_ERR("Unable to decrypt provisioning data");
        close_link(PROV_ERR_DECRYPT, CLOSE_REASON_FAILED);
        return;
    }

    err = bt_mesh_dev_key(link.dhkey, link.prov_salt, dev_key);
    if (err) {
        BT_ERR("Unable to generate device key");
        close_link(PROV_ERR_UNEXP_ERR, CLOSE_REASON_FAILED);
        return;
    }

    BT_DBG("DevKey: %s", bt_hex(dev_key, 16));

    net_idx = sys_get_be16(&pdu[16]);
    flags = pdu[18];
    iv_index = sys_get_be32(&pdu[19]);
    addr = sys_get_be16(&pdu[23]);

    BT_DBG("net_idx %u iv_index 0x%08x, addr 0x%04x",
           net_idx, iv_index, addr);

    prov_buf_init(msg, PROV_COMPLETE);
    prov_send(msg);

    /* Ignore any further PDUs on this link */
    link.expect = 0;

    bt_mesh_provision(pdu, net_idx, flags, iv_index, 0, addr, dev_key);


//------------------------------------------------------------------------------------------------------------------------------------------

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }foo;
   
     int i;

    for(i=0;i<=24;i++)
    {
        foo.a.pdu[i]=pdu[i];
    }

    for(i=0;i<=15;i++)
    {
        foo.a.dev_key[i]=dev_key[i];
    }

    foo.a.flags = flags;
    foo.a.net_idx = net_idx;
    foo.a.addr = addr;   
    foo.a.iv_index = iv_index;
 
    fs_file_t fp;   

    err = fs_open(&fp,"/prov.txt");
    if (err != 0)
    {
        printk("\n\rerror %d while opening prov_cfg.txt for write\n\r", err);
    }

    err = fs_write(&fp, foo.array, 50);
    if (err != 50)
    {
        printk("\n\rerror %d while writing PDU\n\r", err);
    }

    err = fs_close(&fp);
    if (err != 0)
    {
        printk("\n\rerror %d while closing prov_cfg.txt after write\n\r", err);
    }

//------------------------------------------------------------------------------------------------------------------------------------------


}


Similarly, edit bt_ready( ) from $zephyr_base/samples/bluetooth/mesh/src/main.c as follow

static void bt_ready(int err)
{
    .
    .
    .
    .
    printk("Mesh initialized\n\r");

    struct fs_dirent entry;

    struct prov_data
    {
        u8_t pdu[25];
        u8_t dev_key[16];
        u8_t flags;
        u16_t net_idx;
        u16_t addr;
        u32_t iv_index;
    };

    union
    {
        unsigned char array[50];
        struct prov_data a;
    }test;

    if(fs_stat("/prov.txt",&entry)==0)
    {
        printk("\n\rprov.txt is available\n\r");

        fs_file_t fp;

        err = fs_open(&fp,"/prov.txt");
        if (err != 0) {
            printk("error %d while opening for read\n\r", err);
        }

        err = fs_read(&fp, test.array, 50);
        if (err < 0) {
            printk("error %d while reading\n\r", err);
        }

        err = fs_close(&fp);
        if (err != 0) {
            printk("error %d while closing after read\n\r", err);
        }

        err = bt_mesh_provision(test.a.pdu, test.a.net_idx, test.a.flags, test.a.iv_index, 0, test.a.addr, test.a.dev_key);
   
        if(err)
        {
            printk("Provisioning failed (err %d)\n", err);
            return;
        }

        printk("Provisioning completed\n\r");
   
    }

}

So after reset if prov.txt is available then DEVICE will automatically provision itself.
And as per my testing it is working perfectly.

But is it right approach since I've dare to touch stack ? 🤔

Now I wanna save data related to configuration which happens just after provisioning.

Where I will find that function ?

I'm aware about bt_mesh_cfg_app_key_add( ) this function but for that we've to enable CONFIG_BT_MESH_CFG_CLI=y
Is it necessary ? ...because even we disable it, provisioner APP trigger some function which does every thing like bt_mesh_cfg_app_key_add( ) does.

So please tell me where I will find that function, so that I can save ALL data related configuration into cfg.txt ?

As per my understanding once we complete, Provisioning & Configuration process, then there is no need to touch prov.txt & cfg.txt
in future for writing ? Am I right ?

Besides prov.txt & cfg.txt , how many files we have to create ?

If there will be standard for creating files for #BluetoothMesh then that will helpful for all.

Thank You !!


Re: undefined reference to `bt_uuid_str'

Johan Hedberg
 

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


Re: Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Sundar Subramaniyan
 

Hi Carles,

Thanks for the information.
I'll get back if I run into other doubts.

Sundar


On Mon, Jan 29, 2018 at 3:55 PM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Sundar,

 

I am told internally that it should be EPDATASTATUS, there is an mistake in the documentation.

 

Thanks,

 

Carles

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Sundar Subramaniyan
Sent: 27 January 2018 17:13
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

 

Hi,



I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

 

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar



Re: Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

Sundar Subramaniyan
 

Hi Andrzej,

I'll make it read the EPDATASTATUS register alone for bulk/interrupt in that case.
Thanks for the clarification.

Sundar

On Mon, Jan 29, 2018 at 2:34 PM, Głąbek, Andrzej <Andrzej.Glabek@...> wrote:

Hi Sundar,

 

The EPDATASTATUS register is the one that you should examine after getting the EPDATA event (our USB expert has confirmed this).

nRF52840 documentation is a bit imprecise in this regard in section 51.10.2.

 

Best regards,

Andrzej

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Sundar Subramaniyan
Sent: Saturday, January 27, 2018 5:13 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Zephyr nRF52840 USBD driver development: EPSTATUS vs EPDATASTATUS register

 

Hi,

I'm developing a driver for USB device controller on nRF52840. I came across the BULK/INTERRUPT section in the datasheet and have some doubts.
My question is about the significance of EPSTATUS and EPDATASTATUS registers.

In Section 51.10.2 from the nRF52840 datasheet, it's mentioned that EPSTATUS register gets set when EPDATA event happens on one of the BULK/Interrupt OUT endpoint.

Here's the excerpt:
"Upon receiving the next OUT + DATA transaction, an ACK handshake
is returned to the host while a EPDATA event is sent (and EPSTATUS register flags set to indicate on which
endpoint this happened), and once the EasyDMA is prepared and enabled through writing the EPOUT[n]
registers and sending the STARTEPOUT[n] task, the incoming data will be transferred to Data RAM."

 

But according to section 51.13.23, EPSTATUS notifies only about the capture of EasyDMA registers. There's no mention about acknowledged data transfer on the USB bus.
Per section 51.13.24, the EPDATASTATUS register is the one that tells if there's an acknowledged DATA transfer on the USB bus.

So when a EPDATA event occurs, should I be reading EPSTATUS and EPDATASTATUS registers and infer which endpoint the event happened depending on the context/type of data exchange?
Could anyone please clarify?

Thanks in advance.

Sundar



undefined reference to `bt_uuid_str'

Gavrikov Paul <Paul.Gavrikov@...>
 

Hello,

 

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

 

Best regards,

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: tests/subsys/fs/nffs_fs_api fails after commit ff7dfc4fb44b5c987e42afc847dce33f43d520ba

Steve Brown
 

Hi Carles,

The test now builds and runs successfully.

Thanks,

Steve

On Mon, 2018-01-29 at 11:31 +0000, Cufi, Carles wrote:
Hi Steve,

Andrzej has posted a PR today:

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

Regards,

Carles

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-
devel-
bounces@lists.zephyrproject.org] On Behalf Of Steve Brown
Sent: 27 January 2018 11:15
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] tests/subsys/fs/nffs_fs_api fails after
commit
ff7dfc4fb44b5c987e42afc847dce33f43d520ba

From bisect
dts: bindings: add support for the flash driver name


***** BOOTING ZEPHYR OS v1.10.99 - BUILD: Jan 27 2018 10:01:12
*****
Running test suite nffs_fs_basic_test
===================================================================
starting test - test_unlink
***** BUS FAULT *****
Executing thread ID (thread): 0x20025920
Faulting instruction address: 0x9f38018
Instruction bus error
Fatal fault in thread 0x20025920! Aborting.

The board is a nrf52840_pca10056.

Additionally, there is a typo in the CMakeLists.txt file for this
board.

zephyrt_compile_definitions -> zephyr_compile_definitions

Also, the set CONF_FILE for this board doesn't have an effect.
prj.conf
is still used.

CONF_FILE=nrf5x.conf cmake -DBOARD=nrf52840_pca10056 ..

Selects the proper config file.

Steve

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

3981 - 4000 of 8033