hiro99ma blog

何か技術的なこと

DevAcademy

2024/07/18

いまさらだが、nRF Connect SDKのDevAcademyを最初からやった方がいいんじゃないかという気がしている。 あまりにも知識が足りないので、途中からやるものではないと気がついたのだ。

nRF Connect SDKに関しては2つコースがある(2024/07/17現在)。

いままでMCUbootで見ていたのは”Intermediate”の方だ。”Learning Paths”によると、最初は “nRF Connect SDK Fundamentals”をやったあと、自分がやりたいことによってどれかの Fundamentals をやり、最後に”nRF Connect SDK Intermediate”をやるものらしい。

image

タイトルを見る限り、main()まで到達できるボードがないとつらそうだ。 そのために nRF5340DK のような標準開発ボードを用意しているのだろうが、nRF5340 MDBT53-1Mモジュールピッチ変換基板を買ったのでわざわざ買い足したくない。

しかしMDBT53ボードで提供された定義ファイルを使うと ncs v2.6 からはサンプルアプリが起動しないので MCUboot のことを調べているという次第である。 ブートローダの途中でFlash Areaの取得に失敗をしているのか、エラーになっているためだった。

nRF5340DKの定義ファイルを使うとmain()まで起動するのだがGPIOの割り当てが違うのでLEDやボタンが作動しない。使えるようにするにはDTSファイルの上書きがいる。 MDBT53ボードの定義ファイルはThingy53をベースにしているが、これもMDBT53とはGPIOのアサインが違う。 nRF5340DKは64MB外部Flashがあるし、Thingy53も同様だ。

ならば QSPI を無効にして chosen からも削除すればよいのでは？

Visual DeviceTree EditorのQSPIを右クリックすると「Enable Peripheral」と出てくるから現在はDisableになっているように見えるのだが、どれを見ても同じなのであまり関係ないのか。

image

サイドバーの方で”qspi”を検索すると、ツリー表示の方にはチェックが入っていたので外した。 そうすると overlay ファイルの方には “disable” が追加された。

image

chosenからも削除。

image

問題はMCUbootの方で、こちらはflash_sim.overlayというファイルを参照している。 Build Configurationの編集画面では”Extra CMake arguments”で-Dmcuboot_DTC_OVERLAY_FILE="C:/ncs/v2.6.1/nrf/modules/mcuboot/flash_sim.overlay"のように設定されていた。

image

では別のoverlayファイルを作ってBuild Configurationを書き換えれば良いかというとそうでもないようで、変更してビルドするとまた書き換えたパスが元に戻っているのだ。 これはどうも、初回の Build Configuration 作成時に設定したものが使われるようだ。ということはプロジェクトではなくビルドした設定の中にしか入っていないのか。

ビルドするとbootloaderのところでerror: 'PM_MCUBOOT_SECONDARY_ID' undeclaredのようなエラーが出てしまう。 Kconfigで検索するとこれらにチェックが入っていたので外す。

image

これを保存しようとすると ncs の下のファイルに保存しようとしてしまうので、プロジェクトに child_image/mcuboot.conf を作る。 -Dmcuboot_OVERLAY_CONFIGを追加。 なお元々mcuboot_OVERLAY_CONFIGは複数のconfが設定されていたのだが、初回の追加は自分のconfファイルだけ追加しておけば良い。ビルドしたら自動で他のconfも追加されていた。

image

が、これでもエラーになる。

よくソースコードを見ると、エラーになっているのはここなのだが、PM_MCUBOOT_SECONDARY_IDを使っているのは#ifdefも#elseも同じなのでもっと前の方で無効にしないといけない。 となるとCONFIG_SINGLE_APPLICATION_SLOTを定義すればよいということになる。

これで Pristine Build すると error: Aborting due to Kconfig warnings が出ていた。 以前からwarningはいくつも出力されていたが、abortまではいわれてなかったと思う。 だいたい、ビルドもerrorになった時点で止めてくれれば良いのに

CONFIG_SINGLE_APPLICATION_SLOT=yにしたけど、これは外部Flashとは関係ないな。 ブートローダのアップデートを元に戻せるように2セット(2スロット)にするだけだったのだと思う。

DevAcademy - MCUboot, and relevant librariesにmcubootのprimaryとsecondaryというスロット名が出てくる。 CONFIG_BOOTLOADER_MCUBOOT=y(追加するのはMCUbootのKconfig設定)を設定すると、1スロットだけが”child image”として追加される。 追加しただけではDFU機能はがない。デフォルトでは mcuboot_primary と mcuboot_secondary の dual slot になる。 図を見ると、”mcuboot”(青), “mcuboot_primary”(緑), “mcuboot_secondary”(赤) の3領域ある。 次の項目ではnRF53のためにnetwork coreと並んだ図があるが、”mcuboot_“とついているものの中にアプリコアを含んでいる。 なので”mcuboot_“というプレフィクスはあるが実際はアプリコアということだ。 Simultaneous multi-image DFU with nRF5340 DKによるとこうだ。

dual slotと似たような感じがするのがmulti-imageだが、これはアプリとブートローダを1つのimageファイルにしている。 ブートローダの方が”child image”になる。
child imageの種類は、CONFIG_BOOTLOADER_MCUBOOTにするとMCUbootになり、CONFIG_SECURE_BOOTにするとNSIB(Nordic Secure Immutable Bootloader)になる。

nRF53はアプリ用と通信用の2コア構成で、プログラムもそれぞれ別になっている。 それらのプログラムを同時に更新するのが”simultaneous update“だとか”simultaneous multi-image update”だとか呼ぶものである。 同時にアップデートするなら1つのイメージファイルにまとめるので必然的にmulti-imageになるのかな？ ネットコアの更新には PCDドライバがいるらしい。CONFIG_PCD_APPがそれか。

そしてこの図を見ると、同時に更新する場合は外部Flashが使われている。 MDBT53には外部Flashがないので同時アップデートはできないことになる。

overlayで変更するのは面倒なので、提供された設定ファイルssci_mdbt53_dev_board_cpuapp.confを直接いじることにした。 DeviceTreeの設定もssci_mdbt53_dev_board/ssci_mdbt53_dev_board_common.dtsを直接編集する。 これで Build Configuration を作成し直すときも特に編集せずに済む。

あれこれやってKconfigのエラーはなくなった。設定が正しいのかどうかは分からん。 次はGenerating ../../zephyr/net_core_app_signed.hexでこんなエラーが出る。

FAILED: zephyr/net_core_app_update.bin xxxx/build/zephyr/net_core_app_update.bin

これはimgtool.pyというコマンドの--slot-sizeというオプションに値がないためだった。 たぶん変数か何かに入っているべき値がないのだろう、次のパラメータまでのスペースが2つ空いていた。 これは自動で指定ではないのか？

うーん。。。

< Top page