|
Re: FW: support for NFFS file system
Vikrant More <vikrant8051@...>
toggle quoted messageShow quoted text
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
Â
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
Â
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:
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
Â
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
Â
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
Â
Â
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
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:
Â
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 ?
Â
On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:
Â
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 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
Â
Â
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
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:
Â
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 ?
Â
On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:
Â
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
Â
Â
Â
Â
Â
|
|
|
Re: USB: Question about usb_write() API
|
|
|
Re: USB: Question about usb_write() API
|
|
|
Re: USB: Question about usb_write() API
|
|
|
Re: USB: Question about usb_write() API
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/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
|
Re: USB: Question about usb_write() API
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/542The 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/5231Regards, Johann Fischer
|
|
|
Re: USB: Question about usb_write() API
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/5231https://github.com/zephyrproject-rtos/zephyr/pull/5214Best regards Andrei Emeltchenko
|
|
|
Re: FW: support for NFFS file system
> 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
Â
Â
toggle quoted messageShow quoted text
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
Â
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
Â
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:
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
Â
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
Â
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
Â
Â
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
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:
Â
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 ?
Â
On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:
Â
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 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
Â
Â
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
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:
Â
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 ?
Â
On Fri, Jan 19, 2018 at 12:15 AM, Michael Hope <michaelh@...> wrote:
Â
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
Â
Â
Â
Â
Â
|
|
|
Re: USB: Question about usb_write() API
Hi Paul,
toggle quoted messageShow quoted text
-----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
toggle quoted messageShow quoted text
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.
|
|
|
Re: USB: Question about usb_write() API
Hello Sundar,
toggle quoted messageShow quoted text
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/Linarohttp://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: 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));
|
|
|
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#L665When 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#L1004https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/usb/device/usb_dc_dw.c#L423Another 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#L189One 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@...>
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.
{
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.
{
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
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
Â
Â
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
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
Hi Carles,
The test now builds and runs successfully.
Thanks,
Steve
toggle quoted messageShow quoted text
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
|
|
|
