Date   

BLE stack using PPI channels #ble #nrf52832

robert.konc@...
 

In my application I was try to use 6 PPI channels. And I discovered that almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert


Re: Bluetooth: about using of NVS & setting Layer in single App

vikrant8051 <vikrant8051@...>
 

Hi Jehudi,

Many thanks for these details which are not available under https://docs.zephyrproject.org/latest/


On Tue 25 Sep, 2018, 1:42 PM Laczen JMS, <laczenjms@...> wrote:
Hi Vikrant,

The dts changes you propose might work, but there are some
disadvantages with it: if you are overlapping the scratch area with
NVS you will loose the data in NVS persistent storage after FOTA.

I guess this is related to your problem on using persistent storage
with btmesh. According to me the best way to use persistent storage in
combination with "btsettings" is to use "btsettings" to store and
retrieve your persistent variables. I don't have the time at the
moment to write a complete example but I can give you some guidelines:

Suppose we need to store a variable named: VID, and its value is
VID_VALUE. The values will be stored under "bt/ps". We will need to
define routines to apply the data at startup from flash: this is a set
routine. Other routines that we could define are export (to save the
data) and commit (to apply the data). For simplicity I will only
describe the case where there is only a set routine and storage will
be done directly.

Registering the routines is done by: BT_SETTINGS_DEFINE(ps, ps_set,
NULL, NULL): this will define a routine ps_set that will be called if
a variable is found under "bt/ps" (e.g. "bt/ps/VID"). The routine
ps_set itself is something like:

static int ps_set(int argc, char **argv, char *val) {
  if (argc!=1) {
    return -EINVAL;
  }
  if (strcmp(argv[0],"VID")==0) {
   len = sizeof(VID_VALUE);
   err = settings_bytes_from_str(val, VID_VALUE, &len);
  }
}

This routine will be called at startup and when VID is found under
"bt/ps" its value will be used to update VID_VALUE.

To store the variable you have to call two routines :
  str = settings_str_from_bytes(&VID_VALUE, sizeof(VID_VALUE), buf,
sizeof(buf));
  settings_save_one("bt/ps/VID", str);

The used buffer is a char array that can be defined as: char
buf[BT_SETTINGS_SIZE(sizeof(VID_VALUE))];
Op ma 24 sep. 2018 om 10:36 schreef Vikrant More <vikrant8051@...>:
>
> Hi,
>
> I've modified nrf52840_pca10056.dts as follow ......
>
> &flash0 {
>     /*
>      * For more information, see:
>      * http://docs.zephyrproject.org/latest/devices/dts/flash_partitions.html
>      */
>     partitions {
>         compatible = "fixed-partitions";
>         #address-cells = <1>;
>         #size-cells = <1>;
>
>         boot_partition: partition@0 {
>             label = "mcuboot";
>             reg = <0x000000000 0x0000C000>;
>         };
>         slot0_partition: partition@c000 {
>             label = "image-0";
>             reg = <0x0000C000 0x000069000>;
>         };
>         slot1_partition: partition@75000 {
>             label = "image-1";
>             reg = <0x00075000 0x000069000>;
>         };
>         scratch_partition: partition@de000 {
>             label = "image-scratch";
>             reg = <0x000de000 0x0001B000>;
>         };
>         nvs_partition: partition@f9000 {
>             label = "storage";
>             reg = <0x000f9000 0x00003000>;
>         };
>
> #if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
>         storage_partition: partition@fc000 {
>             label = "storage";
>             reg = <0x000fc000 0x00004000>;
>         };
> #endif
>     };
> };
>
> That means some part of scratch partition will get utilize ( 12 KB) for #NVS storage.
> After this I've to set #define NVS_STORAGE_OFFSET 0xF9000
>
> Is it correct strategy to save App level data on SoC flash without disturbing
> #settings_layer data as well feature of #FOTA ?
>
> Thank You !!
>
>


Re: Microbit Accelometer

Carles Cufi
 

Hi William,

 

Would you mind sending a GitHub Pull Request instead?

 

https://docs.zephyrproject.org/latest/contribute/contribute_guidelines.html

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of William Fish
Sent: 25 September 2018 12:40
To: devel@...
Subject: [Zephyr-devel] Microbit Accelometer

 

Hi All,

I’m attempting to get the accelometer on the microbit working in Zephyr. I have roughly created a driver based on others yet I could use some help double checking and implementing.

 

Attached are files:

 

Billy...

 

Virus-free. www.avg.com


Re: NRF52 : use of NFFS file system

Puzdrowski, Andrzej
 

  • I found a solution in increasing CONFIG_NFFS_FILESYSTEM_MAX_AREAS to 128

64 is exactly what you need as you use 64 flash pages of nRF52. You can try to use nffs build in statistic to garb some info

On RMA resurces consumed.

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Tuesday, September 25, 2018 4:53 PM
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Cufi, Carles <Carles.Cufi@...>
Subject: RE: NRF52 : use of NFFS file system

 

Hi Andrzej,

 

I found a solution in increasing CONFIG_NFFS_FILESYSTEM_MAX_AREAS to 128. But then I had a problem of space left in RAM so I decrease CONFIG_FS_NFFS_NUM_INODES to 48, which is enough for me. The solution seems ok for the first tests I make. I need to implement more tests but I can't do it right now.

I tried before that to set CONFIG_FS_NFFS_NUM_BLOCKS  to 2048 but it was not successful.

 

Thanks for your advice,

Regards

Laurence

 


De : Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Envoyé : mardi 25 septembre 2018 16:37
À : Laurence Pasteau; zephyr-devel@...; zephyr-users@...
Cc : Andrzej Kaczmarek; Cufi, Carles
Objet : RE: NRF52 : use of NFFS file system

 

I think it was possible that you encounter lack of BLOCK representation in RAM (this is what -12 -ENOMEM stand for). Try to increase CONFIG_FS_NFFS_NUM_BLOCKS until success.

Looks like GC was unable to optimize object in flash.

Can you try my advice and let now the reslt?

 

BR

Andrzej

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Friday, September 21, 2018 11:05 AM
To: zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Cufi, Carles <Carles.Cufi@...>
Subject: NRF52 : use of NFFS file system

 

Hi all,

 

Thanks having resolved my first issue on NFFS file system.

I work on a nrf52_pca10040 board. My purpose is still to use the file system NFFS to fill the nrf52 flash.

 

My flash config booked half of the flash for the file system :

 

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@40000 {
            label = "storage";
            reg = <0x00040000 0x00040000>;
        };
#endif

 

My test writes in loop 24 bytes in one or more files, as much as possible. (main_test.c attached)

I find a configuration that writes successfully all flash in one single file :

 

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

 

Result test :

test_files : 1 nb files
file write error (-28)
FILE :  test1.bin size 235968
FILE :  test2.bin size 0
FILE :  test3.bin size 0
FILE :  test4.bin size 0
FILE :  test5.bin size 0

Error -28 indicates that the flash is full.That's great.

 

But when I write in 5 differents files, I can not write all the flash and I have another error :

 

Result test :

test_files : 5 nb files
file write error (-12)

FILE :  test1.bin size 20448
FILE :  test2.bin size 20448
FILE :  test3.bin size 20448
FILE :  test4.bin size 20424
FILE :  test5.bin size 20424
write4 error

 

Attached is the little test used to have this result. It is a quick test with both success and error tests.

 

All tests with more than one file fails and I don't understand why. I don't know if my NFFS configuration is not good or if it is an issue in NFFS file ssytem.

 

If someone can help me it will be very helpful.

Thanks in advance,

Regards,

Laurence

 

 

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 18:50
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Laurence, I’ve assigned it and we will deal with it as soon as we can.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 18:08
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

 

Here is the link :

https://github.com/zephyrproject-rtos/zephyr/issues/9749

 

Regards,

Laurence

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 16:48
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

Yes please, if you could open a GitHub issue and then send us the link here we will be able to track it better.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 16:17
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

Sorry, I meant 0x30000 and 0x40000...

 


De : Laurence Pasteau
Envoyé : vendredi 31 août 2018 15:28
À : Cufi, Carles; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Carles,

 

the test lasts one or two minutes but can be shorten if necessary. My purpose is to have half of the flash (0x4000 bytes) in the file system. I have now a configuration with a flash system of 0x3000 bytes that has less problem but it still happens.

Files that are badly written are not recoverable, new weird files are not cleanable (with fs_unlink() function) so the system is not usable in my project for the moment.

 

If it is better, I can add an issue in github but I still don't know if I made a mistake in NFFS configuration or in the test, or if it is an issue in the file system.

 

Thanks in advance for any solution / idea / conclusions.

Laurence


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : mardi 28 août 2018 14:36
À : Laurence Pasteau; users@...; devel@...; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

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

 

Carles

 

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

 

Hi everybody,

 

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

 

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

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

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

 

I tried to modify NFFS configuration.

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

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

 

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

 

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

 

 

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

 

In the dts file :

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

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

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

 

In the conf file :

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

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

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

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: NRF52 : use of NFFS file system

Laurence Pasteau
 

Hi Andrzej,


I found a solution in increasing CONFIG_NFFS_FILESYSTEM_MAX_AREAS to 128. But then I had a problem of space left in RAM so I decrease CONFIG_FS_NFFS_NUM_INODES to 48, which is enough for me. The solution seems ok for the first tests I make. I need to implement more tests but I can't do it right now.

I tried before that to set CONFIG_FS_NFFS_NUM_BLOCKS  to 2048 but it was not successful.


Thanks for your advice,
Regards
Laurence


De : Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Envoyé : mardi 25 septembre 2018 16:37
À : Laurence Pasteau; zephyr-devel@...; zephyr-users@...
Cc : Andrzej Kaczmarek; Cufi, Carles
Objet : RE: NRF52 : use of NFFS file system
 

I think it was possible that you encounter lack of BLOCK representation in RAM (this is what -12 -ENOMEM stand for). Try to increase CONFIG_FS_NFFS_NUM_BLOCKS until success.

Looks like GC was unable to optimize object in flash.

Can you try my advice and let now the reslt?

 

BR

Andrzej

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Friday, September 21, 2018 11:05 AM
To: zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Cufi, Carles <Carles.Cufi@...>
Subject: NRF52 : use of NFFS file system

 

Hi all,

 

Thanks having resolved my first issue on NFFS file system.

I work on a nrf52_pca10040 board. My purpose is still to use the file system NFFS to fill the nrf52 flash.

 

My flash config booked half of the flash for the file system :

 

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@40000 {
            label = "storage";
            reg = <0x00040000 0x00040000>;
        };
#endif

 

My test writes in loop 24 bytes in one or more files, as much as possible. (main_test.c attached)

I find a configuration that writes successfully all flash in one single file :

 

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

 

Result test :

test_files : 1 nb files
file write error (-28)
FILE :  test1.bin size 235968
FILE :  test2.bin size 0
FILE :  test3.bin size 0
FILE :  test4.bin size 0
FILE :  test5.bin size 0

Error -28 indicates that the flash is full.That's great.

 

But when I write in 5 differents files, I can not write all the flash and I have another error :

 

Result test :

test_files : 5 nb files
file write error (-12)

FILE :  test1.bin size 20448
FILE :  test2.bin size 20448
FILE :  test3.bin size 20448
FILE :  test4.bin size 20424
FILE :  test5.bin size 20424
write4 error

 

Attached is the little test used to have this result. It is a quick test with both success and error tests.

 

All tests with more than one file fails and I don't understand why. I don't know if my NFFS configuration is not good or if it is an issue in NFFS file ssytem.

 

If someone can help me it will be very helpful.

Thanks in advance,

Regards,

Laurence

 

 

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 18:50
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Laurence, I’ve assigned it and we will deal with it as soon as we can.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 18:08
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

 

Here is the link :

https://github.com/zephyrproject-rtos/zephyr/issues/9749

 

Regards,

Laurence

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 16:48
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

Yes please, if you could open a GitHub issue and then send us the link here we will be able to track it better.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 16:17
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

Sorry, I meant 0x30000 and 0x40000...

 


De : Laurence Pasteau
Envoyé : vendredi 31 août 2018 15:28
À : Cufi, Carles; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Carles,

 

the test lasts one or two minutes but can be shorten if necessary. My purpose is to have half of the flash (0x4000 bytes) in the file system. I have now a configuration with a flash system of 0x3000 bytes that has less problem but it still happens.

Files that are badly written are not recoverable, new weird files are not cleanable (with fs_unlink() function) so the system is not usable in my project for the moment.

 

If it is better, I can add an issue in github but I still don't know if I made a mistake in NFFS configuration or in the test, or if it is an issue in the file system.

 

Thanks in advance for any solution / idea / conclusions.

Laurence


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : mardi 28 août 2018 14:36
À : Laurence Pasteau; users@...; devel@...; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

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

 

Carles

 

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

 

Hi everybody,

 

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

 

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

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

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

 

I tried to modify NFFS configuration.

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

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

 

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

 

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

 

 

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

 

In the dts file :

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

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

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

 

In the conf file :

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

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

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

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: NRF52 : use of NFFS file system

Puzdrowski, Andrzej
 

I think it was possible that you encounter lack of BLOCK representation in RAM (this is what -12 -ENOMEM stand for). Try to increase CONFIG_FS_NFFS_NUM_BLOCKS until success.

Looks like GC was unable to optimize object in flash.

Can you try my advice and let now the reslt?

 

BR

Andrzej

 

From: Laurence Pasteau [mailto:laurence.pasteau@...]
Sent: Friday, September 21, 2018 11:05 AM
To: zephyr-devel@...; zephyr-users@...
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Cufi, Carles <Carles.Cufi@...>
Subject: NRF52 : use of NFFS file system

 

Hi all,

 

Thanks having resolved my first issue on NFFS file system.

I work on a nrf52_pca10040 board. My purpose is still to use the file system NFFS to fill the nrf52 flash.

 

My flash config booked half of the flash for the file system :

 

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@40000 {
            label = "storage";
            reg = <0x00040000 0x00040000>;
        };
#endif

 

My test writes in loop 24 bytes in one or more files, as much as possible. (main_test.c attached)

I find a configuration that writes successfully all flash in one single file :

 

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

 

Result test :

test_files : 1 nb files
file write error (-28)
FILE :  test1.bin size 235968
FILE :  test2.bin size 0
FILE :  test3.bin size 0
FILE :  test4.bin size 0
FILE :  test5.bin size 0

Error -28 indicates that the flash is full.That's great.

 

But when I write in 5 differents files, I can not write all the flash and I have another error :

 

Result test :

test_files : 5 nb files
file write error (-12)

FILE :  test1.bin size 20448
FILE :  test2.bin size 20448
FILE :  test3.bin size 20448
FILE :  test4.bin size 20424
FILE :  test5.bin size 20424
write4 error

 

Attached is the little test used to have this result. It is a quick test with both success and error tests.

 

All tests with more than one file fails and I don't understand why. I don't know if my NFFS configuration is not good or if it is an issue in NFFS file ssytem.

 

If someone can help me it will be very helpful.

Thanks in advance,

Regards,

Laurence

 

 

 

 

---

Laurence Pasteau

laurence.pasteau@...

1 Avenue du Professeur Jean Rouxel, ZAC de la Fleuriaye, 44470 Carquefou

www.stimio.fr

 

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 18:50
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Laurence, I’ve assigned it and we will deal with it as soon as we can.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 18:08
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

 

Here is the link :

https://github.com/zephyrproject-rtos/zephyr/issues/9749

 

Regards,

Laurence

 

 


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : vendredi 31 août 2018 16:48
À : Laurence Pasteau; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

Yes please, if you could open a GitHub issue and then send us the link here we will be able to track it better.

 

Regards,

 

Carles

 

From: Laurence Pasteau <laurence.pasteau@...>
Sent: 31 August 2018 16:17
To: Cufi, Carles <Carles.Cufi@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; Andrzej Kaczmarek <andrzej.kaczmarek@...>
Subject: RE: NRF52 : use of NFFS file system

 

Sorry, I meant 0x30000 and 0x40000...

 


De : Laurence Pasteau
Envoyé : vendredi 31 août 2018 15:28
À : Cufi, Carles; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Thanks Carles,

 

the test lasts one or two minutes but can be shorten if necessary. My purpose is to have half of the flash (0x4000 bytes) in the file system. I have now a configuration with a flash system of 0x3000 bytes that has less problem but it still happens.

Files that are badly written are not recoverable, new weird files are not cleanable (with fs_unlink() function) so the system is not usable in my project for the moment.

 

If it is better, I can add an issue in github but I still don't know if I made a mistake in NFFS configuration or in the test, or if it is an issue in the file system.

 

Thanks in advance for any solution / idea / conclusions.

Laurence


De : Cufi, Carles <Carles.Cufi@...>
Envoyé : mardi 28 août 2018 14:36
À : Laurence Pasteau; users@...; devel@...; Puzdrowski, Andrzej; Andrzej Kaczmarek
Objet : RE: NRF52 : use of NFFS file system

 

Hi Laurence,

 

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

 

Carles

 

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

 

Hi everybody,

 

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

 

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

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

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

 

I tried to modify NFFS configuration.

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

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

 

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

 

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

 

 

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

 

In the dts file :

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

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

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

 

In the conf file :

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

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

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

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Microbit Accelometer

William Fish <william.fish@...>
 

Hi All,

I’m attempting to get the accelometer on the microbit working in Zephyr. I have roughly created a driver based on others yet I could use some help double checking and implementing.

 

Attached are files:

 

Billy...


Virus-free. www.avg.com


Microbit accelerometer

William Fish
 

Hi All,

I’m attempting to get the accelerometer on the microbit working in Zephyr. I have roughly created a driver based on others yet I could use some help double checking and implementing.

Any and all help appreciated.

Attached are files:

 

 

Billy...


Re: Bluetooth: about using of NVS & setting Layer in single App

laczenJMS
 

Hi Vikrant,

The dts changes you propose might work, but there are some
disadvantages with it: if you are overlapping the scratch area with
NVS you will loose the data in NVS persistent storage after FOTA.

I guess this is related to your problem on using persistent storage
with btmesh. According to me the best way to use persistent storage in
combination with "btsettings" is to use "btsettings" to store and
retrieve your persistent variables. I don't have the time at the
moment to write a complete example but I can give you some guidelines:

Suppose we need to store a variable named: VID, and its value is
VID_VALUE. The values will be stored under "bt/ps". We will need to
define routines to apply the data at startup from flash: this is a set
routine. Other routines that we could define are export (to save the
data) and commit (to apply the data). For simplicity I will only
describe the case where there is only a set routine and storage will
be done directly.

Registering the routines is done by: BT_SETTINGS_DEFINE(ps, ps_set,
NULL, NULL): this will define a routine ps_set that will be called if
a variable is found under "bt/ps" (e.g. "bt/ps/VID"). The routine
ps_set itself is something like:

static int ps_set(int argc, char **argv, char *val) {
if (argc!=1) {
return -EINVAL;
}
if (strcmp(argv[0],"VID")==0) {
len = sizeof(VID_VALUE);
err = settings_bytes_from_str(val, VID_VALUE, &len);
}
}

This routine will be called at startup and when VID is found under
"bt/ps" its value will be used to update VID_VALUE.

To store the variable you have to call two routines :
str = settings_str_from_bytes(&VID_VALUE, sizeof(VID_VALUE), buf,
sizeof(buf));
settings_save_one("bt/ps/VID", str);

The used buffer is a char array that can be defined as: char
buf[BT_SETTINGS_SIZE(sizeof(VID_VALUE))];
Op ma 24 sep. 2018 om 10:36 schreef Vikrant More <vikrant8051@gmail.com>:


Hi,

I've modified nrf52840_pca10056.dts as follow ......

&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/latest/devices/dts/flash_partitions.html
*/
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

boot_partition: partition@0 {
label = "mcuboot";
reg = <0x000000000 0x0000C000>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000C000 0x000069000>;
};
slot1_partition: partition@75000 {
label = "image-1";
reg = <0x00075000 0x000069000>;
};
scratch_partition: partition@de000 {
label = "image-scratch";
reg = <0x000de000 0x0001B000>;
};
nvs_partition: partition@f9000 {
label = "storage";
reg = <0x000f9000 0x00003000>;
};

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
storage_partition: partition@fc000 {
label = "storage";
reg = <0x000fc000 0x00004000>;
};
#endif
};
};

That means some part of scratch partition will get utilize ( 12 KB) for #NVS storage.
After this I've to set #define NVS_STORAGE_OFFSET 0xF9000

Is it correct strategy to save App level data on SoC flash without disturbing
#settings_layer data as well feature of #FOTA ?

Thank You !!


Re: Running Hello World for Dragino-LSN50 on B-L072Z-LRWAN1 Dicovery Board

Erwan Gouriou
 

Sure, would be great to have this LORA board in tree.


On Sat, 22 Sep 2018 at 21:59, seems.deviant <seems.deviant@...> wrote:
After setting everything  in .dts and defconfig, Hello world finally started working.

Thanks for assistance. Do you think its worth creating pull request fwith my changes?


- Aleksandr
21 сент. 2018 г. 11:11 ПП | От: Erwan Gouriou <erwan.gouriou@...> | Сообщение:


Le ven. 21 sept. 2018 à 10:45, <seems.deviant@...> a écrit :

В Чтв, 20/09/2018 в 23:43 +0200, Erwan Gouriou пишет:
> Hi,
>
> Looking to B-L072Z-LRWAN1 user manual, it seems that you can get ST-
> Link VCP using USART2,
> Did you changed the console settings to match this configuration ?
>

In order to answer your question I've inspected the
boards/arm/nucleo_l073rz/nucleo_l073rz_defconfig which has a Virtual
COM Port. And I didn't find any UART-specific configuration
options except for CONFIG_SERIAL, CONFIG_CONSOLE and
CONFIG_UART_CONSOLE that should be specified for a VCP to work
correctly.

You don't have to care about VCP, this is internal to ST-Link chip, just make sure that console is set to uart2(.DTS) and enabled (_defconfig).

Could you point out which options do I need to change/specify?

> Then, fortunately, both boards share the same pin mapping on this
> UART,
> so on this point you should be fine.
>
> Last, one point to check would be the clock settings;
> Dragino uses HSI driven PLL, does this fit with B-L072Z-LRWAN1?
>

Yes, the B-L072Z-LRWAN1 uses the same HSI 16M clock source, that's what
datasheet says.

Great, you should be fine then!

> Cheers
>
>
>
> On Thu, 20 Sep 2018 at 22:16, Aleksandr Makarov <seems.deviant@gmail.
> com> wrote:
> > Hello,
> >
> > I am trying to run Hello World application built for Dragino-LSN50
> > on a
> > B-L072Z-LRWAN1 Dicovery Board. Those two boards both are SM32L0-
> > based
> > and share exactly the same MCU model - SMT32L072CZY.
> >
> > The build process and device flashing work fine, however I can't
> > see a
> > "Hello World!" print on a COM terminal after a reset.
> >
> > A working USART port is the only peripheral I care for now. The
> > USART
> > pin configuration for Dragino LSN50 board should be suitable for
> > L072Z-
> > LRWAN1 as well, though it is not working.
> >
> > Please advice.
> >
> >
> >


Bluetooth: about using of NVS & setting Layer in single App

vikrant8051 <vikrant8051@...>
 

Hi,

I've modified nrf52840_pca10056.dts as follow ......

&flash0 {
    /*
     * For more information, see:
     * http://docs.zephyrproject.org/latest/devices/dts/flash_partitions.html
     */
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x000000000 0x0000C000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x000069000>;
        };
        slot1_partition: partition@75000 {
            label = "image-1";
            reg = <0x00075000 0x000069000>;
        };
        scratch_partition: partition@de000 {
            label = "image-scratch";
            reg = <0x000de000 0x0001B000>;
        };

        nvs_partition: partition@f9000 {
            label = "storage";
            reg = <0x000f9000 0x00003000>;
        };


#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@fc000 {
            label = "storage";
            reg = <0x000fc000 0x00004000>;
        };
#endif
    };
};

That means some part of scratch partition will get utilize ( 12 KB) for #NVS storage.
After this I've to set #define NVS_STORAGE_OFFSET 0xF9000

Is it correct strategy to save App level data on SoC flash without disturbing
#settings_layer data as well feature of #FOTA ?

Thank You !!



Don't have Interrupt latency test result in Time Measurement test report

seems.deviant@...
 

Hello,

I am running a timing_info test on my B-L072Z-LRWAN1. It builds and
runs on the board, but the Interrupt Latency value is missing from the
resulting report:

$ cd tests/benchmarks/timing_info/
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=b_l072z_lrwan1 ..
$ ninja flash
# picocom -b 115200 /dev/ttyACM0

***** Booting Zephyr OS zephyr-v1.13.0-297-ga013ce3bf *****
starting test - Time Measurement
Timing Results: Clock Frequency: 32 MHz
Context switch : 220 cycles , 6875 ns
Tick overhead : 491 cycles , 15343 ns
Thread Creation : 567 cycles , 17718 ns
Thread cancel : 226 cycles , 7062 ns
Thread abort : 529 cycles , 16531 ns
Thread Suspend : 536 cycles , 16750 ns
Thread Resume : 573 cycles , 17906 ns
Thread Yield : 463 cycles , 14468 ns
Thread Sleep : 749 cycles , 23406 ns
Heap Malloc :1370 cycles , 42812 ns
Heap Free :1172 cycles , 36625 ns
Semaphore Take with context switch : 820 cycles , 25625 ns
Semaphore Give with context switch : 774 cycles , 24187 ns
Semaphore Take without context switch : 78 cycles , 2437 ns
Semaphore Give without context switch : 214 cycles , 6687 ns
Mutex lock : 251 cycles , 7843 ns
Mutex unlock : 339 cycles , 10593 ns
Message Queue Put with context switch : 870 cycles , 27187 ns
Message Queue Put without context switch : 282 cycles , 8812 ns
Message Queue get with context switch :1003 cycles , 31343 ns
Message Queue get without context switch : 281 cycles , 8781 ns
MailBox synchronous put :1070 cycles , 33437 ns
MailBox synchronous get :1044 cycles , 32625 ns
MailBox asynchronous put : 458 cycles , 14312 ns
MailBox get without context switch : 824 cycles , 25750 ns
Timing Measurement finished
PASS - main
===================================================================
===================================================================
PROJECT EXECUTION SUCCESSFUL


Re: Running Hello World for Dragino-LSN50 on B-L072Z-LRWAN1 Dicovery Board

seems.deviant <seems.deviant@...>
 

After setting everything  in .dts and defconfig, Hello world finally started working.

Thanks for assistance. Do you think its worth creating pull request fwith my changes?


- Aleksandr
21 сент. 2018 г. 11:11 ПП | От: Erwan Gouriou <erwan.gouriou@...> | Сообщение:



Le ven. 21 sept. 2018 à 10:45, <seems.deviant@...> a écrit :

В Чтв, 20/09/2018 в 23:43 +0200, Erwan Gouriou пишет:
> Hi,
>
> Looking to B-L072Z-LRWAN1 user manual, it seems that you can get ST-
> Link VCP using USART2,
> Did you changed the console settings to match this configuration ?
>

In order to answer your question I've inspected the
boards/arm/nucleo_l073rz/nucleo_l073rz_defconfig which has a Virtual
COM Port. And I didn't find any UART-specific configuration
options except for CONFIG_SERIAL, CONFIG_CONSOLE and
CONFIG_UART_CONSOLE that should be specified for a VCP to work
correctly.

You don't have to care about VCP, this is internal to ST-Link chip, just make sure that console is set to uart2(.DTS) and enabled (_defconfig).

Could you point out which options do I need to change/specify?

> Then, fortunately, both boards share the same pin mapping on this
> UART,
> so on this point you should be fine.
>
> Last, one point to check would be the clock settings;
> Dragino uses HSI driven PLL, does this fit with B-L072Z-LRWAN1?
>

Yes, the B-L072Z-LRWAN1 uses the same HSI 16M clock source, that's what
datasheet says.

Great, you should be fine then!

> Cheers
>
>
>
> On Thu, 20 Sep 2018 at 22:16, Aleksandr Makarov <seems.deviant@gmail.
> com> wrote:
> > Hello,
> >
> > I am trying to run Hello World application built for Dragino-LSN50
> > on a
> > B-L072Z-LRWAN1 Dicovery Board. Those two boards both are SM32L0-
> > based
> > and share exactly the same MCU model - SMT32L072CZY.
> >
> > The build process and device flashing work fine, however I can't
> > see a
> > "Hello World!" print on a COM terminal after a reset.
> >
> > A working USART port is the only peripheral I care for now. The
> > USART
> > pin configuration for Dragino LSN50 board should be suitable for
> > L072Z-
> > LRWAN1 as well, though it is not working.
> >
> > Please advice.
> >
> >
> >


Re: SPI driver development

Vincent - VLoTech
 

Hi Jiri,

Sorry for my late reply. I was out of the office  a few days.

Good to hear you've made good progress. I've spoken with Justin, who maintains the SAM drivers. He proposed to take a look at the ADC and UART driver as example.
He offered to help testing where needed. Would you be open to share your current progress and compare implementations? I can also create a github fork we can work into together or so?
I would say, whatever works for you.

Looking forward to your response.

Kind regards,

Vincent


On 09/17/2018 03:17 PM, Jiří Kubias wrote:
Hi Vincent,
Im open minded 8-). I have implemented SPI driver with polling - seems to be working fine for moth ways. But configuration stuff need some recheck and only one CS is supported.  I have tried to implement the DMA (I can compile it) into my driver but it fails when I bind the DMA - I have received MPU protection fault. Unfortunately there not many examples with DMA so it is not so simply to implement it... In another thread was reported also MPU fault with v1.13 which Im using. But it seems to be fixed in GIT so I have to recheck it again to see if the problem is still there or not.  I would like to finish it this week but Im sharing my time with another projects.... 

I will also try to implement the flash driver - but I didnt started yet.

Regards, 
Jiri


2018-09-17 15:07 GMT+02:00 <vincent@...>:

Hi Jiri, 

I'm was planning a SPI driver for the SAM4S and later on the SAMe70. 
I have sufficient boards to test the SPI driver, with displays, flash, IMU and transceivers on them to push its boundries. I can add the IRQ and DMA also, as I was using both with another RTOS before. 

Perhaps we can combine effort for this. 

Kind regards,
Vincent 




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

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient's and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

TERMS AND CONDITIONS : All contracts & agreements are carried out in accordance with VLoTech's general terms and conditions. Entry into the contract implies acceptance of the applicability of the general terms and conditions of VLoTech. The general terms and conditions are stated on our web page ( www.VLoTech.com - click on "terms and conditions" - ), and a printed copy can be sent free of charge on request.


Re: Running Hello World for Dragino-LSN50 on B-L072Z-LRWAN1 Dicovery Board

Erwan Gouriou
 



Le ven. 21 sept. 2018 à 10:45, <seems.deviant@...> a écrit :

В Чтв, 20/09/2018 в 23:43 +0200, Erwan Gouriou пишет:
> Hi,
>
> Looking to B-L072Z-LRWAN1 user manual, it seems that you can get ST-
> Link VCP using USART2,
> Did you changed the console settings to match this configuration ?
>

In order to answer your question I've inspected the
boards/arm/nucleo_l073rz/nucleo_l073rz_defconfig which has a Virtual
COM Port. And I didn't find any UART-specific configuration
options except for CONFIG_SERIAL, CONFIG_CONSOLE and
CONFIG_UART_CONSOLE that should be specified for a VCP to work
correctly.

You don't have to care about VCP, this is internal to ST-Link chip, just make sure that console is set to uart2(.DTS) and enabled (_defconfig).

Could you point out which options do I need to change/specify?

> Then, fortunately, both boards share the same pin mapping on this
> UART,
> so on this point you should be fine.
>
> Last, one point to check would be the clock settings;
> Dragino uses HSI driven PLL, does this fit with B-L072Z-LRWAN1?
>

Yes, the B-L072Z-LRWAN1 uses the same HSI 16M clock source, that's what
datasheet says.

Great, you should be fine then!

> Cheers
>
>
>
> On Thu, 20 Sep 2018 at 22:16, Aleksandr Makarov <seems.deviant@gmail.
> com> wrote:
> > Hello,
> >
> > I am trying to run Hello World application built for Dragino-LSN50
> > on a
> > B-L072Z-LRWAN1 Dicovery Board. Those two boards both are SM32L0-
> > based
> > and share exactly the same MCU model - SMT32L072CZY.
> >
> > The build process and device flashing work fine, however I can't
> > see a
> > "Hello World!" print on a COM terminal after a reset.
> >
> > A working USART port is the only peripheral I care for now. The
> > USART
> > pin configuration for Dragino LSN50 board should be suitable for
> > L072Z-
> > LRWAN1 as well, though it is not working.
> >
> > Please advice.
> >
> >
> >


Re: Running Hello World for Dragino-LSN50 on B-L072Z-LRWAN1 Dicovery Board

seems.deviant@...
 

В Чтв, 20/09/2018 в 23:43 +0200, Erwan Gouriou пишет:
Hi,

Looking to B-L072Z-LRWAN1 user manual, it seems that you can get ST-
Link VCP using USART2,
Did you changed the console settings to match this configuration ?
In order to answer your question I've inspected the
boards/arm/nucleo_l073rz/nucleo_l073rz_defconfig which has a Virtual
COM Port. And I didn't find any UART-specific configuration
options except for CONFIG_SERIAL, CONFIG_CONSOLE and
CONFIG_UART_CONSOLE that should be specified for a VCP to work
correctly.

Could you point out which options do I need to change/specify?

Then, fortunately, both boards share the same pin mapping on this
UART,
so on this point you should be fine.

Last, one point to check would be the clock settings;
Dragino uses HSI driven PLL, does this fit with B-L072Z-LRWAN1?
Yes, the B-L072Z-LRWAN1 uses the same HSI 16M clock source, that's what
datasheet says.

Cheers



On Thu, 20 Sep 2018 at 22:16, Aleksandr Makarov <seems.deviant@gmail.
com> wrote:
Hello,

I am trying to run Hello World application built for Dragino-LSN50
on a
B-L072Z-LRWAN1 Dicovery Board. Those two boards both are SM32L0-
based
and share exactly the same MCU model - SMT32L072CZY.

The build process and device flashing work fine, however I can't
see a
"Hello World!" print on a COM terminal after a reset.

A working USART port is the only peripheral I care for now. The
USART
pin configuration for Dragino LSN50 board should be suitable for
L072Z-
LRWAN1 as well, though it is not working.

Please advice.



Re: Choosing Tx Buffers in BLE stack

Von Dentz, Luiz <luiz.von.dentz@...>
 

Hi,

I guess that is because with more buffer one can queue more data and
is less affected by the speed in which the controller acknowledge
their transmissions, obviously this increase the footprint but it is
the usual trade of size for speed. Btw, if the improvement is
substantial maybe we should have 3 by default, though we need to
figure if the crash on windows is due to some misbehaviour on our side
when are operating with more buffers.

On Fri, Sep 21, 2018 at 1:58 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Copying a few people to this thread.

Carles

________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
behalf of dhguja@gmail.com <dhguja@gmail.com>
Sent: Thursday, September 20, 2018 11:56 AM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack

Hello,
I am working on a BLE HID keyboard application using zephyr 1.13.

I was playing around with Tx buffers (specifically Maximum number of pending
TX buffers, Number of Tx buffers).
With default buffer settings the characters were transmitted very slowly due
to small number of buffers. But as soon as
i increased it to 3 pending buffers and 3 Tx buffers i saw significant
improvement in the speed of characters transmitted.
My question is how to choose the buffer values for this?.

The reason is currently i face a compatibility problem with my HID
application, where it works fine in Linux, Android, iOS devices
with increased number of buffers, but crashes on windows system. When i
debugged the HCI log (from btmon) i saw that with
increased buffers, characters are sent very quickly on the order of 500 us
for each character. This causes the data (of 20 characters)
to be transmitted within one or two connection intervals. Maybe this causes
some overflow in windows systems. I would like to know
what are the implications of choosing a number of Tx buffers and pending
buffers.

It will be helpful if anyone can tell how to choose the number of Tx
buffers? or even point to some direction in the BLE specification?

Thank you,
Dhananjay G J


Re: Choosing Tx Buffers in BLE stack

dhguja@gmail.com
 

Hi,
    Thanks for the reply. Sorry if there is some confusion regarding the crash on windows. 

I will explain more elaborately below what i am trying to achieve & what i debugged till now.

I am working on BLE based barcode scanner which will send the data via HID over GATT profile. I am using nRF52840 
device and Zephyr 1.13 with default connection interval parameters. With the default Tx buffer numbers provided in zephyr
the characters are sent to peer devices very slowly. We can literally see that characters are printed one by one. When i checked
the HCI timestamps using btmon i see that 1 character is sent every connection interval time(around 45 ms ). 

To remove the bottleneck on Tx buffers i increased Maximum number of pending TX buffers (3) , Number of Tx buffers(3).
I see that characters are sent instantly now (within one connection interval or even less than 10ms). The improvement in speed
is seen only when i change both of these parameters from the default values.

Now with this new config changes related to Tx buffers my application works fast as expected in Android, iOS, Linux systems. 
But on windows 10 system after two or three scans 'Windows' HID driver crashes probably due to buffer overflow from sending the 
data so fast. I checked the windows log and i see that "A command sent to the adapter has timed out. The adapter did not respond".
The behavior seen is that characters are not accepted anymore and the last character that is sent to windows is printed continuously 
until the connection is closed. On the zephyr side, the bt_gatt_notify API is blocked until this time and then returns with error. 
I also checked the connection interval used with Windows 10 system as 40 ms.

I also changed different buffer numbers to know the behavior but this just changes the time when this crash in windows occurs again. 
I also checked with some commercial devices that have similar application of using HID profile to send data and it also uses buffering
to speed up. One thing i noticed in commercial device is for every 10 characters sent there is some delay equal to max connection 
interval time. But in case of my application using zephyr there is just 1 delay with connection interval for even up to 40 characters that are 
sent.

In order to control the speed of buffering i tried changing different buffer numbers but with no luck or information on how to proceed
further. If i know how to calculate or more information on these i can try to control the speed of my application by using buffer numbers or 
delays like i saw in other commercial devices. It would be helpful even if i had to look for something else in BLE specification or Zephyr.

Thanks very much for the help.

Regards,
Dhananjay G J











On Fri, Sep 21, 2018 at 1:20 PM Von Dentz, Luiz <luiz.von.dentz@...> wrote:
Hi,

I guess that is because with more buffer one can queue more data and
is less affected by the speed in which the controller acknowledge
their transmissions, obviously this increase the footprint but it is
the usual trade of size for speed. Btw, if the improvement is
substantial maybe we should have 3 by default, though we need to
figure if the crash on windows is due to some misbehaviour on our side
when are operating with more buffers.

On Fri, Sep 21, 2018 at 1:58 PM, Cufi, Carles <Carles.Cufi@...> wrote:
>
> Hi there,
>
> Copying a few people to this thread.
>
> Carles
>
> ________________________________
> From: devel@... <devel@...> on
> behalf of dhguja@... <dhguja@...>
> Sent: Thursday, September 20, 2018 11:56 AM
> To: devel@...
> Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack
>
> Hello,
>       I am working on a BLE HID keyboard application using zephyr 1.13.
>
> I was playing around with Tx buffers (specifically Maximum number of pending
> TX buffers, Number of Tx buffers).
> With default buffer settings the characters were transmitted very slowly due
> to small number of buffers. But as soon as
> i increased it to 3 pending buffers and 3 Tx buffers i saw significant
> improvement in the speed of characters transmitted.
> My question is how to choose the buffer values for this?.
>
> The reason is currently i face a compatibility problem with my HID
> application, where it works fine in Linux, Android, iOS devices
> with increased number of buffers, but crashes on windows system. When i
> debugged the HCI log (from btmon) i saw that with
> increased buffers, characters are sent very quickly on the order of 500 us
> for each character. This causes the data (of 20 characters)
> to be transmitted within one or two connection intervals. Maybe this causes
> some overflow in windows systems. I would like to know
> what are the implications of choosing a number of Tx buffers and pending
> buffers.
>
> It will be helpful if anyone can tell how to choose the number of Tx
> buffers? or even point to some direction in the BLE specification?
>
> Thank you,
> Dhananjay G J


Re: Choosing Tx Buffers in BLE stack

Chettimada, Vinayak Kariappa
 

characters are sent very quickly on the order of 500 us for each character
Please clarify, minimum BLE connection interval is 7.5 ms.

Do you know what is the connection interval used by Window when you see the Window OS crash? you get Blue Screen of Death? Which version of Window OS?

As the TX Buffer implies, it’s the number of packets queued locally until a chance to transmit them to the peer. Your TX Buffer count should be based on the rate of generation of packets per BLE connection interval.
Usually, 7 Tx Buffers for slave role for a connection interval of 7.5ms should suffice. Actually calculation of optimal buffer count should be based on how fast, and how many bytes per packet is generated when Controller is transmitting the previous packet.

- Vinayak


-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Carles Cufi <carles.cufi@nordicsemi.no>
Date: Friday, 21 September 2018 at 12:58 PM
To: "dhguja@gmail.com" <dhguja@gmail.com>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>, "Dunaj, Pawel" <padu@nvlsi.no>, "Gawor, Kamil" <Kamil.Gawor@nordicsemi.no>, "Piszczek, Kamil" <Kamil.Piszczek@nordicsemi.no>, "Von Dentz, Luiz" <luiz.von.dentz@intel.com>
Subject: Re: [Zephyr-devel] Choosing Tx Buffers in BLE stack



Hi there,


Copying a few people to this thread.

Carles

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of dhguja@gmail.com <dhguja@gmail.com>
Sent: Thursday, September 20, 2018 11:56 AM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack

Hello,
I am working on a BLE HID keyboard application using zephyr 1.13.


I was playing around with Tx buffers (specifically Maximum number of pending TX buffers, Number of Tx buffers).

With default buffer settings the characters were transmitted very slowly due to small number of buffers. But as soon as

i increased it to 3 pending buffers and 3 Tx buffers i saw significant improvement in the speed of characters transmitted.

My question is how to choose the buffer values for this?.

The reason is currently i face a compatibility problem with my HID application, where it works fine in Linux, Android, iOS devices

with increased number of buffers, but crashes on windows system. When i debugged the HCI log (from
btmon) i saw that with
increased buffers, characters are sent very quickly on the order of 500 us for each character. This causes the data (of 20 characters)
to be transmitted within one or two connection intervals. Maybe this causes some overflow in windows systems. I would like to know

what are the implications of choosing a number of Tx buffers and pending buffers.

It will be helpful if anyone can tell how to choose the number of Tx buffers? or even point to some direction in the BLE specification?

Thank you,
Dhananjay G J


Re: Choosing Tx Buffers in BLE stack

Carles Cufi
 


Hi there,

Copying a few people to this thread.

Carles


From: devel@... <devel@...> on behalf of dhguja@... <dhguja@...>
Sent: Thursday, September 20, 2018 11:56 AM
To: devel@...
Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack
 
Hello,
      I am working on a BLE HID keyboard application using zephyr 1.13.

I was playing around with Tx buffers (specifically Maximum number of pending TX buffers, Number of Tx buffers).
With default buffer settings the characters were transmitted very slowly due to small number of buffers. But as soon as
i increased it to 3 pending buffers and 3 Tx buffers i saw significant improvement in the speed of characters transmitted.
My question is how to choose the buffer values for this?.

The reason is currently i face a compatibility problem with my HID application, where it works fine in Linux, Android, iOS devices
with increased number of buffers, but crashes on windows system. When i debugged the HCI log (from btmon) i saw that with
increased buffers, characters are sent very quickly on the order of 500 us for each character. This causes the data (of 20 characters)
to be transmitted within one or two connection intervals. Maybe this causes some overflow in windows systems. I would like to know
what are the implications of choosing a number of Tx buffers and pending buffers.

It will be helpful if anyone can tell how to choose the number of Tx buffers? or even point to some direction in the BLE specification?

Thank you,
Dhananjay G J

2441 - 2460 of 7600