DFU via BLE using external SPI flash on nRF52832

[Erwin Rietveld]

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!

[Vidar Berg]

Hello,

As far as I know, the only time the upload can be skipped without any errors is if an image with the same hash already exists on the target device.  Please try our Device Manager which supports more mcumgr commands (available on both iOS and Android) and switch to the 'Advanced' view for image management. Then click the 'Read' button to get the slot information to see if this could be the case.

Best regards,

Vidar

[Erwin Rietveld]

Hello Vidar,

Thank you for your reply. I downloaded the Device Manager app. You can see the 'Read' results in the screenshot. 



When I try the DFU, the state jumps to 'No entry'. Based on this information, do you have an idea of what might be the issue here?

Best,
Erwin

[Vidar Berg]

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

[Erwin Rietveld]

Hello Vidar,

Thank you for your message. I've grabbed another fresh device and the transfer of the FW seemed to work. However, after rebooting the device, it got stuck in the same state. 

I initially flashed the device with the programmer and implemented static partitioning. pm_static.yml:

external_flash:
  address: 0x74000
  end_address: 0x200000
  region: external_flash
  size: 0x18c000

mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x74000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0x74000

mcuboot_secondary matches the size of mcuboot_primary, which is also visible in the screenshot of the memory report I shared earlier. 

Since I'm unable to erase slot 1, the device is bricked for DFU for now. I guess the challenge now is to figure out why it gets stuck on pending and why the FW isn't swapped. Any ideas on how to approach this?

Thanks,
Erwin

[Vidar Berg]

Hello Erwin,

As long as the bootloader and all application versions are built with the same memory layout, I don't see how you could end up in this state. However, the pm_static.yml file you posted only defines the partition layout in external flash so it is still possible for the dynamic partitions in internal flash to become changed. To ensure the start address of the primary slot remains consistent as well, please use the generated partitions.yml file from the build directory as your pm_static.yml file, and make sure it is used in all builds.

Thanks,

Vidar