nRF Connect SDK:nRF7002DKでUSB DFU

真のUSB DFU #とは

かつてニセモノ(笑)のDFUの記事を書いたことがあります。今だから笑ってニセモノとか言えますが、これでも当時は必死に調べたんですよ！！！

ちなみにこの記事に出てくるdfu-utilの話をDevZoneで話したら「なんだそれ？Nordicが公式にサポートしているツールはmcumgrだけだ」みたいなことを言われて「ふぁーーーーーー！」となった記憶があります。

AIは相変わらずすごい、が……

AIが劇的に進化してコーディングにも普通に使えるようになりました。それからというもの「AIに聞けば何でも作れるじゃん」とか思っていましたし、実際に言っていた時期もありました(笑)。このあたりの記事ですかね。

たしかにそうだとは思うんですよ。Nordic AIなんてまさに聞けばズバリの回答をしてくれます。ただ、それだけだとその場限りでして、忘れてしまうものだから何度も同じことを聞くようになるんですよね。え？覚えろって？
カーナビ(Googleマップでも)全盛の時代にあなたは道を全部覚えられますか？僕は無理です(笑)

実装したい機能ごとの備忘録は必要

やっぱり備忘録は必要という結論になりました(笑)。
いや、だって何時間もかけてAIと壁打ちして調べてKconfig書いて実装したんだけど、次の日に見たら何が書いてあるのか分からないなんてことが普通に起こります、ええ。

知らないと聞きだすこと自体が難しい

これは備忘録の話にも通ずるところがあるのですが、知らないことを聞くことはできないのです。当たり前なんですけどね。例えば、これからnRF7002DKでUSB DFUを実装する手順を記載していきますが、nRF7002DKでDFUを実装するには外付けフラッシュROMが必要だなんて触ったことがない人は知らないですよね？先回りして「nRF7002でDFUを実行するためには外付けフラッシュROMは必要ですか？」なんてAIに聞くことができたら天才です。知らないことを聞くことはできません。
ちなみにかのRaytac(NordicのBLEモジュールを作っている台湾のメーカー)が作ったnRF7002の評価ボードですら初期バージョンには外付けフラッシュROMは搭載されていませんでした。多分、彼らでも知らなかったのだと思います。

現在販売されている評価ボードには搭載されています

でも……

誰かがまとめてくれていたら、ブラウザーで「nRF7002 DFU」と検索したらどうすればいいかが書いてあったら、もちろんそれを読むほうがいいに決まっていますよね。だからやっぱり必要なのです。

ということでまた少しずつ再開していきたいと思います。
もちろん僕の備忘録として、ですけど(笑)

nRF7002とは

nRF7002はいわゆるコンパニオンICという位置づけになるもので、nRF7002自体にはCPU(MCU)の機能がありません。nRF5340やnRF54Lxxの配下に置く形で使います。そのため、デバイスドライバー機能およびWi-Fiパッチ(nRF7002のROM修正パッチ)をファームウェアが全部持つことになりますが、当然ファームウェアのサイズが肥大します。最低限で組み込んでだいたい550KBくらいでしょうか。
過去の記事で何回もでてきますが、nRF Connect SDKでバックグラウンドDFUを実装する場合は必ずアプリケーションをデュアルスロットにしなければいけないため、MCU内蔵のフラッシュサイズは半分(約440KB)になってしまいます。これだけでもう「は？どうしろって言うんだ？」となるのが分かりますよね。

バックグラウンドDFUとはアプリケーションを動かしながら更新ファームウェアを書き込む方式です。
それに対して起動時に特定のボタンを押してブートローダーのDFUを起動するのがシリアルリカバリーと呼ばれるDFUです。NCS 3.xからはシリアルリカバリーのみ実装する場合はデュアルスロットでなくてもよくなりました。

デュアルスロットを外付けフラッシュに逃がすことができる

いつも不思議に思っていたのですが、Nordicの評価ボードにはSPIフラッシュROMが載っているんですよね。でも色々なサンプルプロジェクトを動かしてみても特に使われている様子もなく、何のために載っているのか全然分からなかったんですよね。nRF7002DKにも例外ではなくちゃんと載っていますし、しかもQSPIはnRF7002が使っているのでわざわざSPIM4に繋ぎ直してあります。(nRF52840やnRF5340の評価ボードはQSPIに繋がっています)
このSPIフラッシュの主な役目は、デュアルスロットにすると不足してしまうプライマリフラッシュROM領域(いわゆる内蔵フラッシュROM領域)のためにセカンダリスロットを逃がすための外付けフラッシュROMだったのです。

ゴン、お前だったのか、のノリで(笑)

さて実装するとすっか！

本当は少しずつ紐解いていきながら解説をしたいところなのですが、あまりにも膨大すぎてそんなことをすると多分1冊本が書けるくらいになってしまうので、厳選してこれだけは知っておいた方がいいというドツボにハマりそうなところだけ順番に解説したいと思います。

なお、最終プロジェクトは以下のgitリポジトリに置いてあります。

これらのドツボにハマったところをAIなしで全部解決できたら天才じゃないかと思いますｗ
もちろん調べればちゃんとドキュメントはありますけどね

シリアルリカバリーは非実装

ちょっと前にも出てきましたが、シリアルリカバリーというのはブートローダーにDFUの機能を持たせることでアプリケーションが文鎮化しても復帰できる機能のことです。全然関係ないですけど、英語圏ではBrickと言うそうです(笑)。
リリース後にそんなことが起きたら重大インシデントですし、そうならないためにデュアルスロット構成を取っているわけです。ですので必要になるケースは原則ないというのが建前上の話なのですが、もう一つ切実な問題があって、シリアルリカバリーを組み込むと当然ブートローダーのサイズが大きくなってしまいます。ブートローダーのサイズが大きくなると当然アプリケーション領域がその分だけ小さくなります。内蔵フラッシュROMの容量は変えられないので、nRF7002ではいっぱいいろんなものを組み込む必要がある関係上、何が起きるかというと普通にKconfigで組み込む機能を厳選するとかデバッグビルドができなくなるとかの制限が入ってきてしまいます。例えばベースとなるWi-FiのKconfigに加えてShellとWi-Fi Credentialsを組み込むだけでデバッグビルドはまあまあカツカツです。
ということもあって、ブートローダーはできるだけ小さくなるようにしています。

デバッグが終わって最後にシリアルリカバリーを付け加えるというやり方はありです。
ただしアップデートするときにまた外す必要がありますので個人的にはお勧めしません。

ble_coexサンプルプロジェクト

nRF7002を使うのであれば間違いなくBLEも同時に使うと思いますので、ble_coexというBLE/Wi-Fi共存のサンプルプロジェクトを使います。そのまま使えますが、もしWi-Fi接続をしたい場合はprj.confの

prj.conf

CONFIG_WIFI_CREDENTIALS_STATIC_SSID="Myssid"
CONFIG_WIFI_CREDENTIALS_STATIC_PASSWORD="Mypassword"

この設定にはご自分のルーターの設定を書き込んでください。

Wi-Fi接続しなくてもUSB DFUを動かすことはできます。

早速ビルドしてみると……

ターミナルのログにはこんなのが出ています。なお、デバッグシンボルありのビルドなのでサイズが大きくなりますが、実際のプロジェクト開発現場ではデバッグできないと非常に辛いので必須です。

[566/566] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      821508 B         1 MB     78.35%
             RAM:      363296 B       448 KB     79.19%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from C:/ncs_projects/_samples/ble_coex/build/ble_coex/zephyr/zephyr.elf for board: nrf7002dk
[11/20] No install step for 'ble_coex'   

おおっと！
すでに1MBのフラッシュROMの80%くらいを使ってしまっています。この状態でブートローダーを組み込んでデュアルスロットにしたら容量が不足するのは火を見るより明らかですが、何事もやってみないと分からないのでとりあえずやりましょう。(孫正義)

sysbuild.conf

#
# Copyright (c) 2024 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

SB_CONFIG_WIFI_NRF70=y
SB_CONFIG_BOOTLOADER_MCUBOOT=y

いざ、ビルド……やっぱりダメだったか(当たり前)

FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map C:/ncs_projects/_samples/ble_coex/build/ble_coex/zephyr/zephyr_pre0.map
cmd.exe /C "cd . && C:\ncs\toolchains\c1a76fddb2\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe  -gdwarf-4 @CMakeFiles\zephyr_pre0.rsp -o zephyr\zephyr_pre0.elf -L"c:/ncs/toolchains/c1a76fddb2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/thumb/v8-m.main/nofp" -lc -lgcc && cmd.exe /C "cd /D C:\ncs_projects\_samples\ble_coex\build\ble_coex\zephyr && C:\ncs\toolchains\c1a76fddb2\opt\bin\cmake.exe -E true""
c:/ncs/toolchains/c1a76fddb2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr_pre0.elf section `text' will not fit in region `FLASH'
c:/ncs/toolchains/c1a76fddb2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `FLASH' overflowed by 330500 bytes collect2.exe: error: ld returned 1 exit status ninja: build stopped: subcommand failed.

330K bytesくらいオーバーフローしてます、だそうです。

セカンダリスロットを外付けフラッシュへ！

以下のKconfigを追加します。新たに追加するものだけを記載しているので、前にあったものは消さないでください！

sysbuild.conf

SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
SB_CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y
SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
SB_CONFIG_NETCORE_APP_UPDATE=y
SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y

ちなみに何をしているかと言うと、上の2つは何となく分かる気がするのですが、それ以降の4つが割と謎です。ざっくり説明すると(chatGPT風)ネットワークコアをDFUでアップデートできるようにしているのですが、これがないと動的パーティションがうまく構成されなくてビルドが通りません。その場合もpm_static.ymlを記述すれば動くのですが、手順を説明している関係上できるだけpm_static.ymlなしでできるように進めていきます。

できるだけpm_static.ymlがないとは……そのうち意味が分かります。

続いてプロジェクト内のsysbuildフォルダの下に以下のファイルを生成します。ipc_radioフォルダと同じ感じでmcubootフォルダを作って、それぞれprj.conf, app.overlayという名称でもよいです。

僕は分かりやすさを重視してsysbuild直下にmcuboot.confやipc_radio.confを置くほうが好きですが、好みの問題です。
ipc_radio側はサンプルプロジェクトがそうなっているので手を加えません。

mcuboot.conf

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_NOR=y
CONFIG_SPI_NOR_SFDP_DEVICETREE=y
CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_NORDIC_QSPI_NOR=n
CONFIG_MULTITHREADING=y
CONFIG_BOOT_MAX_IMG_SECTORS=1024
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

mcuboot.overlay

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
};

これも何をしているのかざっくり説明すると(chatGPT風)、overlayのほうはブートローダーにフラッシュROMを認識させるためのDTSです。Kconfigのほうは、Nordic評価ボードではQSPIにフラッシュROMが接続されているのがデフォルトなのでmcubootもデフォルトでQSPIを見に行くのですが、nRF7002はQSPIにはnRF7002が接続されており、SPIM4にフラッシュROMが接続されています。そのため、mcubootに外付けフラッシュROMはQSPIではなくてSPIM4に繋がっていますよと教えています。

最後にアプリケーションにもフラッシュROMを認識させれば完了です。USB DFUなのでmcumgrを動かすためのCDC ACMも追加しています。

現時点ではまだCOMポートとしては認識されません。
prj.confにKconfigが必要です。

nrf7002dk_nrf5340_cpuapp.overlay

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
		zephyr,uart-mcumgr = &cdc_acm_uart0;
	};
};

&zephyr_udc0 {
	cdc_acm_uart0: cdc-acm-uart0 {
		compatible = "zephyr,cdc-acm-uart";
		label = "CDC_ACM_0";
	};
};

ビルドしてみます。

[7/7] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      821516 B     982528 B     83.61%
             RAM:      363296 B       440 KB     80.63%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from C:/ncs_projects/_samples/ble_coex/build/ble_coex/zephyr/zephyr.elf for board: nrf7002dk

さっきとは微妙に変わって、フラッシュROMのリージョンサイズが1MBではなく982528Bになりました。でもこれだけでは本当にデュアルスロットでビルドできているのか分からないですよね。なので、こういう時はMemory reportを見ます。ちなみに押してから表示されるまでまあまあ時間がかかります。

partitionsのタブを表示すると、external_flashは認識されており、デュアルスロットのセカンダリスロット側がフラッシュROM上にあることがちゃんと表示されています。ちなみにmcuboot_secondary_1というのはネットワークコアのデュアルスロット側です。サイズも0xf0000(10進数で983,040bytes)なので先ほどのビルド結果に表示された982,528bytesと一致していると言ってよいでしょう。

差の512bytesはおそらくmcuboot_padの512バイトだと思われます。

さらにWi-Fiパッチも外付けフラッシュROMへ

お前はいったい何を言っているんだ(ミルコクロコップ風・写真は省略ｗ)
nRF7002には駆動するためのベースとなるROMが内蔵されています。ただしROMなので不具合があったり機能を追加したいと思ってもファームウェアアップデートができません。そのため、nRF7002をビルドする時はアプリケーションコアにWi-Fiパッチという128KBのnRF7002用ROMデータがくっついています。nRF7002はこのWi-Fiパッチを起動時にロードすることで常に最新状態を保つことができますが、アプリケーションコアのビルドサイズを大きくしている要因でもあります。
外付けフラッシュROMがあれば、このWi-Fiパッチ部分を外付けフラッシュROM上に置くことができます。そうすることでアプリケーションコアの容量が128KB丸々減ることになります。今、サンプルコードを全くいじっていない状態で820KBあるので、ここから128KB減れば相当余裕ができます。

ただ、体感ですが若干起動に時間がかかるようになる気はします……。誤差かも知れませんが。

Wi-Fiパッチを外付けフラッシュROMに移動させるのは必須ではないです。ただ、DFUのために外付けフラッシュROMが付いているので、やっておいたほうが内蔵フラッシュROMを圧迫しません。
Wi-Fi関連のAPI(Kconfig)はどれもROM使用量が大きいです。

Wi-Fiパッチを外付けフラッシュROMへ！

最初に断っておきますが意味不明なくらい難関だらけです。AIがなかったら絶対に実装できなかった自信がありますｗ

Wi-Fiパッチを外付けフラッシュROMに移動させるには以下の設定を追加します。SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGESは先ほどまでは2だったのですが、3つ目のイメージとしてWi-Fiパッチが追加されるので3に書き換えます。

sysbuild.conf

SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=3
SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE=y

いざビルドすると……

C:/ncs/v3.1.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:21:37: error: 'PM_MCUBOOT_PRIMARY_2_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_1_ID'?

なんだこりゃ……？何を言っているのか意味が分かりませんが、これは要するにWi-Fiパッチ用のパーティションが見つかりませんよというエラーを出しています。最初の方で

できるだけpm_static.ymlなしでできるように進めていきます。

と書いたのはそういうことでして、ここで初めてpm_static.ymlが必要になります。

pm_static.ymlとは

パーティションの定義をするファイルです。プロジェクトフォルダーのルートに入れるのですが、ない場合はビルド時にコンパイラーが勝手に生成します。buildフォルダの中にあるpartitions.ymlが自動生成されたファイルで、pm_static.ymlはこのファイルをベースに(＝コピーして)作ります。

ということでこのファイルをプロジェクトルートにコピーしてpm_static.ymlに名前を変更します。そして中身を覗いてみると……

app:
  address: 0x10200
  end_address: 0x100000
  region: flash_primary
  size: 0xefe00
external_flash:
  address: 0x150000
  end_address: 0x800000
  region: external_flash
  size: 0x6b0000
  ...
  (省略)

確かに先ほどエラーに出ていたmcuboot_primary_2というのはなさそうです。sysbuildのKconfigを追加したら自動的にパーティションを作ってくれればいいのですが、SDK 3.1.1の時点ではそのような仕様になっておらず手動でパーティションを指定する必要があります。

例えばCONFIG_NVS=yを指定するとstorage_partitionなるものが勝手に作られたり、CONFIG_BT_SETTINGS=yを指定するとsettings_storageなるものが作られたりと、自動的にパーティションを生成するKconfigもいっぱいあります。

nrf70_wifi_fwパーティションの上に以下のパーティションを追加して、さらにnrf70_wifi_fwのアドレスを変更します。nrf70_wifi_fw_mcuboot_padというのはブートローダー用の領域でDFUを実行するために必要な領域です。

pm_static.yml

mcuboot_secondary_2:
  address: 0x150000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x170000
  region: external_flash
  size: 0x20000
mcuboot_primary_2:
  address: 0x000000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  orig_span: &id003
    - nrf70_wifi_fw_mcuboot_pad
    - nrf70_wifi_fw
  region: external_flash
  size: 0x20000
  span: *id003
nrf70_wifi_fw_mcuboot_pad:
  address: 0x000000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x000200
  region: external_flash
  size: 0x200
nrf70_wifi_fw:
  address: 0x200 ← 0x0を修正
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x20000
  placement:
    after:
    - settings_storage
  region: external_flash
  size: 0x1fe00 ← 0x20000を修正

さらに未使用領域として一番上に定義されているexternal_flashパーティションを修正します。ちなみにこの未使用領域を定義している部分はなくてもよいです。

pm_static.yml

app:
  address: 0x10200
  end_address: 0x100000
  region: flash_primary
  size: 0xefe00
external_flash:
  address: 0x170000 ← 0x150000を修正
  end_address: 0x800000
  region: external_flash
  size: 0x690000 ← 0x6b0000を修正

やっとビルドが通るようになりました。ビルド後のROMサイズも128KB減っ……てないやん！！！76KBほどしか減っていません。AIによると外部フラッシュROMから読み出すためのコードが増えたりして純粋に128KB減るわけじゃないんだよとのことです。そりゃそうか。

Memory region         Used Size  Region Size  %age Used
           FLASH:      745652 B     982528 B     75.89%
             RAM:      363544 B       440 KB     80.69%
        IDT_LIST:          0 GB        32 KB      0.00%

ここで一旦書き込んでみましょう(フラグ)

Flashボタンをポチっとな。
残りのビルドが走って書き込みが実行されます。

WARNING: Specifying runner options for multiple domains is experimental.
If problems are experienced, please specify a single domain using '--domain <domain>'
-- west flash: using runner nrfutil
-- runners.nrfutil: reset after flashing requested
-- runners.nrfutil: Flashing file: C:\Users\YoshihiroGoto\ncs\ble_coex_usb_dfu\build\merged_CPUNET.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Erasing address ranges touched by firmware
-- runners.nrfutil: Programming image
-- runners.nrfutil: Verifying image
-- runners.nrfutil: Reset
-- runners.nrfutil: Board(s) with serial number(s) 1050794415 flashed successfully.
-- west flash: using runner nrfutil
-- runners.nrfutil: reset after flashing requested
-- runners.nrfutil: Flashing file: C:\Users\YoshihiroGoto\ncs\ble_coex_usb_dfu\build\merged.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Erasing address ranges touched by firmware
-- runners.nrfutil: Programming image
-- runners.nrfutil: Verifying image
-- runners.nrfutil: Reset
-- runners.nrfutil: Board(s) with serial number(s) 1050794415 flashed successfully.

無事書き込まれました、めでたしめでたし(？)
試しにターミナルで外付けフラッシュROMを読み込んでみると

PS C:\Users\YoshihiroGoto\ncs\ble_coex_usb_dfu> nrfutil device read --address 0x10000000 --bytes 16 --width 8
1050794415
0x10000000: 3D B8 F3 96 00 00 00 00 00 02 00 00 54 4F 01 00   |=...........TO..|

ちゃんと書き込まれているのが分かります。
……？
フラグってなんだよ！って思ったそこのあなた、するどいです。実はここにも色々とトラップが仕掛けられています。

DKには特別な設定なしで書き込める

またまた出ました。お前はいったい何を言っているんだ(ミルコクロ略
機会が来たら別途記事を書こうと思いますが、カスタムボードにはさらに設定が色々と必要になります。現時点までの手順ではは動きません。でもAIが回答してくれるのできっと大丈夫です(笑)。

いざ、USB DFU……の前に

と思ったのですが、mcumgrをアプリケーションコアに組み込む部分をすっかり忘れていました(笑)。さらに最初にUSB CDC ACMポートを追加したのにUSBデバイスとして動かすKconfigもないです。

prj.conf

CONFIG_FLASH=y
CONFIG_ZCBOR=y
CONFIG_CRC=y
CONFIG_BASE64=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUMGR=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_TRANSPORT_UART=y
CONFIG_STREAM_FLASH=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=y

prj.confにこれらのKconfigを追加します。

なぜ設定が変わらないのだ……？

prj.conf上でよくこんな表示を見かけることがあります。

prj.confでyって書いているけれど、このビルド結果ではnになっているよ、という類の警告が表示されることがあります。そもそもこのKconfigをKconfig GUIでいじろうと思ってもグレーアウトしていることも多いです。

これはいったいなんなのか？

本筋と話が逸れてしまうので別記事に移したほうがいいのかも知れませんが、かいつまんで説明すると「Kconfig GUIをはじめとする全てのVSCode拡張は、ありとあらゆる設定を網羅できるわけではなく、参照できない位置にある設定は反映されない。その結果としてGUI上でグレーアウトすることがある」
というものです。
NordicのスタンスもGUIツールはあくまで補助的な位置づけであり、これ一つで全てが網羅できるものではないと言っています。

ですので、最後の最後で手書きは必要です(笑)。

ではどうすれば……？

最終的にどうなっているかは、/build/projects/zephyr/ に生成される.configを見ると分かります。

この中に全てのKconfigが記載されるので、開いて先ほどのKconfigで検索をかけると分かります。ちゃんとyになっていますね。

今度こそUSB DFU

やっとmcugmrを使ったDFUが動かせます！
mcumgrはNordicが正式にサポートしているものですが、正直AIなしでここまで辿り着ける人ってほとんどいないのではないかと思います。以前に僕が書いた記事のようにdfu-util(非公式)に引っかかる人もまあまあいると思います。
コマンドプロンプトからmcumgrを実行します。

ちゃんとイメージスロットが見えています。image=0はアプリケーションコア、image=2はWi-Fiパッチです。ちなみにimage=1(ネットワークコア)がないのは、ネットワークコアはRAM上で動いているからだそうです。

正直、いまいちよく分かっていません……。

さっそく試しにビルドしたフォルダのイメージをアップロードしてみましょう。なお、USB DFUで使うイメージファイルはzephyr.signed.binというファイルです。BLE DFUで使う.hexではないので注意が必要です。

無事書き込みが終わったのでもう一度イメージのリストを見てみると

image=0のslot=1が表示されました。ちゃんと書き込まれています。ただ、ハッシュ値が同じことからも分かるように全く同じものが書き込まれているのでDFUの意味はないですが……。

アクティブイメージを切り替える

USB DFUではイメージを書き込むだけでは自動的に切り替わりません。コマンドを打って自分で切り替える必要があります。BLEと同じように一度だけ試して元に戻したい場合はtestで、もう切り替えるのを決定するのであればcofirmで切り替えるハッシュ値を指定します。

詳しいことはmcumgr --helpで確認してください。

このテストでは全く同じハッシュ値なので切り替わりませんが、通常は違うハッシュ値になっているので切り替わります。

捕捉

一番複雑なnRF7002系でのUSB DFUです。
nRF5340やnRF52840では外付けフラッシュが必要になるケースはあまりありませんが、同じように外付けフラッシュを付けることで内蔵フラッシュをフルに使うことができるので、大きいアプリケーションを作る際には必要になります。
また、NVSやsettings_storageのパーティションを大きく取りたい場合にも外部フラッシュを実装してその上にパーティションを作ることでアプリケーションの内蔵フラッシュ領域を大きくすることもできます。