MCUboot (6)

2024/07/16

評価ボードnRF5340 MDBT53-1Mモジュールピッチ変換基板が自分でビルドしたアプリを焼くと動かない件の調査である。

• MCUboot (1)
• MCUboot (2)
• MCUboot (3)
• MCUboot (4)
• MCUboot (5)

簡易まとめ

• DevAcademy Lesson 8-2 を MDBT53 用に書き換えてmain()は起動するようになったが Serial Recoveryモードにならない
• ncs は v2.6.1 に変更した
  • なぜか v2.7.0 で APPLICATIONS から mcuboot を選択するとおかしくなるのでやむなく。

MCUbootというタイトルだが、Serial Recoveryに入れない件を調べているだけである。

DevAcademyの続き

引き続きinter_less8_exer2_solutionを見ていく。

MCUbootでボタンを押す押さないにかかわらずdetect_pin()に入っていることは分かった。

gpio_pin_get_dt()が呼ばれているのだが、戻り値rcは最適化されていてデバッガで見えない。 AAPCSによるとレジスタr0が戻り値と思っていて良いだろう。 そしてr0=0。

となるとbutton0がGPIO P1.10になっていないのだろうか？

button0の値は上の画像に見えるとおりなのだが、値を見てもよくわからない。 前回 GPIO をたたくだけなのに関数でいろいろ処理があるというようなことを書いたが、GPIO の設定が既に大変だ。 ああいう形にしないと間違った設定のチェックはできない気がする。

GPIOの説明を読む。
GPIOは32本あるが、物理的なピンとしてはP0.00-P0.31、P1.00-P1.15までで他の機能との兼用になっている。 ボタンはP1.10に割り当てられているが、これは物理的なピンである。これがGPIOのどれに相当するかはどうやって決まっているのだろうか？ Devicetree Visual Editorでも物理的なピンの設定をしただけでGPIOの割り当ては行っていないので、何か決まりがあるはずだ。

P0やP1が出てくるのはRegistersか。 nsかどうかでP0かP1かが決まってくるのか。。。

• PINの割り当ては以下に対して可能
  • Application core
  • Network core
  • Peripheral with dedicated pins
  • Trace and debug(TaD) subsystem
• デフォルトはApplication core PIN_CNF[n]のMCUSELビットフィールド

これは深く考えず、例えばP1.10をGPIOとして使用したらP0.10はGPIOとして使用できない、ということでよいのかな。 ならばデバッグで取得したpin=23、つまりP0.23を見ているということだろうか(P1.23は存在しないので)。

確かに、nRF5340DKのbutton0はP0.23だった。 つまり、MCUbootの中ではまだnRF5340DKの設定を見ているということか。 main()ではボタンが有効だったので、app.overlay以外となるとchild_image/mcuboot.overlayくらいしかない。

child_image/mcuboot.overlayに以下を追加して Pristine Build。 Flashして焼き、ボタンを押したまま起動すると LEDが点灯したままになった。 Serial Recoveryモードになったと考えて良かろう。

&button0 {
	gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
};

&led0 {
	gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
};

長かったー。 設定し直したときのpinはちゃんと10になっていた。実際にどうなっているかはPIN_CNF[10]を見ないと分からないのかな。 configが<gpio_nrfx_p0_cfg>から<gpio_nrfx_p1_cfg>になっているので、そこで判定して良いのか

とはいえ、ようやくスタートに立ったくらいのところである。先は長い。