USBを有効にする
2024/08/02
評価ボードnRF5340 MDBT53-1Mモジュールピッチ変換基板のボード定義ファイルを作り直そうとしている。 理由は ncs v2.6 以降で動かなかったためである。
ここ最近は、Partition Manager を使うために Thingy:53 のボード定義ファイルをベースにしようとしていた。 しかしどうしてもうまくいかないので、Partition Manager を使っていない nRF5340DK をベースにする方針に変更した。
というのが前回までのあらすじである。
MCUbootでUARTを有効にする
まだDFUはやっていないが、準備はしておきたい。 その前段階として、MCUboot から Serial Recoveryモードになれるようにしておく。
以前も同じようなことをやったが、あのときは GPIO のピンアサインを修正した。 今回は UART が有効になってなかったため、DTSファイルと Kconfigファイルを変更した。
評価ボードは UART用のピンが出ているわけではないので、LED とボタンを邪魔しなければどのピンでも良かった。
コードでいえばこの辺。
ボタン押下以外にもいくつかboot_serial_enter()が呼ばれる経路がある。
評価ボード手順ではボタンを押したまま起動すると USB経由でファームウェアの更新ができるようになっていた。
なので名前が「Serial Recovery」だが、ファーム更新もできるのだと思う。
上のcommitでは、ボタンを押したまま起動すると LED点滅しない。 なので Serial Recoveryモードになっているのだと思う。 確認のため、USB でできるようにしよう。
MCUbootでUSBを有効にする
正確には USB の CDC(Communication Device Class) ACM(Abstract Control Model)で、いわゆる USBシリアルというやつだ。 わざわざ FTDIのチップなどを外付けしなくても nRF5340 だけでできてしまう(コネクタはいるが)。
Exercise 2 – DFU over USB, adding external flash & custom keys
これと nRF5340DK, Thingy:53 のボード定義を見ながら変更していったのだが、リンクエラーが発生する。
ld.bfd.exe: zephyr\zephyr_pre0.elf section `noinit' will not fit in region `RAM'
ld.bfd.exe: region `RAM' overflowed by 8200 bytes
collect2.exe: error: ld returned 1 exit status
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x15000をchild_image/mcuboot.confに追加することは書いてあったがCONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=yはなかったので忘れていた。
なおCONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAMはprj.confの方である。mcuboot.confではダメだ。
あるいはボード定義ファイルの defconfig でもよかった。
DevAcademyではボード定義ファイルの方に書いていたのでそうしておこう。
CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAMはThingy:53しか見ていないが、なんでだろうか。 Nordicのサイトで検索してもnRF Connect SDK v2.3.0 Release Notesしか出てこなかった。もうちょっと大々的に宣伝した方がよいのではなかろうか。
ともかく、これでボタンを押しながら起動すると Windows から USB を認識するようになった。
mcuboot.confはいろいろ増えているが、Thingy:53のMCUboot設定ファイルを参考にした。
CONFIG_BOARD_SERIAL_BACKEND_CDC_ACMをコメントアウトしているのはThingy:53のKconfig.defconfigのため未定義になったからだ。
CONFIG_USB_DEVICE_REMOTE_WAKEUPは不要だろう。
CONFIG_USB_DEVICE_MANUFACTURERなどは文字列だから良いとしてCONFIG_USB_DEVICE_VIDやCONFIG_USB_DEVICE_PIDはThingy:53の値と同じだが実験中であれば使い回して良いのかな。
DevAcademyのExerciseでは、確かボタンを押さずに起動してもUSBデバイスとして認識していたと思う。
これはmain()などに何も書いていないからだ。
それはよいのだが、なぜか USBデバイス 2つ分として見えているのだ。
同じものを 2つ表示しているのではなく、ちゃんと別のものとして見えているようだ。
DTSファイルは cpuapp にしか追加していないので、cpunet が影響しているわけでもなかろう。
DTSファイルのchosenでzephyr,consoleとzephyr,shell-uartをコメントアウトしたが変わらず。
uart-mcumgrもコメントアウトしたが変わらない。ビルドエラーにもならないし、ボタンを押すと Serial Recoveryモードになるし。
DFU用とログ用で2つあるのでは？とCONFIG_LOG=nを設定したが変わらず。
CONFIG_MULTITHREADINGでもなかった。“Required by USB and QSPI”とあったから追加していたのだが、USBとQSPIの両方を使う場合だけ必要なんだろうか？
わからんな！
少し整理したこの状況で続けることにしよう。
ログを出してみよう
USBシリアルが有効になったのでログを出してみよう。
Lesson 4 – Printing messages to console and logging
アプリに追加しただけだが、ボタンを押さずに起動しても USBデバイスとして見えていた。
*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
メッセージはBOOT_BANNER_STRINGであろう。
boot_banner()はbg_thread_main()から呼び出されていて、その後にmain()を呼んでいる。
このmain()がアプリかMCUbootかがはっきりしない。
アプリのmain()にprintk()でログを吐くようにすると、バナーの後にログが出た。
あとはMCUbootのログが出せればわかるかと思ったが、MCUbootでのログの出し方が分からない。
また、アプリでUSBを有効にした場合と、MCUbootでボタンを押してUSBを有効にした場合では Windows から見た USBデバイスが違ったものとして認識されている。
USBシリアルでログを出す場合、PCがUSBデバイスを認識するまでの間に出力したデータは捨てられそうな気がしたのだが、そうでもないのか。
mcuboot.confにCONFIG_UART_CONSOLE=nを書くのが面倒だったから defconfig でCONFIG_CONSOLEとCONFIG_UART_CONSOLEを削除したらUSBシリアルからログが出力されなくなってしまった。
あれは”CONSOLE”らしい。
CONFIG_CONSOLEの説明を読んでも “console drivers” ではわからんよ。
ここが Nordic AI の使いどころか！
違ったようだ。