UNABLE to do BLE FOTA (SDK 2.4.0)

[Humberto Matias Cosentini]

Board: Custom board

---

Chip: NRF28323 - 512K flash 64K RAM

---

SDK 2.4.0   -  ZEPHYR 3.3.99 - CMake 3.20.5 - West 1.0.0 - VSCode pluggin v2023.4.179

---

We used to program with SEGGER and the SOFTDEVICE, but in this project we decided to start using ZEPHYR and we already regret it, implementing the DUF before was so easy now is a nightmare.

We used as base a CTS sample because we need to ge the current time for our project, after working on it, we decide to add the FOTA functionality, we managed to fix a lot of issues, but one is wining. 

We added to our project the SMP service and the config options mentioned in the FOTA documentation, but we get, the FLASH overflow error "zephyr\zephyr_pre0.elf section `text' will not fit in region `FLASH' -region `FLASH' overflowed by 81964 bytes"

So we read all the post in the forum about it, in all the post the recommendation is is to increase the MCUBOOT partition size until the problem is fixed, but here is where we found this funny behavior.

CONFIG_PM_PARTITION_SIZE_MCUBOOT	MCBOOT size	Overflow in bytes
0x8000	32KB	81964
0xc000	48KB	90156
0x10000	64KB	98348
0x40000	256KB	196652

So my understanding is that when we get the overflow message is related to the APP not to the MCUBOOT, unless I misunderstood something. 

So the solution to increase the size of  the MCUBOOT partition to fix the problem can't fix it.

Here are the CMAKE WARNINGS I got while building.

CMake Warning at C:/nrf_sdk/v2.4.0/nrf/samples/common/mcumgr_bt_ota_dfu/CMakeLists.txt:14 (message):
  MCUmgr Bluetooth OTA DFU: suboptimal configuration of Bluetooth Controller
  buffers.  Consider using optimal values defined in the
  C:/nrf_sdk/v2.4.0/nrf/samples/common/mcumgr_bt_ota_dfu/Kconfig file for
  CONFIG_BT_BUF_ACL_TX_SIZE, CONFIG_BT_BUF_ACL_RX_SIZE and
  CONFIG_BT_CTLR_DATA_LENGTH_MAX options


CMake Warning at C:/nrf_sdk/v2.4.0/nrf/samples/common/mcumgr_bt_ota_dfu/CMakeLists.txt:27 (message):
  MCUmgr Bluetooth OTA DFU: suboptimal configuration of Bluetooth Host
  buffers.  Consider using optimal values defined in the
  C:/nrf_sdk/v2.4.0/nrf/samples/common/mcumgr_bt_ota_dfu/Kconfig file for
  CONFIG_BT_BUF_ACL_TX_SIZE, CONFIG_BT_BUF_ACL_RX_SIZE and
  CONFIG_BT_L2CAP_TX_MTU options

CMake Warning (dev) at F:/_SW/_ATL_projects/ATLRR00158_Ice_Sensor/ATLRR00158_Ice_Sensor/build/mcuboot/child_image_preload.cmake:7 (set):
  Syntax error in cmake code at

    F:/_SW/_ATL_projects/ATLRR00158_Ice_Sensor/ATLRR00158_Ice_Sensor/build/mcuboot/child_image_preload.cmake:7

  when parsing string

    c:\nrf_sdk\toolchains\31f4403e35\opt\bin\python.exe

  Invalid escape sequence \3

  Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
  "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning at C:/nrf_sdk/v2.4.0/zephyr/CMakeLists.txt:838 (message):
  No SOURCES given to Zephyr library: lib__libc__common

  Excluding target from build.

This is the prj.conf file

CONFIG_HEAP_MEM_POOL_SIZE=1024
#CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2304  #2040 previous to adding FOTA
CONFIG_MAIN_STACK_SIZE=4096

#Configuration for BT
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="xxxxxxx"
CONFIG_BT_DEVICE_APPEARANCE=768

#Configuration GATT client
CONFIG_BT_GATT_CLIENT=y

#ENABLE manager
CONFIG_BT_GATT_DM=y

#Enable of Security Manager Protocol support
CONFIG_BT_SMP=y

# Enable CTS client
CONFIG_BT_CTS_CLIENT=y

# Enable Device Information service
CONFIG_BT_DIS=y
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_FW_REV_STR="xxxxxx"
CONFIG_BT_DIS_HW_REV=y
CONFIG_BT_DIS_HW_REV_STR="xxxx"
CONFIG_BT_DIS_MANUF="xxxxxxx"
CONFIG_BT_DIS_MODEL="xxxxxxxx"
CONFIG_BT_DIS_SERIAL_NUMBER=y
CONFIG_BT_DIS_SERIAL_NUMBER_STR="SN01xxxxxx"
CONFIG_BT_DIS_SW_REV=y
CONFIG_BT_DIS_SW_REV_STR="xxxxx"
CONFIG_BT_DIS_PNP=n

# Enable bondings
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y


#Enable RTT to read the logging
CONFIG_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

#Enable log and use the RTT backend

CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_SHOW_COLOR=y
CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP=y
CONFIG_LOG_DEFAULT_LEVEL=1

# CONFIG_UART_CONSOLE=n
CONFIG_PRINTK=y

#Enable GPIO control
CONFIG_GPIO=y

CONFIG_DEBUG_THREAD_INFO=y
CONFIG_DEBUG_OPTIMIZATIONS=y

# #Enable ADC
CONFIG_ADC=y

#enable primt float
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_NEWLIB_LIBC_MIN_REQUIRED_HEAP_SIZE=2048
CONFIG_CBPRINTF_FP_SUPPORT=y

# Enable FOTA DFU
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y

# Allow for large Bluetooth data packets.
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

# Enable the Bluetooth mcumgr transport (unauthenticated).
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=n
CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL=y

# Enable the Shell mcumgr transport.
CONFIG_BASE64=y
CONFIG_SHELL=y
CONFIG_SHELL_BACKEND_SERIAL=n
CONFIG_MCUMGR_TRANSPORT_SHELL=y

# Enable the mcumgr Packet Reassembly feature over Bluetooth and its configuration dependencies.
# MCUmgr buffer size is optimized to fit one SMP packet divided into five Bluetooth Write Commands,
# transmitted with the maximum possible MTU value: 498 bytes.
CONFIG_MCUMGR_TRANSPORT_BT_REASSEMBLY=y
CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=2475
CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS=y
CONFIG_MCUMGR_TRANSPORT_WORKQUEUE_STACK_SIZE=4608

# Enable the LittleFS file system.
CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y

# Enable file system commands
CONFIG_MCUMGR_GRP_FS=y

# Enable the storage erase command.
CONFIG_MCUMGR_GRP_ZBASIC=y
CONFIG_MCUMGR_GRP_ZBASIC_STORAGE_ERASE=y

# Disable Bluetooth ping support
CONFIG_BT_CTLR_LE_PING=n

# Disable shell commands that are not needed
CONFIG_CLOCK_CONTROL_NRF_SHELL=n
CONFIG_DEVICE_SHELL=n
CONFIG_DEVMEM_SHELL=n
CONFIG_FLASH_SHELL=n

I tried to use from VSCODE the memory report but I get an error, I have the SDK and my project files in different drives, so maybe that's why.

How can I fix this? We spent 3 days stuck on this, 

Can you suggest how to configure the pm_static.yml to fix this problem?

Thanks for the support.

[AHaug]

Hi,

How can I fix this? We spent 3 days stuck on this, 

nRF Connect SDK v2.4.0 were released yesterday. Could you clarify if you've been using nCS v2.4.0-rc1 before that point in time, or have you been using NCS v2.3.0?

We added to our project the SMP service and the config options mentioned in the FOTA documentation, but we get, the FLASH overflow error "zephyr\zephyr_pre0.elf section `text' will not fit in region `FLASH' -region `FLASH' overflowed by 81964 bytes"

The issue is that your application is to large to support DFU without external flash on a device that only has 512kB of internal flash. You will either have to reduce the application w.r.t flash, add an external flash or upgrade to the nRF52840/nRF5340 which has 1MB of flash.

So we read all the post in the forum about it, in all the post the recommendation is is to increase the MCUBOOT partition size until the problem is fixed, but here is where we found this funny behavior.

It is not possible to solve the flash overflow of your application by increasing the bootloader partition. What those cases that you have read must suggest is to increase the size of the primary and secondary application partitions. This can be done in the pm_static.yml if the device you're working with has surplus flash.

To illustrate how it will look like on the nRF52833 (same flash as the nRF52832 which I assume you're using), I've used this minimal sample to generate a build with DFU support: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/smp/mcuboot_smp_ble

  flash_primary (0x80000 - 512kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x3a000 - 232kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x39e00 - 231kB)-+
| 0xc200: app (0x39e00 - 231kB)                   |
+-------------------------------------------------+
| 0x46000: mcuboot_secondary (0x3a000 - 232kB)    |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

You see there are 3 partitions within "Flash_primary":

1. mcuboot (48kB) which is where the bootloader lies
2. mcuboot_primary (232kB): Maximum half of the remaining flash size of the internal flash. This is where your application will be run from
3. mcuboot_secondary (232kb): Must be the same size as mcuboot primary. This is where the image used for updating will be temporarily stored when you perform DFU and the bootloader does its swap magic.

Can you open the build folder in command line/bash and use ninja partition_manager_report? The output should be something similar to what I listed above.

Your application is most likely ~300kB since you have a flash overflow of 81964bytes. As I mentioned, this is too large to fit on a nRF52832/52833 if you wish to add DFU support.

Can you suggest how to configure the pm_static.yml to fix this problem?

What does your current pm_static.yml look like? Could you post it here? Remember that the case is a public case so don't post any sensitive information in this ticket.

Kind regards,
Andreas

[Humberto Matias Cosentini]

AHaug said:

nRF Connect SDK v2.4.0 were released yesterday. Could you clarify if you've been using nCS v2.4.0-rc1 before that point in time, or have you been using NCS v2.3.0?

We were using NCS v2.3.0 we updated today.

AHaug said:

Your application is most likely ~300kB since you have a flash overflow of 81964bytes. As I mentioned, this is too large to fit on a nRF52832/52833 if you wish to add DFU support.

Ok, that's a bad news, we are only running the Current time service and the SMP service to do the OTA, the ADC and we are using RTT backend for logs.

Is our first time using Zephyr and MCUboot, I guess I didn't expect that this RTOS will be so memory-inefficient, or maybe we configured something wrong.

AHaug said:

Can you open the build folder in command line/bash and use ninja partition_manager_report? The output should be something similar to what I listed above.

Here you are:

+-------------------------------------------------+
| 0x0: mcuboot (0x8000 - 32kB)                    |
+---0x8000: mcuboot_primary (0x38000 - 224kB)-----+
| 0x8000: mcuboot_pad (0x200 - 512B)              |
+---0x8200: mcuboot_primary_app (0x37e00 - 223kB)-+
| 0x8200: app (0x37e00 - 223kB)                   |
+-------------------------------------------------+
| 0x40000: mcuboot_secondary (0x38000 - 224kB)    |
| 0x78000: littlefs_storage (0x6000 - 24kB)       |
| 0x7e000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x20000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

AHaug said:

The issue is that your application is to large to support DFU without external flash on a device that only has 512kB of internal flash. You will either have to reduce the application w.r.t flash, add an external flash or upgrade to the nRF52840/nRF5340 which has 1MB of flash.

I'm super surprised we only enabled the BLE with 2 services, the FOTA and the ADC, nothing else.

We are doing a demo in a week so we already have the demo PCB ready, what a nightmare we will need to change everything to SOFTDEVICE then.

Let me know if we are missing something, and thanks for your support.

[AHaug]

Thank you for clarifying, providing the partition report and giving some more information about your time horizon

AHaug said:

What does your current pm_static.yml look like? Could you post it here?

I assume that you don't use a static partition file as this question were left unanswered?

Humberto Matias Cosentini said:

I'm super surprised we only enabled the BLE with 2 services, the FOTA and the ADC, nothing else.

We are doing a demo in a week so we already have the demo PCB ready, what a nightmare we will need to change everything to SOFTDEVICE then.

I agree that it sounds like it is a lot.

When you perform a build it should generate how large the files are. Could you post the build logs in a code attachment so we can exclude if the application actually is that large or if the issue is elsewhere?

In this blog  Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK there are steps to optimize the memory footprint. If you have the time, I would recommend you to have a look at the various tips there. In addition, this page: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/optimizing/index.html also has some recommandations

If you're able, you could also zip and attach your project and I can have a look to see if I spot something that is not mentioned in these two links

Kind regards,
Andreas