Flash size of BLE Applications

[H.Marske]

Hi,

We are currently developing an application where we use a nrf52811.
Currently i am working on integrating the BLE-Stack as this is the last part missing.

I am constantly running out of flash as well as RAM. Therefor we also scrapped a FOTA-Update via BLE as there was no way of implementing this with this few Flash.
Can someone please verify that BLE as a central wich scans for devices with a certain Complete-Name in its advertising data takes up almost XX% of Flash and XX% of RAM?

without BLE:
  FLASH: 190644B - 96.97%
  RAM: 23432B - 95.35%
with BLE:
  FLASH: 52724B - 26.82%
  RAM: 4968B - 20.21%

Also my program crashes when i start the scanning. I believe this is due to a lack of memory. I reduced several queues and stack in order to fit everything in the ram.

My curent configuration is as follows:

CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_POWEROFF=y

CONFIG_BT=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_SMP=y
CONFIG_BT_OBSERVER=y
CONFIG_BT_SCAN=y
CONFIG_BT_GATT_DM=y
CONFIG_BT_FAST_PAIR=n
CONFIG_HEAP_MEM_POOL_SIZE=512
CONFIG_BT_DEBUG_NONE=y
CONFIG_BT_ASSERT=n
CONFIG_BT_DATA_LEN_UPDATE=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_GATT_SERVICE_CHANGED=n
CONFIG_BT_DEVICE_NAME="SL_RC"
CONFIG_BT_CTLR_LE_ENC=n
CONFIG_BT_CTLR_ECDH=n
CONFIG_BT_CTLR_EXT_REJ_IND=n
CONFIG_BT_CTLR_CONN_RSSI=n
CONFIG_MINIMAL_LIBC=y
CONFIG_BT_CTLR_EXT_SCAN_FP=n

CONFIG_MAIN_STACK_SIZE=512
CONFIG_IDLE_STACK_SIZE=128
CONFIG_ISR_STACK_SIZE=256
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512

Apart from that i am using 1 PWM-Peripheral, 1 SAADC-Channel, 2 RGB-LED and 4 Buttons.
I have a hard time believing that these rather few peripherals make me run out of Memory

EDIT:
To make my usecase clearer:
On button press i want to scan for all devices with a certain complete name in its Advertising Data.
I then want to connect to the device with the best RSSI-Value over a certain timeperiod (e.g. 5 seconds)
After connecting i want to set a certain GATT-Service to 0 or 1 depending on the Button pressed.

[Einar Thorsrud]

Hi,

The default configurations typically have some headroom with regards to buffer sizes etc which affect RAM, and also include support for features you may not need, which affect both flash and RAM usage. I see you are able to fit th eapplication, though just barely. With optimizations, I exect you should have a bit more headroom. I do not have an example that does exactly what you describe, but you can refer to the prj_minimal.conf here which gives a good idea (though this is for a Bluetooth peripheral device). Zephyr also has a sample with a prj_minimal.conf for a central. There is also documentation on Memory footprint optimization that is worth exploring.

As you are able to build the project, I do not believe the issue you are seeing when testing is due to lack of memory. The linker was able to place everything in RAM, includign all buffers etc. But to know more about why you see a crash when starting scannng we need to debug (first I would start by olbserving the log if you have logging enabled to see if there is a fault).

[H.Marske]

Enabeling loggin would overflow flash by 29080B and RAM by 3400B, so there is no point in enabeling this.

I have attached the stacktrace on failure. I would read it as i try calling the mpsl workqueue out of an ISR but i am not. I call this

The reason-Parameter is 4

It fails after starting the scan with bt_le_scan_start but before i stop it.
I can post the start-scanning-code as well as the stopping if it helps

[Einar Thorsrud]

Hi,

This shows an MPSL assert. As logging is diffucult, can you debug in m_assert_handler() and check the file and line? (If it is easier you can allo make a custom mpsl_assert_handle() function and check there). I can look up the MPSL assert information to see if it gives any pointers.

[H.Marske]

on the left you can see the file and line parameter

Thanks four your help!

[Einar Thorsrud]

Thanks, that is what I was looking for. However, I forgot to ask which SDK version you are using?