Hello again,
I am putting together a device that need a lot of local non-volatile data and uses a lot of flash on my NRF52833. I am running NRF Connect SDK 2.6.0. I'd like to be able update the firmware (including the data) over BLE which I understand needs mcuboot and two application slots to be able to perform BLE DFU updates during execution of the application.
Currently, the application uses the new BLE link layer (CONFIG_BT_LL_SW_SPLIT) and only scans and advertises. It does not perform connections or have a GATT server, characteristics etc.
If I want to use the standard way of doing DFU with mcumgr over SMP and BLE, this requires CONFIG_BT_PERIPHERIAL which about doubles the size of the BLE stack which limits the amount of local data we can have. Is there any way we could trim this down? This is the size of the application with and without the DFU configs:
With BLE SMP DFU: 237,228 bytes (96% of our slot)
Without BLE SMP DFU: 160,500 bytes (65% of our slot)
Looking at output from rom_report build target:
with BLE SMP DFU: (ZEPHYR_BASE/subsys/bluetooth): 132,859 bytes
without BLE SMP DFU: (ZEPHYR_BASE/subsys/bluetooth): 68,652 bytes
Here are the config options that I am currently testing with that add the size:
CONFIG_BT_PERIPHERAL=y
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=n
CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL=y
Is this just the flash size penalty that we need to pay to have this reference BLE DFU functionality?
Thank you,
Ethan
