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 !!
>
>

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.
> >
> >
> >

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