🫴 Build for XIAO & DFU

Products & Technology XIAO
, ,
2

First one.

from the other thread…

Hi there,

So are you having the Partitions, defined ? Looks like you are very close.
It’s the Boot that is FAILING, not the DFU (LOL :smile: Wait , your not there YET!).
usually means one of these:
The boot started, but it didn’t find the APP image was invalid, Was it signed?

Is this for the DK or the XIAO..
One has an external Flash, One DOES NOT … Oh the regret :face_with_hand_over_mouth: his is exactly why:

  • Nordic DKs → easy DFU
  • XIAO → tight squeeze

SO, some Background and context for this…

There is a required 1 slot OVERWRITE needed or something to that effect
for it to work. ( Boot source: none ) tells me that.

There is a DEV academy course on this, definitely worth the Run-through.

SOAP ON…

IMO, they bobbled the ball a bit on this, but in there defence the 20M wasn’t available then (more IO PINS) and in an effort to quiet the complaints about battery monitoring (a major for battery powered devices & wearables) They used the pins for the Voltage divider, and missed the MAJOR advantage the extra flash provides the Chip and the User options for DFU… Then there was size, would another chip fit under the SHEILD? Compromises were made :face_with_peeking_eye: I was PO’d the left out the RGB LED, I love that thing :heart_eyes:on the nRF52840..but I digress !

What to do?

So the “one-slot workaround” is not the normal answer for BLE OTA.

What single-slot is really for

Nordic’s docs note that single application slot / single app mode exists, but that mode is for cases where the application can only be updated by MCUboot serial recovery, not the normal slot-based OTA swap flow. Technical Documentation

single-slot / single-app → useful for serial recovery, not the usual Bluetooth OTA path
You can look up the the Reference Build flow for BLE MCUmgr DFU for Zephyr

You need to add the line that makes it build with the MCU boot in mind.

CONFIG_BOOTLOADER_MCUBOOT=y

make sure it’s signed, use a static partition map for either DK , or XIAO
“pm_static.yml”

The BLE OTA is limited to the FLASH size so keep that in mind if using XIAO (no external flash) It can work if the APP is small enough though.
If it won’t fit abandon BLE OTA and use serial recovery / single-app mode instead

Short Assessment …
Most likely:

  1. You enabled DFU config
  2. MCUboot got built/flashed
  3. The actual application was not properly built/signed for MCUboot
  4. Bootloader came up and found garbage or unsigned content in slot 0
  5. So it stopped with:
    Image in the primary slot is not valid

Bottom Line…
That boot log means MCUboot is running, but it cannot find a valid signed application in the primary slot. Enabling CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y alone is not enough. For BLE DFU you need to build the application with MCUboot support, use a proper static partition layout with image-0 and image-1, and flash a correctly signed image. On boards without external flash, BLE OTA only works if the internal flash is large enough for both slots. If there is not enough room, then the fallback is usually MCUboot serial recovery / single-app mode rather than normal Bluetooth OTA.

BLE OTA works well on the Nrf 52840 (has ext Flash) TWO SLOTS.. normal workflow.
Normal 2 Slot; conf

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_MCUMGR=y
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

CONFIG_IMG_MANAGER=y
CONFIG_STREAM_FLASH=y

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="MyDFU"

and build with SysBuild.

HTH
Gl :slight_smile: PJ :v:

The bigger trade-off, in hindsight, is flash. Additional onboard flash would have opened up far more robust DFU options and long-term flexibility for developers.
It was likely a set of reasonable engineering trade-offs at the time.