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

Kai Ren

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


CONFIG_BT_RX_STACK_SIZE=1450 (from 1100)






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?





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:



#5.0 features







#4.2 features







#4.1 features




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!







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:




… provided you can find some free RAM space!






From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Kai Ren
Sent: Friday, March 23, 2018 4:11 AM
To: Johan Hedberg <
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.








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



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

    to cmake: -DCONF_FILE=microbit_gatt.conf




Join to automatically receive all group messages.