Topics

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

 

 


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


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


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

   


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

   


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

   


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

   


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

   


Martin <ma@...>
 

Hi,
I am running into the same problem (ISR / Spinning error when trying to run the bluetooth mesh example with gatt enabled on micro bit) but unfortunately do not know how to delete Generic Level server / root model from zephyr. Could someone give me a heads up please? Is there some straightforward way?

Thanks,

Martin


vikrant8051 <vikrant8051@...>
 

Hi to All,
FYI, after sync with master branch I too got some kernel fault, MPU fault
while testing with Bluetooth Mesh sample examples.


On Wed, Sep 5, 2018 at 4:37 AM Martin <ma@...> wrote:

Hi,
I am running into the same problem (ISR / Spinning error when trying to run the bluetooth mesh example with gatt enabled on micro bit) but unfortunately do not know how to delete Generic Level server / root model from zephyr. Could someone give me a heads up please? Is there some straightforward way?

Thanks,

Martin