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!

[Erwin Rietveld]

Hello Vidar,

We made some progress with this project. We can successfully send the new image to slot 1 but when the image needs to be swapped, swap fails and the bootable, pending and permanent flags are set. See the attached screenshot.



Do you have any suggestions?

We've defined the partitioning of the internal flash in pm_static.yml now as well:

app:
  address: 0xc200
  end_address: 0x4c000
  region: flash_primary
  size: 0x3FE00
external_flash:
  address: 0x00
  end_address: 0x80000
  region: external_flash
  size: 0x80000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    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: 0x4c000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x40000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x4c000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x3FE00
  span: *id002
mcuboot_secondary:
  address: 0x00000
  device: W25Q16
  end_address: 0x40000
  region: external_flash
  size: 0x40000

[Vidar Berg]

Hello,

Maybe you have enabled it since, bu I see you did not have CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK selected in the bootloader configuration. This is required when using the SPI NOR driver. 

Have you tried enabling logging in the bootloader (increase CONFIG_LOG_DEFAULT_LEVEL) to see if here are any errors or warnings reported when the bootloader should be activating the new update (this will increase the memory footprint and may require you to allocate more space to the bootloader)?

Also, not directly related to the issue, but CONFIG_BOOT_MAX_IMG_SECTORS is currently set to 2048 in your config, which is too large and will result in an unnecessarily large image trailer. The min. number of sectors needed can be found by dividing the image slot size by the sector size: https://github.com/nrfconnect/sdk-mcuboot/blob/0e091c9a8d35cb7c8cacb66aacbea3623ee7fb8b/boot/zephyr/Kconfig#L10 

Best regards,

Vidar