MCUboot (6)
2024/07/16
評価ボードnRF5340 MDBT53-1Mモジュールピッチ変換基板が自分でビルドしたアプリを焼くと動かない件の調査である。
簡易まとめ
- 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>
になっているので、そこで判定して良いのか
とはいえ、ようやくスタートに立ったくらいのところである。先は長い。