BLE DFU nRF5280,nRF5340

RE: BLE DFU nRF5280,nRF5340

Vidar Berg — Wed, 24 Jun 2026 11:18:48 GMT

Continuously polling state flags such as i2s_buffer_ready only wastes CPU cycles. As Turbo suggested here, a semaphore should be suitable for your case.

https://docs.zephyrproject.org/latest/kernel/services/index.html#scheduling-interrupts-and-synchronization

https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-8-thread-synchronization/

RE: BLE DFU nRF5280,nRF5340

Turbo J — Tue, 23 Jun 2026 13:08:48 GMT

That is a blocking (main) thread that could in theory starve others.

Workaround could be k_sem_take()/k_sem_give() instead of the i2s_buffer_ready bit.

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Tue, 23 Jun 2026 12:48:00 GMT

[quote userid="4240" url="~/f/nordic-q-a/128480/ble-dfu-nrf5280-nrf5340/568316"]I can't say much without seeing any code. I understand you have proprietary code you are unable to share, but you can still show code that isn't or create pseudo code to illustrate what you are doing. Would also help to know if you are using the Zephyr drivers for i2s, etc[/quote]

int main(void)
{
    ble_init();

    codec_init();
    i2s_init();

    while (1)
    {
        if (recording_enabled)
        {
            if (i2s_buffer_ready)
            {
                process_audio();
                // write audio data to buffer
                // codec control operations
                // occasionally stop/start I2S
            }
        }

        // No user-created threads
    }
}

✅ A simple application (only BLE/main) performs DFU successfully.
❌ my actual application (I2S, codec, audio processing, flash, etc.) advertises SMP, nRF Connect detects MCUboot, negotiates MTU, queries image list, and starts "Uploading firmware...", but the progress window disappears in the middle.

RE: BLE DFU nRF5280,nRF5340

Vidar Berg — Tue, 23 Jun 2026 11:57:13 GMT

I can't say much without seeing any code. I understand you have proprietary code you are unable to share, but you can still show code that isn't or create pseudo code to illustrate what you are doing. Would also help to know if you are using the Zephyr drivers for i2s, etc

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Tue, 23 Jun 2026 10:40:41 GMT

[quote userid="4240" url="~/f/nordic-q-a/128480/ble-dfu-nrf5280-nrf5340/568110"]Our SDK examples will typically spend >99% of the time in sleep (from the idle thread), and it is difficult to comment on why you are seeing the high cpu usage in your case without any details about your code. I would recommend you go through our devacademy course here: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-7-multithreaded-applications/topic/scheduler/. [/quote]

Hi, i studied zephyr RTOS...

in my application we have handling multiple pheripherals.. in my main thread we have while loop continuously reading i2s data and etc.. in this case iam suspecting main thread leads to BLE starve so dfu failing...is am correct? i can share my prj.conf.. but iam unable to share whole code because of privacy...

# -------------------------------
# Console & Output Configuration
# -------------------------------
CONFIG_CONSOLE=y                        
CONFIG_STDOUT_CONSOLE=y                 
CONFIG_PRINTK=y
CONFIG_UART_CONSOLE=y
CONFIG_UART_LINE_CTRL=y

#----------------------
# USB CDC ACM (USB Serial) Configuration
#----------------------
CONFIG_SERIAL=y
CONFIG_USB_CDC_ACM=y

#--------------------------------
# USB Device Stack Configuration
#--------------------------------
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="nRF5340 Composite Device"
CONFIG_USB_DEVICE_MANUFACTURER="Nordic"
CONFIG_USB_DEVICE_PID=0x0004
CONFIG_USB_DEVICE_VID=0x1915

# -------------------------------
# General Kernel Configuration
# -------------------------------
CONFIG_MULTITHREADING=y                 
CONFIG_MAIN_STACK_SIZE=4096             
CONFIG_HEAP_MEM_POOL_SIZE=4096          


# -------------------------------
# Timekeeping & RTC
# -------------------------------
CONFIG_COUNTER=y                        
CONFIG_NRFX_RTC2=y                     


# -------------------------------
# C Library & Floating Point Support
# -------------------------------
CONFIG_NEWLIB_LIBC=y                    
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y       
CONFIG_CBPRINTF_FP_SUPPORT=y          
CONFIG_FPU=y                           
CONFIG_FP_HARDABI=y   
CONFIG_CMSIS_DSP=y                 
CONFIG_CMSIS_DSP_FILTERING=y 
CONFIG_CMSIS_DSP_STATISTICS=y
CONFIG_CMSIS_DSP_TRANSFORM=y
CONFIG_CMSIS_DSP_FASTMATH=y

# -------------------------------
# Bluetooth (BLE) Configuration
# -------------------------------
CONFIG_BT=y                            
CONFIG_BT_PERIPHERAL=y                 
CONFIG_BT_DEVICE_NAME="FYZKS_WDS"      
CONFIG_BT_GATT_CLIENT=y                
CONFIG_BT_ZEPHYR_NUS=y                 
CONFIG_BT_USER_DATA_LEN_UPDATE=y        
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=502           
CONFIG_BT_BUF_ACL_TX_SIZE=502         
CONFIG_BT_L2CAP_TX_MTU=498           
CONFIG_BT_USER_PHY_UPDATE=y    
CONFIG_BT_CTLR_PHY_2M=y         
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n 

# Connection interval settings
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=6    
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=8     
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0   
# CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=400   
CONFIG_BT_CTLR_TX_PWR_PLUS_4=y  

CONFIG_BT_BUF_ACL_TX_COUNT=65
CONFIG_BT_L2CAP_TX_BUF_COUNT=65
CONFIG_BT_CONN_TX_MAX=65
CONFIG_BT_BUF_EVT_RX_COUNT=70


# -------------------------------
# Device Power Management
# -------------------------------                        
CONFIG_PM_DEVICE=y                           
CONFIG_POWEROFF=y          
# CONFIG_PM_DEVICE_RUNTIME=y

       
# -------------------------------
# Peripherals
# -------------------------------
CONFIG_GPIO=y                          
CONFIG_I2C=y                           
CONFIG_I2S=y                                                
CONFIG_RTC=y  
CONFIG_SPI=y 


# -------------------------------
# Flash & Storage
# -------------------------------
CONFIG_FLASH=y                         
CONFIG_FLASH_MAP=y                    
CONFIG_FLASH_PAGE_LAYOUT=y             
CONFIG_MPU_ALLOW_FLASH_WRITE=y              
CONFIG_NORDIC_QSPI_NOR=y             

# Stream data directly to flash
CONFIG_STREAM_FLASH=y
CONFIG_USB_MASS_STORAGE=y   # to open as drive
CONFIG_MASS_STORAGE_DISK_NAME="NAND"
CONFIG_USB_COMPOSITE_DEVICE=y

# -------------------------------
# File System (FAT FS)
# -------------------------------
CONFIG_FILE_SYSTEM=y                  
CONFIG_FS_FATFS_LFN=y                
CONFIG_DISK_ACCESS=y                 
CONFIG_FAT_FILESYSTEM_ELM=y           
CONFIG_DISK_DRIVER_FLASH=y            
CONFIG_FS_FATFS_MKFS=y                
CONFIG_FS_FATFS_MOUNT_MKFS=y        
CONFIG_FILE_SYSTEM_MKFS=y             

CONFIG_WATCHDOG=y

# Enable the Floating Point Unit
CONFIG_FPU=y
CONFIG_FP_HARDABI=y
CONFIG_NEWLIB_LIBC=y
CONFIG_SPEED_OPTIMIZATIONS=y
CONFIG_NRF_ENABLE_ICACHE=y

# (Optional) Enable FPU sharing if multiple threads use floating point math
# This prevents context switching corruption when threads share the FPU.
CONFIG_FPU_SHARING=y

CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n


CONFIG_NORDIC_QSPI_NOR_INIT_PRIORITY=90


# STEP 2.2 - Enable FOTA over Bluetooth LE
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Thu, 18 Jun 2026 08:46:09 GMT

ok thankyou , thanks a lot for early response

RE: BLE DFU nRF5280,nRF5340

Vidar Berg — Thu, 18 Jun 2026 07:39:17 GMT

Our SDK examples will typically spend >99% of the time in sleep (from the idle thread), and it is difficult to comment on why you are seeing the high cpu usage in your case without any details about your code. I would recommend you go through our devacademy course here: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-7-multithreaded-applications/topic/scheduler/.

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Thu, 18 Jun 2026 07:18:22 GMT

yes it works with by removing while();, ... when we look into real projects if main loop having more to excute alomst main only uses 98% of cpu cycles.. what we can do?

RE: BLE DFU nRF5280,nRF5340

Vidar Berg — Thu, 18 Jun 2026 05:49:24 GMT

I see the empty while loop you have in main() now. This will prevent other lower priority threads from running and it explains why the device is not responding to the mcumgr commands. Solution is to simply remove your while() loop and let the program exit the main thread.

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Thu, 18 Jun 2026 04:23:06 GMT

I think it is beacause of main thread using more CPU cycles...when i put delay to cpu idle , dfu working fine...

1. is there any solution / implementation methods for this instead of delay..?(except threads)

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Wed, 17 Jun 2026 11:55:36 GMT

RE: BLE DFU nRF5280,nRF5340

Vidar Berg — Wed, 17 Jun 2026 11:51:19 GMT

I meant to ask if you could provide debug logs from your nRF52 devices which you are trying to perform the dfu on.

RE: BLE DFU nRF5280,nRF5340

Macherla Swetha — Wed, 17 Jun 2026 11:48:33 GMT

same thing happens with "config_log" also

RE: BLE DFU nRF5280,nRF5340

Vidar Berg — Wed, 17 Jun 2026 11:41:27 GMT

Hello,

The log is only showing that the connection is terminated after what looks to be the "image list" command, but it does not give any indication of why. I think it would be more helpful here if you could get debug logs (CONFIG_LOG=y) from your DFU target.

Best regards,

Vidar