nRF52833 DFU OTA failing due to flash space (MCUboot dual-slot too large)

[Sangam Prajapati]

Hello,

I am working with nRF Connect SDK v3.0.2 on nRF52833 and trying to enable DFU over BLE using MCUboot.

• I can see the device in the nRF Connect mobile app, connect to it, and attempt DFU.

• However, the upload fails with GATT connection timeout.

Looking at the build output, my application is already very large:

FLASH: 227600 B / 232960 B (97.7%)
RAM: 49680 B / 131072 B (37.9%)

Since MCUboot with dual-slot mode requires both slot 0 and slot 1, there is not enough flash left for OTA updates.

Prj.config:

CONFIG_NCS_SAMPLES_DEFAULTS=y

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME="SyTrakDFU_test"

CONFIG_DK_LIBRARY=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Step 2.2 - Enable FOTA over Bluetooth LE

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# From rtls_tags: TX Power and Stability

CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

CONFIG_BT_CTLR_ADVANCED_FEATURES=y

CONFIG_BT_CTLR_CONN_RSSI=y

CONFIG_BT_CTLR_ADV_EXT=y

CONFIG_BT_CTLR_RADIO_ENABLE_FAST=y

CONFIG_BT_CTLR_TIFS_HW=y

CONFIG_BT_CTLR_CRYPTO=y

CONFIG_NRF_RTC_TIMER=y

CONFIG_CLOCK_CONTROL=y

CONFIG_CLOCK_CONTROL_NRF=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_PM=y

CONFIG_PM_DEVICE=y

CONFIG_MAIN_STACK_SIZE=2048

CONFIG_BT_BUF_ACL_TX_SIZE=251

CONFIG_BT_BUF_ACL_RX_SIZE=251

CONFIG_BT_BUF_EVT_RX_SIZE=255

CONFIG_BT_BUF_CMD_TX_SIZE=255

CONFIG_BT_CTLR_LLCP_CONN=2

CONFIG_BT_CTLR_LLCP_PER_CONN_TX_CTRL_BUF_NUM=3

CONFIG_BT_CTLR_CONN_PARAM_REQ=n

CONFIG_BT_CTLR_LE_ENC=n

CONFIG_BT_CTLR_PRIVACY=n

CONFIG_LOG=y

CONFIG_GPIO=y

My questions:

1. Is there a recommended way to enable single-slot (overwrite-only) DFU on nRF52833 so that new images overwrite slot 0 directly?

2. Alternatively, what are the best practices to reduce flash usage (e.g., configuration options to safely disable)?

3. Would compression support in MCUboot help in this scenario, or is single-slot the only practical option for nRF52833?

[Hung Bui]

Hi Sangam, 

Could you send us the partitions.yml file in your build folder ? 
What did you change in your new firmware compare to old firmware ? Normally the size of slot 1 (where you receive new image) should be equal to the size of slot 0 (where the current image is). If you don't have significant change in the firmware you should be able to receive the image. 

1. Single slot DFU update is currently not supported in NCS. It is coming but I don't know when and nRF52 may not be supported. 
2. There are a few things you should try: 
- Disable unused features and peripherals
For example 

CONFIG_I2C=n
CONFIG_SPI=n
CONFIG_SERIAL=n
CONFIG_LOG=n
CONFIG_USE_SEGGER_RTT=n
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_PRINTK=n
CONFIG_EARLY_CONSOLE=n

- Optimize Bluetooth Stack and Features

You should optimize the bluetooth stack to only use what you need, for example only peripheral , no PHY update, no extended advertising etc. 
- Compiler Optimization Flags
Use compiler optimization flags for size, such as -Os or -Oz
CONFIG_COMPILER_OPT="-Os"

- Remove Debugging and Assert Features

3. Yes compression support in MCUboot helps. It allows the slot 1 to be 70% of slot 0. 

[Sangam Prajapati]

Thank so much for your support and valuable answer. Here is the partition.yml

app:
address: 0xc200
end_address: 0x45000
region: flash_primary
size: 0x38e00
mcuboot:
address: 0x0
end_address: 0xc000
placement:
align:
end: 0x1000
before:
- mcuboot_primary
region: flash_primary
size: 0xc000
mcuboot_pad:
address: 0xc000
end_address: 0xc200
placement:
align:
start: 0x1000
before:
- mcuboot_primary_app
region: flash_primary
size: 0x200
mcuboot_primary:
address: 0xc000
end_address: 0x45000
orig_span: &id001
- app
- mcuboot_pad
region: flash_primary
sharers: 0x1
size: 0x39000
span: *id001
mcuboot_primary_app:
address: 0xc200
end_address: 0x45000
orig_span: &id002
- app
region: flash_primary
size: 0x38e00
span: *id002
mcuboot_secondary:
address: 0x45000
end_address: 0x7e000
placement:
after:
- mcuboot_primary
align:
start: 0x1000
region: flash_primary
share_size:
- mcuboot_primary
size: 0x39000
settings_storage:
address: 0x7e000
end_address: 0x80000
placement:
align:
start: 0x1000
before:
- end
region: flash_primary
size: 0x2000
sram_primary:
address: 0x20000000
end_address: 0x20020000
region: sram_primary
size: 0x20000

[Hung Bui]

Hi Sangam, 
So what I can see in the partitions.yml is that you have the slot1 configuration as follows: 

mcuboot_secondary:
address: 0x45000
end_address: 0x7e000
placement:
after:
- mcuboot_primary

The size of the slot is 0x39000=233472. 
You will have few hundred bytes less due to over head. But that's pretty much the limit with the nRF52833. 
Please check if your new image exceed this. 

You have some some options: 
- Follow what I wrote to reduce the size of the image

- Use external flash. 

- Try the image compression

I don't think the single bank update on NCS will come for nRF52. But for this future feature, you will have to contact our sale representative. 

[Sangam Prajapati]

Thank you for your answer. I was able to reduce the used flash space from 97% down to 82%. However, I still need to bring it closer to 50%. From what I understand, OTA via DFU mode is only possible if the used flash size is less than 50%.

I also checked on the Nordic forum and documentation, and found that image compression and external flash are not supported on nRF52833 – Image compression is only available on nRF54L15, nRF5340, and nRF52840.

Could you please suggest what other methods we can apply to reduce the flash usage further?

Are there any Nordic-specific recommendations or best practices to shrink the application image size further on nRF52833 so that OTA DFU can work?

[Hung Bui]

Hi, 
No you should be able to update the same application as long as you can flash it on the chip. 
The size is already compensate for dual bank update. For example when you look here: 
FLASH: 227600 B / 232960 B (97.7%)

It say that your application flash is 227600 byte and it is 97.7% of the mcuboot_primary size (232960). 
This doesn't count the secondary slot. So if you can't update the same application, there must be something else wrong. 
I would suggest to try testing with very simple application, try doing DFU on that first. 
Have you followed our Dev Academy guide ? 
academy.nordicsemi.com/.../