DFU via BLE using external SPI flash on nRF52832

Hi,

We’re working on a device using the nRF52832 and have DFU over BLE working correctly using internal flash. Updates work both via our custom app and the nRF Connect app.

Due to the application’s size, we now want to use external SPI flash (W25Q16JV) to store the firmware during the update process. We believe our partitioning is configured correctly (see attached memory report screenshot), and we’ve integrated the external flash into the devicetree (via overlay) and enabled it in the build.


However, the update process shows strange behavior:

  • When loading the dfu_application.zip in the nRF Connect app, it instantly jumps to 100%, without transferring any actual data.

  • No error is shown, but clearly the update isn’t happening.

It feels like the DFU target accepts the file but doesn't actually write it to flash. I’m wondering if something is misconfigured in the mcuboot setup or the flash map, or if I'm missing a key step to get mcumgr to write to the external flash partition.

Platform details:

  • SoC: nRF52832

  • External flash: W25Q16JV

  • Zephyr SDK: v2.4.1

  • MCUBoot: enabled with BLE and DFU via smp_bt

Has anyone encountered similar behavior or knows what part I might be missing?

I've attached the relevant files.

Project tree:


├── CMakeLists.txt
│   └── arm
│       ├── my_board
│       │   ├── Kconfig.board
│       │   ├── Kconfig.defconfig
│       │   ├── board.cmake
│       │   ├── my_board.dts
│       │   ├── my_board.dtsi
│       │   ├── my_board.overlay
│       │   ├── my_board.yaml
│       │   ├── my_board_defconfig
│       │   └── my_board_flash.overlay
│       

├── child_image
│   └── mcuboot
│       ├── boards
│       ├── mcuboot.conf
│       └── mcuboot.overlay
├── dts
│   └── bindings
│       └── pwm-vibration.yaml
├── libs
│   ├── bluetooth
│   │   └── [...]
│   └── devices
│       ├── [...]
├── prj.conf
├── sample.yaml
├── src
│   ├── DeviceInfo.hpp
│   ├── FSMStates.hpp
│   └── main.cpp
└── utils
    ├[...]

my_board_flash.overlay

8132.prj.conf

0207.mcuboot.overlay

1351.mcuboot.conf

Thanks!

Parents Reply Children
  • Hello Erwin,

    Thanks for the additional info. The slot readout shows that there is another FW image in the secondary slot marked as "pending" (different from the FW image you are trying to upload). I wonder if the issue is that the bootloader is not activating this update therefore causes the slot to remain in this state (slot can't be overwritten by another image when in the pending state). If you reboot the device (either by power cycling or resetting it) and then read out the slot again, does it still show as pending?

    Please also note that it is not possible to change the memory layout through DFU as mentioned here: "Static partition requirement for DFU". Doing so may lead to the same symptoms as you are observing.

    Best regards,

    Vidar

Related