Date   

Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Kai Ren
 

Yes, I had to increate both stacks’ size, current configuration is:

CONFIG_MAIN_STACK_SIZE=640 (from 512)

CONFIG_BT_RX_STACK_SIZE=1450 (from 1100)

 

 

Regards,

Kai

 

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Monday, March 26, 2018 5:19 PM
To: Kai Ren <kren@...>; Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: RE: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Thanks Kai. Glad to know you have PB-GATT sans micro:bit display, working.

 

Did you have to increase the STACK_SIZE(s)? if so, which ones?

 

Regards,

Vinayak

 

From: Kai Ren [mailto:kren@...]
Sent: Sunday, March 25, 2018 3:36 PM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Vinayak,

 

I followed your instruction to disable some features above Bluetooth core spec v4.0, like 4.1, 4.2 and 5.0 as follow:

 

#Controller

#5.0 features

CONFIG_BT_CTLR_PHY=n

CONFIG_BT_CTLR_CHAN_SEL_2=n

CONFIG_BT_CTLR_MIN_USED_CHAN=n

CONFIG_BT_CTLR_ADV_EXT=n

CONFIG_BT_CTLR_PHY_2M=n

 

#4.2 features

CONFIG_BT_CTLR_DATA_LENGTH=n

CONFIG_BT_CTLR_DATA_LENGTH_MAX=27

CONFIG_BT_CTLR_PRIVACY=n

CONFIG_BT_CTLR_EXT_SCAN_FP=n

 

 

#4.1 features

CONFIG_BT_CTLR_CONN_PARAM_REQ=n

CONFIG_BT_CTLR_LE_PING=n

 

With this kind of configuration, there are 56 bytes saving, but it’s still not enough for me to squeeze the firmware into RAM. In order to make it happen, made some changes:

  • Delete Generic Level server from root models;
  • Delete Health server from root models;
  • disable CONFIG_MICROBIT_DISPLAY to save some RAM bytes, but OOB number display on LED matrix is sacrificed, MUST use com port to print OOB number like nRF 5x boards;

 

After above configuration, the RAM usage is 99.32% and I can:

  • use BlueZ v5.49 to provision the micro:bit by PB-GATT;
  • use meshctl to control LED matrix on and off by Generic OnOff server set command;  

 

Thank you for the help!

 

Regards,

Kai

 

 

 

From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...>
Date: Friday, 23 March 2018 at 10:58 PM
To: Kai Ren <kren@...>, Johan Hedberg <johan.hedberg@...>
Cc: "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Ken,

 

As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM.

But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.

 

That said, please increase these:

CONFIG_MAIN_STACK_SIZE

CONFIG_BT_RX_STACK_SIZE

 

… provided you can find some free RAM space!

 

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM
To: Johan Hedberg <
johan.hedberg@...>
Cc:
zephyr-devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Johan,

Thank you for the proposal, I've tested it.

I copied microbit_gatt.conf  and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below.

OOB Number: 549

***** HARD FAULT *****

  Executing thread ID (thread): 0x20001670

  Faulting instruction address:  0x200014dc

Fatal fault in ISR! Spinning...

 

 

I guess that there may be two causes:

  • RAM reach to limit, 99.93% is not safe for application even if it’s passed build phase;
  • CONFIG_BT_L2CAP_TX_BUF_COUNT is too small to fit the provisioning process.

So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.

 

 

Regards,

Kai

 

 

 

On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:

 

    Hi Kai,

   

    On Thu, Mar 22, 2018, Kai Ren wrote:

    > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that

    > current source code for micro:bit just support PB-ADV, don’t support

    > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really

    > hard to pass the build process because it runs out of RAM if I

    > modified prj_bbc_microbit.conf.

    > Meanwhile, I also found that there is a configuration flag,

    > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so

    > I’m just curious that what function does this flag provide? And is it

    > necessary for PB-GATT on micro:bit?  Thanks!

   

    There's actually a samples/bluetooth/mesh/microbit_gatt.conf

    configuration that's intended to be used for a GATT-based build of the

    mesh sample. That said, I just tried it and it actually overflows the

    RAM by 300 bytes. That's much less than 2k however, and hopefully easily

    to fix. Looking into it now. It might e.g. be possible that the

    CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was

    recently an extra segmentation buffer introduced for outgoing ACL

    packets.

   

    Note: you can select microbit_gatt.conf e.g. by passing the following

    to cmake: -DCONF_FILE=microbit_gatt.conf

   

    Johan

   


Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Chettimada, Vinayak Kariappa
 

Thanks Kai. Glad to know you have PB-GATT sans micro:bit display, working.

 

Did you have to increase the STACK_SIZE(s)? if so, which ones?

 

Regards,

Vinayak

 

From: Kai Ren [mailto:kren@...]
Sent: Sunday, March 25, 2018 3:36 PM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Vinayak,

 

I followed your instruction to disable some features above Bluetooth core spec v4.0, like 4.1, 4.2 and 5.0 as follow:

 

#Controller

#5.0 features

CONFIG_BT_CTLR_PHY=n

CONFIG_BT_CTLR_CHAN_SEL_2=n

CONFIG_BT_CTLR_MIN_USED_CHAN=n

CONFIG_BT_CTLR_ADV_EXT=n

CONFIG_BT_CTLR_PHY_2M=n

 

#4.2 features

CONFIG_BT_CTLR_DATA_LENGTH=n

CONFIG_BT_CTLR_DATA_LENGTH_MAX=27

CONFIG_BT_CTLR_PRIVACY=n

CONFIG_BT_CTLR_EXT_SCAN_FP=n

 

 

#4.1 features

CONFIG_BT_CTLR_CONN_PARAM_REQ=n

CONFIG_BT_CTLR_LE_PING=n

 

With this kind of configuration, there are 56 bytes saving, but it’s still not enough for me to squeeze the firmware into RAM. In order to make it happen, made some changes:

  • Delete Generic Level server from root models;
  • Delete Health server from root models;
  • disable CONFIG_MICROBIT_DISPLAY to save some RAM bytes, but OOB number display on LED matrix is sacrificed, MUST use com port to print OOB number like nRF 5x boards;

 

After above configuration, the RAM usage is 99.32% and I can:

  • use BlueZ v5.49 to provision the micro:bit by PB-GATT;
  • use meshctl to control LED matrix on and off by Generic OnOff server set command;  

 

Thank you for the help!

 

Regards,

Kai

 

 

 

From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...>
Date: Friday, 23 March 2018 at 10:58 PM
To: Kai Ren <kren@...>, Johan Hedberg <johan.hedberg@...>
Cc: "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Ken,

 

As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM.

But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.

 

That said, please increase these:

CONFIG_MAIN_STACK_SIZE

CONFIG_BT_RX_STACK_SIZE

 

… provided you can find some free RAM space!

 

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM
To: Johan Hedberg <
johan.hedberg@...>
Cc:
zephyr-devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Johan,

Thank you for the proposal, I've tested it.

I copied microbit_gatt.conf  and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below.

OOB Number: 549

***** HARD FAULT *****

  Executing thread ID (thread): 0x20001670

  Faulting instruction address:  0x200014dc

Fatal fault in ISR! Spinning...

 

 

I guess that there may be two causes:

  • RAM reach to limit, 99.93% is not safe for application even if it’s passed build phase;
  • CONFIG_BT_L2CAP_TX_BUF_COUNT is too small to fit the provisioning process.

So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.

 

 

Regards,

Kai

 

 

 

On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:

 

    Hi Kai,

   

    On Thu, Mar 22, 2018, Kai Ren wrote:

    > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that

    > current source code for micro:bit just support PB-ADV, don’t support

    > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really

    > hard to pass the build process because it runs out of RAM if I

    > modified prj_bbc_microbit.conf.

    > Meanwhile, I also found that there is a configuration flag,

    > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so

    > I’m just curious that what function does this flag provide? And is it

    > necessary for PB-GATT on micro:bit?  Thanks!

   

    There's actually a samples/bluetooth/mesh/microbit_gatt.conf

    configuration that's intended to be used for a GATT-based build of the

    mesh sample. That said, I just tried it and it actually overflows the

    RAM by 300 bytes. That's much less than 2k however, and hopefully easily

    to fix. Looking into it now. It might e.g. be possible that the

    CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was

    recently an extra segmentation buffer introduced for outgoing ACL

    packets.

   

    Note: you can select microbit_gatt.conf e.g. by passing the following

    to cmake: -DCONF_FILE=microbit_gatt.conf

   

    Johan

   


What is need of addition authentication in case of #BluetoothMesh if ECDH public key exchanged over OOB ? #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi, 

If #BluetoothMesh DEVICE ECDH-public key (oob public key) is exchanged over OOB channel then what is further need of authentication using input-OOB or output-OOB or static-OOB ?

Thanks,


Re: How hacker will hack/impact my BLE device, when ...??

Vikrant More <vikrant8051@...>
 

Hi,
I think we can do OOB pairing, even if Device doesn't have display to share Passkey with user App.

1. Create ECDH public-private key pair (only once in Device life)
2. Read ECDH-Public key via Device serial terminal. Create QR code from it & add it in Device packaging.

3. User will scan it with APP & APP will transfer own dynamically created public key over BLE link.
4. Shared secret will created on both side which can be used to encrypt further communication.

Thanks,
vikrant8051



On Wed, Mar 21, 2018 at 9:13 PM, Vikrant More <vikrant8051@...> wrote:
Hi,
https://eewiki.net/display/Wireless/A+Basic+Introduction+to+BLE+Security

MITM attacks are when a third device, which we will call the malicious device, impersonates the other two legitimate devices, in order to fool these devices into connecting to it. In this scenario, both the GAP Central and GAP Peripheral will connect to the malicious device which in turn routes the communication between the two other devices. This gives the legitimate devices the illusion that they are directly connected to each other when in fact their connection has been compromised. This setup not only allows the malicious device to intercept all the data being sent, but also allows it to inject false data into the communication or remove data before it reaches its intended recipient.

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

After reading this, I understand that without OOB Pairing everything is more or less insecure.


On Wed, Mar 21, 2018 at 7:04 PM, Marcio Montenegro <mtuxpe@...> wrote:
Google Secure beacons.No new hardware design :
https://developers.google.com/beacons/eddystone-eid

Regards,
Marcio


On Wed, Mar 21, 2018 at 10:15 AM, Vikrant More <vikrant8051@...> wrote:
Hi Marcio,
I'm not allowed to add anything extra in my current hardware design.

Besides this, is there any thing which is very serious ?
I'm still trying to understand various security risk behind my current implementation.

Thanks,
 

On Wed, Mar 21, 2018 at 5:35 PM, Marcio Montenegro <mtuxpe@...> wrote:
Hi all,
Maybe you can use crypto device on your product.


You also need to develop an application to configure  crypto device chip.
Then after configuration each device are unique.
For inspiration see:

Note that this devices has no Bluetooth.
Best,
Marcio


On Wed, Mar 21, 2018 at 2:08 AM, Vakul Garg <vakul.garg@...> wrote:

Hi Vikrant

 

I am curious to understand about your security implementation.

I work in area of TLS security and I am not bluetooth security expert.

 

In your case, does the app need to differentiate between a genuine or fake device?

Will it be able to create a shared secret with the device even if it is a clone of genuine device and purpose programmed to leak the common encryption key?

 

Regards

 

Vakul

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Vikrant More
Sent: Tuesday, March 20, 2018 11:28 PM
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] How hacker will hack/impact my BLE device, when ...??

 

Hi,

 

In my current project, I haven't implemented OOB pairing ( BLE based smart lights)

 

Using Zephyr built-in ECDH library, shared secret (using secp256r1 curve) get created on Device as well as on APP side which will act like encryption key for further communication.

 

On that encrypted link, APP send encryption key which is common for all devices associated with it.

 

All this happens when DEVICE is in factory reset mode.

 

There after communication link is encrypted using newly assign common key.

 

..................................................................................….........................................

 

This will create security risk, only if device is not authenticated by user & it could transfer security key ( which is common to many devices) to unauthorized device.

 

To solve this, APP will automatically trigger DEVICE's LEDs to blink & ask user "do you see blinking LED?" 

 

If user click on "YES" then & only then ECDH process will initiate & common key get share with new DEVICE.

 

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

 

Besides this I didn't found any security flaw in this implementation. So I need help from Bluetooth Security expert. Is there anyone who can help me to find out flaws & security risks in my current implementation ?

 

Thanks,

vikrant8051


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







Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Kai Ren
 

Hi Vinayak,

 

I followed your instruction to disable some features above Bluetooth core spec v4.0, like 4.1, 4.2 and 5.0 as follow:

 

#Controller

#5.0 features

CONFIG_BT_CTLR_PHY=n

CONFIG_BT_CTLR_CHAN_SEL_2=n

CONFIG_BT_CTLR_MIN_USED_CHAN=n

CONFIG_BT_CTLR_ADV_EXT=n

CONFIG_BT_CTLR_PHY_2M=n

 

#4.2 features

CONFIG_BT_CTLR_DATA_LENGTH=n

CONFIG_BT_CTLR_DATA_LENGTH_MAX=27

CONFIG_BT_CTLR_PRIVACY=n

CONFIG_BT_CTLR_EXT_SCAN_FP=n

 

 

#4.1 features

CONFIG_BT_CTLR_CONN_PARAM_REQ=n

CONFIG_BT_CTLR_LE_PING=n

 

With this kind of configuration, there are 56 bytes saving, but it’s still not enough for me to squeeze the firmware into RAM. In order to make it happen, made some changes:

  • Delete Generic Level server from root models;
  • Delete Health server from root models;
  • disable CONFIG_MICROBIT_DISPLAY to save some RAM bytes, but OOB number display on LED matrix is sacrificed, MUST use com port to print OOB number like nRF 5x boards;

 

After above configuration, the RAM usage is 99.32% and I can:

  • use BlueZ v5.49 to provision the micro:bit by PB-GATT;
  • use meshctl to control LED matrix on and off by Generic OnOff server set command;  

 

Thank you for the help!

 

Regards,

Kai

 

 

 

From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...>
Date: Friday, 23 March 2018 at 10:58 PM
To: Kai Ren <kren@...>, Johan Hedberg <johan.hedberg@...>
Cc: "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Ken,

 

As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM.

But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.

 

That said, please increase these:

CONFIG_MAIN_STACK_SIZE

CONFIG_BT_RX_STACK_SIZE

 

… provided you can find some free RAM space!

 

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Johan,

Thank you for the proposal, I've tested it.

I copied microbit_gatt.conf  and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below.

OOB Number: 549

***** HARD FAULT *****

  Executing thread ID (thread): 0x20001670

  Faulting instruction address:  0x200014dc

Fatal fault in ISR! Spinning...

 

 

I guess that there may be two causes:

  • RAM reach to limit, 99.93% is not safe for application even if it’s passed build phase;
  • CONFIG_BT_L2CAP_TX_BUF_COUNT is too small to fit the provisioning process.

So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.

 

 

Regards,

Kai

 

 

 

On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:

 

    Hi Kai,

   

    On Thu, Mar 22, 2018, Kai Ren wrote:

    > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that

    > current source code for micro:bit just support PB-ADV, don’t support

    > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really

    > hard to pass the build process because it runs out of RAM if I

    > modified prj_bbc_microbit.conf.

    > Meanwhile, I also found that there is a configuration flag,

    > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so

    > I’m just curious that what function does this flag provide? And is it

    > necessary for PB-GATT on micro:bit?  Thanks!

   

    There's actually a samples/bluetooth/mesh/microbit_gatt.conf

    configuration that's intended to be used for a GATT-based build of the

    mesh sample. That said, I just tried it and it actually overflows the

    RAM by 300 bytes. That's much less than 2k however, and hopefully easily

    to fix. Looking into it now. It might e.g. be possible that the

    CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was

    recently an extra segmentation buffer introduced for outgoing ACL

    packets.

   

    Note: you can select microbit_gatt.conf e.g. by passing the following

    to cmake: -DCONF_FILE=microbit_gatt.conf

   

    Johan

   


Board Config Files

Justin
 

I'm attempting to port over a custom board (NRF52832) and I'm a little confused by which config files are still being used (CMAKE build).

Should I be putting my configurations in <board>_defconfig, KConfig* files or both?  Or should I just be using device tree files now?

Thanks,
Justin 


Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Chettimada, Vinayak Kariappa
 

Hi Ken,

 

As the faulting instruction address is in RAM, I suspect an overflow of some thread call stack. The PB-GATT may not have been tested on micro:bit due to restricted amount of RAM.

But, please review the Kconfig option for the controller (me being the maintainer of controller) in menuconfig and disable any options that will not be needed for your usecase, like disabling 4.1 and above features and reducing any buffer counts.

 

That said, please increase these:

CONFIG_MAIN_STACK_SIZE

CONFIG_BT_RX_STACK_SIZE

 

… provided you can find some free RAM space!

 

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

 

Hi Johan,

Thank you for the proposal, I've tested it.

I copied microbit_gatt.conf  and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below.

OOB Number: 549

***** HARD FAULT *****

  Executing thread ID (thread): 0x20001670

  Faulting instruction address:  0x200014dc

Fatal fault in ISR! Spinning...

 

 

I guess that there may be two causes:

  • RAM reach to limit, 99.93% is not safe for application even if it’s passed build phase;
  • CONFIG_BT_L2CAP_TX_BUF_COUNT is too small to fit the provisioning process.

So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.

 

 

Regards,

Kai

 

 

 

On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:

 

    Hi Kai,

   

    On Thu, Mar 22, 2018, Kai Ren wrote:

    > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that

    > current source code for micro:bit just support PB-ADV, don’t support

    > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really

    > hard to pass the build process because it runs out of RAM if I

    > modified prj_bbc_microbit.conf.

    > Meanwhile, I also found that there is a configuration flag,

    > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so

    > I’m just curious that what function does this flag provide? And is it

    > necessary for PB-GATT on micro:bit?  Thanks!

   

    There's actually a samples/bluetooth/mesh/microbit_gatt.conf

    configuration that's intended to be used for a GATT-based build of the

    mesh sample. That said, I just tried it and it actually overflows the

    RAM by 300 bytes. That's much less than 2k however, and hopefully easily

    to fix. Looking into it now. It might e.g. be possible that the

    CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was

    recently an extra segmentation buffer introduced for outgoing ACL

    packets.

   

    Note: you can select microbit_gatt.conf e.g. by passing the following

    to cmake: -DCONF_FILE=microbit_gatt.conf

   

    Johan

   


Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Kai Ren
 

Hi Johan,

Thank you for the proposal, I've tested it.

I copied microbit_gatt.conf  and reduced CONFIG_BT_L2CAP_TX_BUF_COUNT to 2, RAM usage is 99.93%, which can make it fit micro:bit RAM size, but when I use BlueZ to provision it, after OOB output on micro:bit, it seems to be corrupted, a HARD FAULT as below.

OOB Number: 549

***** HARD FAULT *****

  Executing thread ID (thread): 0x20001670

  Faulting instruction address:  0x200014dc

Fatal fault in ISR! Spinning...

 

 

I guess that there may be two causes:

  • RAM reach to limit, 99.93% is not safe for application even if it’s passed build phase;
  • CONFIG_BT_L2CAP_TX_BUF_COUNT is too small to fit the provisioning process.

So, I have a question that can I enable optimization level for source code compiling? I had used Keil or IAR, their GUI support to configure optimization level, but how can I configure it on Zephyr? I hope it may save some valuable bytes in RAM of micro:bit.

 

 

Regards,

Kai

 

 

On 22/03/2018, 11:39 PM, "Johan Hedberg" <johan.hedberg@...> wrote:

 

    Hi Kai,

   

    On Thu, Mar 22, 2018, Kai Ren wrote:

    > I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that

    > current source code for micro:bit just support PB-ADV, don’t support

    > PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really

    > hard to pass the build process because it runs out of RAM if I

    > modified prj_bbc_microbit.conf.

    > Meanwhile, I also found that there is a configuration flag,

    > CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so

    > I’m just curious that what function does this flag provide? And is it

    > necessary for PB-GATT on micro:bit?  Thanks!

   

    There's actually a samples/bluetooth/mesh/microbit_gatt.conf

    configuration that's intended to be used for a GATT-based build of the

    mesh sample. That said, I just tried it and it actually overflows the

    RAM by 300 bytes. That's much less than 2k however, and hopefully easily

    to fix. Looking into it now. It might e.g. be possible that the

    CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was

    recently an extra segmentation buffer introduced for outgoing ACL

    packets.

   

    Note: you can select microbit_gatt.conf e.g. by passing the following

    to cmake: -DCONF_FILE=microbit_gatt.conf

   

    Johan

   


Re: Firmware over the air (FOTA) and FCB support in 1.11.0

laczenJMS
 

Hi Carles,

I will add the lifetime calculation to the documentation of NVS.

Regarding the comparison between FCB and NVS: FCB would need an
additional layer to be able to get this functionality (which is the
config layer). The following decisions are influencing flash wear:

1. Config system: store name-value pairs as strings: this makes the
difference between 10 bytes and 26 bytes (should really be 27 because
I forgot the zero termination).
2. FCB storage: use of scratch sector this reduces the lifetime to the
amount of scratch sector erases.

Decision 1 will reduce life with a factor 2.6, Decision 2 will reduce
life with at least a factor 2.

Kind regards,

Jehudi

Date: Thu, 22 Mar 2018 15:27:23 +0000
From: "Cufi, Carles" <Carles.Cufi@nordicsemi.no>
To: Laczen JMS <laczenjms@gmail.com>,
"zephyr-devel@lists.zephyrproject.org"
<zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB
support in 1.11.0
Message-ID: <26729c68a51f4a9087156a98f53f9eee@nordicsemi.no>
Content-Type: text/plain; charset="us-ascii"

Hi Jehudi,

Thanks for all the info, maybe you could post this in the NVS PR.

Additionally, you compared Config+FCB with NVS accessed directly. Since the first item we need to decide on is actually whether we "augment" FCB with some of the NVS code or we add NVS as a separate subsystem, a very interesting comparison would be to have a real-life RAM and Flash usage comparison of FCB and NVS both being accessed directly, if possible for BLE Mesh data since that is the main target of NVS right now. How much worse off would we be if we used FCB as it stands today instead of NVS?

Thanks,

Carles

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-
bounces@lists.zephyrproject.org> On Behalf Of Laczen JMS
Sent: 22 March 2018 14:01
To: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB support
in 1.11.0

Hi,

As the author of NVS (PR6391
https://github.com/zephyrproject-rtos/zephyr/pull/6391) I am probably a
bit biased. NVS as is can be used directly for managing persistent data.
I am looking into adding NVS as a backend to the configuration system,
but the configuration system comes with a major drawback:
flash usage.

I did a little calculation to compare the configuration system with FCB
as backend to direct use of NVS. Lets make the following
assumptions: Device is nrf51822, flash erase size is 1k, flash erase
cycles is 20000. Flash available for storage is 2k (2 pages). Data
without the sequence number takes up 512 bytes so 512 bytes is available
to store the sequence number.

Now lets see what happens when storing the sequence number, we will only
store it after 8192 messages (this means we only need to store a
11 bit number). This number can be increased but will reduce the number
of reboots that are allowed (to keep the IV index from changing to
fast). The worst case scenario is 24.3 messages/s (see nordicsemi mesh-
sdk).

Calculation for the config system: each store of the sequence number is
a string looking like:
"bt/btmesh/seq=XXXX" which takes up 18 bytes. FCB overhead takes another
8 bytes, so in total 26 bytes for a write of the sequence number. After
19 (512/26) writes a sector is full and it will be erased (using a 1K
scratch sector). So with the worst case of 24.3
messages/s: after 19 * 8192 /24.3 s a sector will be erased. Or every
1.78 h. With the erase cycles of 20000 flash will be worn out after
about 4 years.

Calculation for NVS: the sequence number is given an id for storage.
This id is used to differentiate between other data that is stored (and
is part of the NVS overhead). The sequence number takes up only 2 bytes.
NVS overhead takes up 8 bytes, so in total 10 bytes for a write. After
51 (512/10) messages the first page (1k) is full and the second page is
taken into use. After 51 messages the second sector is full and the
first page is erased. So after 102 messages the same page is erased.
With the erase cycle of 20000 flash will be worn out after about 21.5
years.

Modifying the above assumptions should allow you to get an estimate of
the expected life of your specific application.

To summarize: the configuration system comes at a price, the use of
human readable strings as storage items takes up more space, and reduces
the life of the device.

I am currently working on a solution for the configuration system that
would use NVS as a backend but would also allow some data to be directly
written to NVS. This would allow combination of human readability for
some data with reduced flash wear for other. But the human readability
will always take up more space.

Kind regards,

Jehudi
Message: 1
Date: Wed, 21 Mar 2018 14:02:39 -0700
From: Michael Scott <michael@opensourcefoundries.com>
To: Vikrant More <vikrant8051@gmail.com>
Cc: zephyr-users@lists.zephyrproject.org,
zephyr-devel@lists.zephyrproject.org,
"ashish.shukla@corvi.com"
<ashish.shukla@corvi.com>
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB
support in 1.11.0
Message-ID:
<7d94daad-9272-4517-f236-50255c352f00@opensourcefoundries.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"



On 03/21/2018 10:09 AM, Vikrant More wrote:
Hi,
Regarding FCB: the initial implementation is done in v1.11, but
the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage
persistent data such as device configuration, system logs and other
uses.
There are several pull requests in-progress which aim to add these
higher level services.? (The first PR will probably be re-written to
use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Are these PRs, suitable to save #BluetoothMesh's Sequence Numbers on
flash which updates frequently ?
IIRC, the idea is to settle on 1 solution which would be appropriate
for most use-cases (including Mesh Sequence Numbers).?? You might want
to have 2 separate storage locations if you have data that only
updates occasionally *and* data that updates frequently.

The guys from Nordic (and possibly Johan) are looking at this issue as
well.

- Mike


Thanks,


On Wed, Mar 21, 2018 at 9:59 PM, Michael Scott
<michael@opensourcefoundries.com
<mailto:michael@opensourcefoundries.com>> wrote:



On 03/20/2018 09:14 PM, ashish.shukla@corvi.com
<mailto:ashish.shukla@corvi.com> wrote:
Hi all,

I've been waiting for FOTA and FCB support in zephyr and now
when
it is supported, I cannot see any samples available or proper
documentation to use these features in my project.
Hi Ashish,

Your question is a bit open-ended, and might be difficult to
answer without some details regarding your paricular use-case
(BLE
update, IP-based update, Mesh, etc)

For instance, the LwM2M subsystem provides a mechanism for
receiving a firmware update in the LwM2M client, but the
implementation of where to store the incoming binary data is up
to
you.? See
https://github.com/zephyrproject-
rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208
<https://github.com/zephyrproject-
rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-
client.c#L208>
for a callback example that is triggered on each incoming block
of
data.? Documentation for the sample itself doesn't discuss the
firmware update mechanism, but it's here for reference:
http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html

<http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html>

Then, there is a robust DFU (Device Firmware Update) subsystem to
help implement the image writing portion of a firmware update as
well as integrate with mcuboot (an MCU bootloader) which would
check an image for validity and then move it into the bootable
application slot. ? See:
https://github.com/zephyrproject-
rtos/zephyr/tree/master/subsys/dfu
<https://github.com/zephyrproject-
rtos/zephyr/tree/master/subsys/dfu>
for sources.

Regarding FCB: the initial implementation is done in v1.11, but
the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage
persistent data such as device configuration, system logs and
other uses.? There are several pull requests in-progress which
aim
to add these higher level services.? (The first PR will probably
be re-written to use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Hopefully that helps get you started,

- Mike


Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com <http://www.corvi.com/>


Please consider the environment before printing this e-mail or
its attachments.

Disclaimer: The information contained herein (including any
accompanying documents) is confidential and is intended solely
for the addressee(s). If you have erroneously received this
message, please immediately delete it and notify the sender.
Also, if you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or taking
any
action in reliance on the contents of this message or any
accompanying document is strictly prohibited and is unlawful.
The
organization is not responsible for any damage caused by a virus
or alteration of the e-mail by a third party or otherwise. The
contents of this message may not necessarily represent the views
or policies of Corvi



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

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

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


Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Johan Hedberg
 

Hi Kai,

On Thu, Mar 22, 2018, Kai Ren wrote:
Meanwhile, I also found that there is a configuration flag,
CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so
I’m just curious that what function does this flag provide? And is it
necessary for PB-GATT on micro:bit?
I forgot to answer your question regarding CONFIG_BT_PERIPHERAL: it
enables support for the Peripheral GAP role, which is definitely
something you need to have a GATT server for PB-GATT and GATT Proxy.

Johan


Re: [Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Johan Hedberg
 

Hi Kai,

On Thu, Mar 22, 2018, Kai Ren wrote:
I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that
current source code for micro:bit just support PB-ADV, don’t support
PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really
hard to pass the build process because it runs out of RAM if I
modified prj_bbc_microbit.conf.
Meanwhile, I also found that there is a configuration flag,
CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so
I’m just curious that what function does this flag provide? And is it
necessary for PB-GATT on micro:bit? Thanks!
There's actually a samples/bluetooth/mesh/microbit_gatt.conf
configuration that's intended to be used for a GATT-based build of the
mesh sample. That said, I just tried it and it actually overflows the
RAM by 300 bytes. That's much less than 2k however, and hopefully easily
to fix. Looking into it now. It might e.g. be possible that the
CONFIG_BT_L2CAP_TX_BUF_COUNT=5 variable can be lowered since there was
recently an extra segmentation buffer introduced for outgoing ACL
packets.

Note: you can select microbit_gatt.conf e.g. by passing the following
to cmake: -DCONF_FILE=microbit_gatt.conf

Johan


Re: Firmware over the air (FOTA) and FCB support in 1.11.0

Carles Cufi
 

Hi Jehudi,

Thanks for all the info, maybe you could post this in the NVS PR.

Additionally, you compared Config+FCB with NVS accessed directly. Since the first item we need to decide on is actually whether we "augment" FCB with some of the NVS code or we add NVS as a separate subsystem, a very interesting comparison would be to have a real-life RAM and Flash usage comparison of FCB and NVS both being accessed directly, if possible for BLE Mesh data since that is the main target of NVS right now. How much worse off would we be if we used FCB as it stands today instead of NVS?

Thanks,

Carles

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-
bounces@lists.zephyrproject.org> On Behalf Of Laczen JMS
Sent: 22 March 2018 14:01
To: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB support
in 1.11.0

Hi,

As the author of NVS (PR6391
https://github.com/zephyrproject-rtos/zephyr/pull/6391) I am probably a
bit biased. NVS as is can be used directly for managing persistent data.
I am looking into adding NVS as a backend to the configuration system,
but the configuration system comes with a major drawback:
flash usage.

I did a little calculation to compare the configuration system with FCB
as backend to direct use of NVS. Lets make the following
assumptions: Device is nrf51822, flash erase size is 1k, flash erase
cycles is 20000. Flash available for storage is 2k (2 pages). Data
without the sequence number takes up 512 bytes so 512 bytes is available
to store the sequence number.

Now lets see what happens when storing the sequence number, we will only
store it after 8192 messages (this means we only need to store a
11 bit number). This number can be increased but will reduce the number
of reboots that are allowed (to keep the IV index from changing to
fast). The worst case scenario is 24.3 messages/s (see nordicsemi mesh-
sdk).

Calculation for the config system: each store of the sequence number is
a string looking like:
"bt/btmesh/seq=XXXX" which takes up 18 bytes. FCB overhead takes another
8 bytes, so in total 26 bytes for a write of the sequence number. After
19 (512/26) writes a sector is full and it will be erased (using a 1K
scratch sector). So with the worst case of 24.3
messages/s: after 19 * 8192 /24.3 s a sector will be erased. Or every
1.78 h. With the erase cycles of 20000 flash will be worn out after
about 4 years.

Calculation for NVS: the sequence number is given an id for storage.
This id is used to differentiate between other data that is stored (and
is part of the NVS overhead). The sequence number takes up only 2 bytes.
NVS overhead takes up 8 bytes, so in total 10 bytes for a write. After
51 (512/10) messages the first page (1k) is full and the second page is
taken into use. After 51 messages the second sector is full and the
first page is erased. So after 102 messages the same page is erased.
With the erase cycle of 20000 flash will be worn out after about 21.5
years.

Modifying the above assumptions should allow you to get an estimate of
the expected life of your specific application.

To summarize: the configuration system comes at a price, the use of
human readable strings as storage items takes up more space, and reduces
the life of the device.

I am currently working on a solution for the configuration system that
would use NVS as a backend but would also allow some data to be directly
written to NVS. This would allow combination of human readability for
some data with reduced flash wear for other. But the human readability
will always take up more space.

Kind regards,

Jehudi
Message: 1
Date: Wed, 21 Mar 2018 14:02:39 -0700
From: Michael Scott <michael@opensourcefoundries.com>
To: Vikrant More <vikrant8051@gmail.com>
Cc: zephyr-users@lists.zephyrproject.org,
zephyr-devel@lists.zephyrproject.org,
"ashish.shukla@corvi.com"
<ashish.shukla@corvi.com>
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB
support in 1.11.0
Message-ID:
<7d94daad-9272-4517-f236-50255c352f00@opensourcefoundries.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"



On 03/21/2018 10:09 AM, Vikrant More wrote:
Hi,
Regarding FCB: the initial implementation is done in v1.11, but
the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage
persistent data such as device configuration, system logs and other
uses.
There are several pull requests in-progress which aim to add these
higher level services.? (The first PR will probably be re-written to
use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Are these PRs, suitable to save #BluetoothMesh's Sequence Numbers on
flash which updates frequently ?
IIRC, the idea is to settle on 1 solution which would be appropriate
for most use-cases (including Mesh Sequence Numbers).?? You might want
to have 2 separate storage locations if you have data that only
updates occasionally *and* data that updates frequently.

The guys from Nordic (and possibly Johan) are looking at this issue as
well.

- Mike


Thanks,


On Wed, Mar 21, 2018 at 9:59 PM, Michael Scott
<michael@opensourcefoundries.com
<mailto:michael@opensourcefoundries.com>> wrote:



On 03/20/2018 09:14 PM, ashish.shukla@corvi.com
<mailto:ashish.shukla@corvi.com> wrote:
Hi all,

I've been waiting for FOTA and FCB support in zephyr and now
when
it is supported, I cannot see any samples available or proper
documentation to use these features in my project.
Hi Ashish,

Your question is a bit open-ended, and might be difficult to
answer without some details regarding your paricular use-case
(BLE
update, IP-based update, Mesh, etc)

For instance, the LwM2M subsystem provides a mechanism for
receiving a firmware update in the LwM2M client, but the
implementation of where to store the incoming binary data is up
to
you.? See
https://github.com/zephyrproject-
rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208
<https://github.com/zephyrproject-
rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-
client.c#L208>
for a callback example that is triggered on each incoming block
of
data.? Documentation for the sample itself doesn't discuss the
firmware update mechanism, but it's here for reference:
http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html

<http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html>

Then, there is a robust DFU (Device Firmware Update) subsystem to
help implement the image writing portion of a firmware update as
well as integrate with mcuboot (an MCU bootloader) which would
check an image for validity and then move it into the bootable
application slot. ? See:
https://github.com/zephyrproject-
rtos/zephyr/tree/master/subsys/dfu
<https://github.com/zephyrproject-
rtos/zephyr/tree/master/subsys/dfu>
for sources.

Regarding FCB: the initial implementation is done in v1.11, but
the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage
persistent data such as device configuration, system logs and
other uses.? There are several pull requests in-progress which
aim
to add these higher level services.? (The first PR will probably
be re-written to use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Hopefully that helps get you started,

- Mike


Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com <http://www.corvi.com/>


Please consider the environment before printing this e-mail or
its attachments.

Disclaimer: The information contained herein (including any
accompanying documents) is confidential and is intended solely
for the addressee(s). If you have erroneously received this
message, please immediately delete it and notify the sender.
Also, if you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or taking
any
action in reliance on the contents of this message or any
accompanying document is strictly prohibited and is unlawful.
The
organization is not responsible for any damage caused by a virus
or alteration of the e-mail by a third party or otherwise. The
contents of this message may not necessarily represent the views
or policies of Corvi



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

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

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


[Bluetooth mesh]CONFIG_BT_PERIPHERAL, what does it mean?

Kai Ren
 

Hello,

I’m try to run ./sample/Bluetooth/mesh/ on micro:bit, I found that current source code for micro:bit just support PB-ADV, don’t support PB-GATT. So, I want to add PB-GATT on it, but I found that it’s really hard to pass the build process because it runs out of RAM if I modified prj_bbc_microbit.conf.  

Meanwhile, I also found that there is a configuration flag, CONFIG_BT_PERIPHERAL, it consumes about 2KB RAM when I enable it, so I’m just curious that what function does this flag provide? And is it necessary for PB-GATT on micro:bit?

Thanks!

 

 

Kai Ren

Developer Relation Manager, APAC  |  Bluetooth Special Interest Group, Inc.

o: +86 13564372135    |  www.bluetooth.com

微博:weibo.com/bluetoothsig  微信:kaiser-tech

 

CONFIDENTIAL: This email message and any information attached to it may contain confidential information that is legally privileged. Any unauthorized disclosure, use, copying, or distribution is strictly prohibited. If you are not the intended recipient, please notify the Author and destroy the original transmission without reading or saving. Thank you.

 

 


Re: Firmware over the air (FOTA) and FCB support in 1.11.0

Johan Hedberg
 

Hi Jehudi,

That's some good analysis you've done. Note that this is for "frequent
sender" mesh nodes. For "requent receiver" nodes it's the Replay
Protection List (RPL) that will need to be updated frequently. What's
worse for the RPL is that you can't make similar jumps of 8192 messages,
rather you have to update the RPL for every message that the node
processes (note that relaying does not count as "processing" in this
sense).

The implications of failing to keep an updated Seq vs failing to keep an
updated RPL are similar, but not quite the same: in the case of the Seq,
you end up in a situation where other nodes ignore packets from you,
since they think someone is doing a replay attack with old seq values.
In the case of not updating the RPL it's the local node that gets
exposed to potential replay attacks.

Johan

On Thu, Mar 22, 2018, Laczen JMS wrote:
Hi,

As the author of NVS (PR6391
https://github.com/zephyrproject-rtos/zephyr/pull/6391) I am probably
a bit biased. NVS as is can be used directly for managing persistent
data. I am looking into adding NVS as a backend to the configuration
system, but the configuration system comes with a major drawback:
flash usage.

I did a little calculation to compare the configuration system with
FCB as backend to direct use of NVS. Lets make the following
assumptions: Device is nrf51822, flash erase size is 1k, flash erase
cycles is 20000. Flash available for storage is 2k (2 pages). Data
without the sequence number takes up 512 bytes so 512 bytes is
available to store the sequence number.

Now lets see what happens when storing the sequence number, we will
only store it after 8192 messages (this means we only need to store a
11 bit number). This number can be increased but will reduce the
number of reboots that are allowed (to keep the IV index from changing
to fast). The worst case scenario is 24.3 messages/s (see nordicsemi
mesh-sdk).

Calculation for the config system: each store of the sequence number
is a string looking like:
"bt/btmesh/seq=XXXX" which takes up 18 bytes. FCB overhead takes
another 8 bytes, so in total 26 bytes for a write of the sequence
number. After 19 (512/26) writes a sector is full and it will be
erased (using a 1K scratch sector). So with the worst case of 24.3
messages/s: after 19 * 8192 /24.3 s a sector will be erased. Or every
1.78 h. With the erase cycles of 20000 flash will be worn out after
about 4 years.

Calculation for NVS: the sequence number is given an id for storage.
This id is used to differentiate between other data that is stored
(and is part of the NVS overhead). The sequence number takes up only 2
bytes. NVS overhead takes up 8 bytes, so in total 10 bytes for a
write. After 51 (512/10) messages the first page (1k) is full and the
second page is taken into use. After 51 messages the second sector is
full and the first page is erased. So after 102 messages the same page
is erased. With the erase cycle of 20000 flash will be worn out after
about 21.5 years.

Modifying the above assumptions should allow you to get an estimate of
the expected life of your specific application.

To summarize: the configuration system comes at a price, the use of
human readable strings as storage items takes up more space, and
reduces the life of the device.

I am currently working on a solution for the configuration system that
would use NVS as a backend but would also allow some data to be
directly written to NVS. This would allow combination of human
readability for some data with reduced flash wear for other. But the
human readability will always take up more space.

Kind regards,

Jehudi
Message: 1
Date: Wed, 21 Mar 2018 14:02:39 -0700
From: Michael Scott <michael@opensourcefoundries.com>
To: Vikrant More <vikrant8051@gmail.com>
Cc: zephyr-users@lists.zephyrproject.org,
zephyr-devel@lists.zephyrproject.org, "ashish.shukla@corvi.com"
<ashish.shukla@corvi.com>
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB
support in 1.11.0
Message-ID:
<7d94daad-9272-4517-f236-50255c352f00@opensourcefoundries.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"



On 03/21/2018 10:09 AM, Vikrant More wrote:
Hi,
Regarding FCB: the initial implementation is done in v1.11,
but the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage persistent
data such as device configuration, system logs and other uses.
There are several pull requests in-progress which aim to add these
higher level services.? (The first PR will probably be re-written to
use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Are these PRs, suitable to save #BluetoothMesh's Sequence Numbers on
flash which updates frequently ?
IIRC, the idea is to settle on 1 solution which would be appropriate for
most use-cases (including Mesh Sequence Numbers).?? You might want to
have 2 separate storage locations if you have data that only updates
occasionally *and* data that updates frequently.

The guys from Nordic (and possibly Johan) are looking at this issue as well.

- Mike


Thanks,


On Wed, Mar 21, 2018 at 9:59 PM, Michael Scott
<michael@opensourcefoundries.com
<mailto:michael@opensourcefoundries.com>> wrote:



On 03/20/2018 09:14 PM, ashish.shukla@corvi.com
<mailto:ashish.shukla@corvi.com> wrote:
Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when
it is supported, I cannot see any samples available or proper
documentation to use these features in my project.
Hi Ashish,

Your question is a bit open-ended, and might be difficult to
answer without some details regarding your paricular use-case (BLE
update, IP-based update, Mesh, etc)

For instance, the LwM2M subsystem provides a mechanism for
receiving a firmware update in the LwM2M client, but the
implementation of where to store the incoming binary data is up to
you.? See
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208
<https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208>
for a callback example that is triggered on each incoming block of
data.? Documentation for the sample itself doesn't discuss the
firmware update mechanism, but it's here for reference:
http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html
<http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html>

Then, there is a robust DFU (Device Firmware Update) subsystem to
help implement the image writing portion of a firmware update as
well as integrate with mcuboot (an MCU bootloader) which would
check an image for validity and then move it into the bootable
application slot. ? See:
https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/dfu
<https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/dfu>
for sources.

Regarding FCB: the initial implementation is done in v1.11, but
the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage
persistent data such as device configuration, system logs and
other uses.? There are several pull requests in-progress which aim
to add these higher level services.? (The first PR will probably
be re-written to use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Hopefully that helps get you started,

- Mike


Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com <http://www.corvi.com/>


Please consider the environment before printing this e-mail or
its attachments.

Disclaimer: The information contained herein (including any
accompanying documents) is confidential and is intended solely
for the addressee(s). If you have erroneously received this
message, please immediately delete it and notify the sender.
Also, if you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or taking any
action in reliance on the contents of this message or any
accompanying document is strictly prohibited and is unlawful. The
organization is not responsible for any damage caused by a virus
or alteration of the e-mail by a third party or otherwise. The
contents of this message may not necessarily represent the views
or policies of Corvi



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

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

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


Re: Firmware over the air (FOTA) and FCB support in 1.11.0

laczenJMS
 

Hi,

As the author of NVS (PR6391
https://github.com/zephyrproject-rtos/zephyr/pull/6391) I am probably
a bit biased. NVS as is can be used directly for managing persistent
data. I am looking into adding NVS as a backend to the configuration
system, but the configuration system comes with a major drawback:
flash usage.

I did a little calculation to compare the configuration system with
FCB as backend to direct use of NVS. Lets make the following
assumptions: Device is nrf51822, flash erase size is 1k, flash erase
cycles is 20000. Flash available for storage is 2k (2 pages). Data
without the sequence number takes up 512 bytes so 512 bytes is
available to store the sequence number.

Now lets see what happens when storing the sequence number, we will
only store it after 8192 messages (this means we only need to store a
11 bit number). This number can be increased but will reduce the
number of reboots that are allowed (to keep the IV index from changing
to fast). The worst case scenario is 24.3 messages/s (see nordicsemi
mesh-sdk).

Calculation for the config system: each store of the sequence number
is a string looking like:
"bt/btmesh/seq=XXXX" which takes up 18 bytes. FCB overhead takes
another 8 bytes, so in total 26 bytes for a write of the sequence
number. After 19 (512/26) writes a sector is full and it will be
erased (using a 1K scratch sector). So with the worst case of 24.3
messages/s: after 19 * 8192 /24.3 s a sector will be erased. Or every
1.78 h. With the erase cycles of 20000 flash will be worn out after
about 4 years.

Calculation for NVS: the sequence number is given an id for storage.
This id is used to differentiate between other data that is stored
(and is part of the NVS overhead). The sequence number takes up only 2
bytes. NVS overhead takes up 8 bytes, so in total 10 bytes for a
write. After 51 (512/10) messages the first page (1k) is full and the
second page is taken into use. After 51 messages the second sector is
full and the first page is erased. So after 102 messages the same page
is erased. With the erase cycle of 20000 flash will be worn out after
about 21.5 years.

Modifying the above assumptions should allow you to get an estimate of
the expected life of your specific application.

To summarize: the configuration system comes at a price, the use of
human readable strings as storage items takes up more space, and
reduces the life of the device.

I am currently working on a solution for the configuration system that
would use NVS as a backend but would also allow some data to be
directly written to NVS. This would allow combination of human
readability for some data with reduced flash wear for other. But the
human readability will always take up more space.

Kind regards,

Jehudi

Message: 1
Date: Wed, 21 Mar 2018 14:02:39 -0700
From: Michael Scott <michael@opensourcefoundries.com>
To: Vikrant More <vikrant8051@gmail.com>
Cc: zephyr-users@lists.zephyrproject.org,
zephyr-devel@lists.zephyrproject.org, "ashish.shukla@corvi.com"
<ashish.shukla@corvi.com>
Subject: Re: [Zephyr-devel] Firmware over the air (FOTA) and FCB
support in 1.11.0
Message-ID:
<7d94daad-9272-4517-f236-50255c352f00@opensourcefoundries.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"



On 03/21/2018 10:09 AM, Vikrant More wrote:
Hi,
Regarding FCB: the initial implementation is done in v1.11,
but the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage persistent
data such as device configuration, system logs and other uses.
There are several pull requests in-progress which aim to add these
higher level services.? (The first PR will probably be re-written to
use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Are these PRs, suitable to save #BluetoothMesh's Sequence Numbers on
flash which updates frequently ?
IIRC, the idea is to settle on 1 solution which would be appropriate for
most use-cases (including Mesh Sequence Numbers).?? You might want to
have 2 separate storage locations if you have data that only updates
occasionally *and* data that updates frequently.

The guys from Nordic (and possibly Johan) are looking at this issue as well.

- Mike


Thanks,


On Wed, Mar 21, 2018 at 9:59 PM, Michael Scott
<michael@opensourcefoundries.com
<mailto:michael@opensourcefoundries.com>> wrote:



On 03/20/2018 09:14 PM, ashish.shukla@corvi.com
<mailto:ashish.shukla@corvi.com> wrote:
Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when
it is supported, I cannot see any samples available or proper
documentation to use these features in my project.
Hi Ashish,

Your question is a bit open-ended, and might be difficult to
answer without some details regarding your paricular use-case (BLE
update, IP-based update, Mesh, etc)

For instance, the LwM2M subsystem provides a mechanism for
receiving a firmware update in the LwM2M client, but the
implementation of where to store the incoming binary data is up to
you.? See
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208
<https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208>
for a callback example that is triggered on each incoming block of
data.? Documentation for the sample itself doesn't discuss the
firmware update mechanism, but it's here for reference:
http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html
<http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html>

Then, there is a robust DFU (Device Firmware Update) subsystem to
help implement the image writing portion of a firmware update as
well as integrate with mcuboot (an MCU bootloader) which would
check an image for validity and then move it into the bootable
application slot. ? See:
https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/dfu
<https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/dfu>
for sources.

Regarding FCB: the initial implementation is done in v1.11, but
the APIs are fairly complex and IMHO it's meant to be used as a
base layer for other higher level implementations to manage
persistent data such as device configuration, system logs and
other uses.? There are several pull requests in-progress which aim
to add these higher level services.? (The first PR will probably
be re-written to use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
<https://github.com/zephyrproject-rtos/zephyr/pull/6391>
https://github.com/zephyrproject-rtos/zephyr/pull/6408
<https://github.com/zephyrproject-rtos/zephyr/pull/6408>

Hopefully that helps get you started,

- Mike


Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development
www.corvi.com <http://www.corvi.com/>


Please consider the environment before printing this e-mail or
its attachments.

Disclaimer: The information contained herein (including any
accompanying documents) is confidential and is intended solely
for the addressee(s). If you have erroneously received this
message, please immediately delete it and notify the sender.
Also, if you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or taking any
action in reliance on the contents of this message or any
accompanying document is strictly prohibited and is unlawful. The
organization is not responsible for any damage caused by a virus
or alteration of the e-mail by a third party or otherwise. The
contents of this message may not necessarily represent the views
or policies of Corvi



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

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


Re: BBC:microbit like pairing implementation on nRF52840-PDK

Vikrant More <vikrant8051@...>
 

Hi,
Suppose there is Admin Characteristic (which requires OOB pairing since I've enable BT_GATT_PERM_WRITE_AUTHEN | BT_GATT_PERM_WRITE_ENCRYPT | BT_GATT_PERM_READ_AUTHEN | BT_GATT_PERM_READ_ENCRYPT)
Can I send AES Key(common for all devices) after OOB pairing to Admin characteristic?

If Yes, then Device can save it on flash & future communication with all other characteristics
( where I've not enable BT_GATT_PERM_WRITE_AUTHEN | BT_GATT_PERM_WRITE_ENCRYPT | BT_GATT_PERM_READ_AUTHEN | BT_GATT_PERM_READ_ENCRYPT)
will be encrypted using it. That's it !!


Thanks,

On Thu, Mar 22, 2018 at 2:48 PM, Vikrant More <vikrant8051@...> wrote:
In this video, user directly enter PIN from BBC:microbit for pairing.


https://www.youtube.com/watch?v=L54Sp2DZibA
In this video, user add pattern first & then enter PIN to pair.

What is pros & cons in these two styles of pairing ?

----------------------------------------------------------------------------------------------------------------------------------------
In both cases. user transform microbit into pairing mode.

What is significance behind it ? Is it help to device enter into factory reset mode ?

As per current Zephyr implementation, we can do pairing without goes into pairing mode.
----------------------------------------------------------------------------------------------------------------------------------------

By using combination of,

 1. BT_GATT_PERM_WRITE_AUTHEN
 2. BT_GATT_PERM_WRITE_ENCRYPT
 3. BT_GATT_PERM_READ_AUTHEN
 4. BT_GATT_PERM_READ_ENCRYPT

we could block Guest users to access certain characteristics & allow only Admin to access them
(who has paired with the Device)

If I do OOB pairing using Device Serial Terminal, it works as expected but after Device reboot I have to do it again to access admin characteristic.

There should be some variable which I have to store on device flash after Pairing & have to reinitialize them on every reboot.
But there is no any demo examples or documentations which shows what to save on flash.
I think this is what I want but this much is not sufficient for noob like me to implementation it with actual products.
----------------------------------------------------------------------------------------------------------------------------------------

Thank You !!












BBC:microbit like pairing implementation on nRF52840-PDK

Vikrant More <vikrant8051@...>
 

In this video, user directly enter PIN from BBC:microbit for pairing.


https://www.youtube.com/watch?v=L54Sp2DZibA
In this video, user add pattern first & then enter PIN to pair.

What is pros & cons in these two styles of pairing ?

----------------------------------------------------------------------------------------------------------------------------------------
In both cases. user transform microbit into pairing mode.

What is significance behind it ? Is it help to device enter into factory reset mode ?

As per current Zephyr implementation, we can do pairing without goes into pairing mode.
----------------------------------------------------------------------------------------------------------------------------------------

By using combination of,

 1. BT_GATT_PERM_WRITE_AUTHEN
 2. BT_GATT_PERM_WRITE_ENCRYPT
 3. BT_GATT_PERM_READ_AUTHEN
 4. BT_GATT_PERM_READ_ENCRYPT

we could block Guest users to access certain characteristics & allow only Admin to access them
(who has paired with the Device)

If I do OOB pairing using Device Serial Terminal, it works as expected but after Device reboot I have to do it again to access admin characteristic.

There should be some variable which I have to store on device flash after Pairing & have to reinitialize them on every reboot.
But there is no any demo examples or documentations which shows what to save on flash.
I think this is what I want but this much is not sufficient for noob like me to implementation it with actual products.
----------------------------------------------------------------------------------------------------------------------------------------

Thank You !!











Re: Firmware over the air (FOTA) and FCB support in 1.11.0

Michael Scott
 



On 03/21/2018 10:09 AM, Vikrant More wrote:
Hi,
>> Regarding FCB: the initial implementation is done in v1.11,
>>but the APIs are fairly complex and IMHO it's meant to be used as a base layer for other higher level implementations to manage persistent data such as device configuration, system logs and other uses. 
>>There are several pull requests in-progress which aim to add these higher level services.  (The first PR will probably be re-written to use FCB as it's base layer):
>> https://github.com/zephyrproject-rtos/zephyr/pull/6391
>> https://github.com/zephyrproject-rtos/zephyr/pull/6408

Are these PRs, suitable to save #BluetoothMesh's Sequence Numbers on flash which updates frequently ?

IIRC, the idea is to settle on 1 solution which would be appropriate for most use-cases (including Mesh Sequence Numbers).   You might want to have 2 separate storage locations if you have data that only updates occasionally *and* data that updates frequently.

The guys from Nordic (and possibly Johan) are looking at this issue as well.

- Mike


Thanks,


On Wed, Mar 21, 2018 at 9:59 PM, Michael Scott <michael@...> wrote:



On 03/20/2018 09:14 PM, ashish.shukla@... wrote:
Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when it is supported, I cannot see any samples available or proper documentation to use these features in my project.

Hi Ashish,

Your question is a bit open-ended, and might be difficult to answer without some details regarding your paricular use-case (BLE update, IP-based update, Mesh, etc)

For instance, the LwM2M subsystem provides a mechanism for receiving a firmware update in the LwM2M client, but the implementation of where to store the incoming binary data is up to you.  See https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208 for a callback example that is triggered on each incoming block of data.  Documentation for the sample itself doesn't discuss the firmware update mechanism, but it's here for reference: http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html

Then, there is a robust DFU (Device Firmware Update) subsystem to help implement the image writing portion of a firmware update as well as integrate with mcuboot (an MCU bootloader) which would check an image for validity and then move it into the bootable application slot.   See: https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/dfu for sources.

Regarding FCB: the initial implementation is done in v1.11, but the APIs are fairly complex and IMHO it's meant to be used as a base layer for other higher level implementations to manage persistent data such as device configuration, system logs and other uses.  There are several pull requests in-progress which aim to add these higher level services.  (The first PR will probably be re-written to use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
https://github.com/zephyrproject-rtos/zephyr/pull/6408

Hopefully that helps get you started,

- Mike


Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi



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


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




Re: Firmware over the air (FOTA) and FCB support in 1.11.0

Vikrant More <vikrant8051@...>
 

Hi,
>> Regarding FCB: the initial implementation is done in v1.11,
>>but the APIs are fairly complex and IMHO it's meant to be used as a base layer for other higher level implementations to manage persistent data such as device configuration, system logs and other uses. 
>>There are several pull requests in-progress which aim to add these higher level services.  (The first PR will probably be re-written to use FCB as it's base layer):
>> https://github.com/zephyrproject-rtos/zephyr/pull/6391
>> https://github.com/zephyrproject-rtos/zephyr/pull/6408

Are these PRs, suitable to save #BluetoothMesh's Sequence Numbers on flash which updates frequently ?

Thanks,


On Wed, Mar 21, 2018 at 9:59 PM, Michael Scott <michael@...> wrote:



On 03/20/2018 09:14 PM, ashish.shukla@... wrote:
Hi all,

I've been waiting for FOTA and FCB support in zephyr and now when it is supported, I cannot see any samples available or proper documentation to use these features in my project.

Hi Ashish,

Your question is a bit open-ended, and might be difficult to answer without some details regarding your paricular use-case (BLE update, IP-based update, Mesh, etc)

For instance, the LwM2M subsystem provides a mechanism for receiving a firmware update in the LwM2M client, but the implementation of where to store the incoming binary data is up to you.  See https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/lwm2m_client/src/lwm2m-client.c#L208 for a callback example that is triggered on each incoming block of data.  Documentation for the sample itself doesn't discuss the firmware update mechanism, but it's here for reference: http://docs.zephyrproject.org/samples/net/lwm2m_client/README.html

Then, there is a robust DFU (Device Firmware Update) subsystem to help implement the image writing portion of a firmware update as well as integrate with mcuboot (an MCU bootloader) which would check an image for validity and then move it into the bootable application slot.   See: https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/dfu for sources.

Regarding FCB: the initial implementation is done in v1.11, but the APIs are fairly complex and IMHO it's meant to be used as a base layer for other higher level implementations to manage persistent data such as device configuration, system logs and other uses.  There are several pull requests in-progress which aim to add these higher level services.  (The first PR will probably be re-written to use FCB as it's base layer):
https://github.com/zephyrproject-rtos/zephyr/pull/6391
https://github.com/zephyrproject-rtos/zephyr/pull/6408

Hopefully that helps get you started,

- Mike


Any help regarding the same would be of great help.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi



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


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



How to dynamically OR on reboot update BLE device TX power ?

Vikrant More <vikrant8051@...>
 

Hi,
How to dynamically OR on reboot update nRF52 based BLE Device TX power ?


Thanks,
vikrant8051

3701 - 3720 of 8041