đź«´ Build for XIAO & DFU

Products & Technology XIAO
, ,
1

Hi there,

SO this comes up enough it needs it’s own thread. It’s Generic enough to cover all the Realms of XIAO builds, OTA’s , DFU, MCUBoot… :+1:

Keep it relevant PLEASE or it will disappear ONLY warning :shushing_face:

Let’s GO!
GL :slight_smile: PJ :v:

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.

3

Hi there,

DFU, Device Firmware Update
Term is thrown around like it’s easy. I love the fact when done correctly ONE can have Crash-Proof DFU.

a couple of points.
:backhand_index_pointing_right: There is NO dedicated video for “single-slot BLE OTA DFU”
because Nordic explicitly teaches that:

  • Single-slot = Serial Recovery (UART/USB)
  • BLE OTA = Dual-slot required

:check_mark: BLE OTA DFU

  • Requires:
    • Slot 0 (running image)
    • Slot 1 (new image)
  • Then swap/overwrite

Nordic split this across lessons (not one single video):
DFU / Bootloader lesson series:

  • Lesson 9: Bootloaders & DFU/FOTA
  • Exercises:
    • UART DFU (single-slot concept)
    • SMP Server (BLE DFU, dual-slot)

:backhand_index_pointing_right: The BLE part is in:

  • smp_svr example (not labeled “single-slot” because it isn’t)

Single-slot DFU

  • Works with:
    • UART
    • USB
    • Serial recovery
  • Done inside MCUboot
  • Safe fallback always available

:cross_mark: BLE OTA + single-slot

  • Not supported in the standard flow
  • No rollback safety
  • No place to store new image

HTH
GL :slight_smile: PJ :v:

If you want BLE OTA DFU → you need two slots
If you only have one slot → you are doing serial DFU, not OTA

This is the closest direct reference from Nordic:

:backhand_index_pointing_right: DFU over UART – Nordic DevAcademy Lesson

From that lesson:

“Single slot support: Can use a single slot… reducing flash”
BUT
“Dual-slot setup is necessary… for wireless transport (Bluetooth)”

There is a hybrid approach (not in DevAcademy);
:shushing_face:

  • CONFIG_MCUBOOT_OVERWRITE_ONLY=y
  • App downloads image → overwrites itself

BUT:

  • No rollback
  • Risky
  • Not what Nordic teaches as standard
  • (more on the HACK method to follow) :wink: