mbed Advent Calendar 2014の11日目です。
まえおき
mbedとの関わり
現在私はmbedのプログラムを
アセンブリ言語でコードをゴリゴリ実装して、バグを作っては治すを繰り返す日々をおくっています。
デバッガは必須
アセンブリ言語はCに比べて低級な言語なので、コーディング中に混乱して、バグを作ることが多いです（主観的発言）。
よくあるバグとしては、メモリ破壊、スタック破壊、リターンアドレスのpop忘れ、etc……。
簡単なデバッグ方法としてはprintfを用いたデバッグがありますが、今回はアセンブリで実装しているため、printfを挟むのは少々コストが大きいです。
そこで活躍するのがデバッガです。
このデバッガがあれば、プログラムを1命令ごと、レジスタの値を監視しながらデバッグすることができます。
これによりprintfでは調査しづらい細かな処理を追うことが可能となり、デバッグの効率を格段に上げることができます。
よって、デバッガは必須なのです。
mbedの一部の製品には、メインのマイコンの他に、mbed interfaceと呼ばれる機能を持ったマイコンがついています。
このmbed interfaceはCMSIS−DAPデバッガとしての機能を持っているため、このmbed interfaceを持った一部の製品は、それ単体でデバッグを行うことができます。
※ CMSIS-DAPの説明は特殊電子回路株式会社さまの「CMSIS-DAPって何？」を参照してください。
前置きが長くなりましたが、本題です。
Macでmbedのデバッグを行いましょう。
プログラムのエクスポート
mbedはプログラムをオンラインでコンパイルするという、画期的なシステムを採用しています。
しかし、このオンラインのシステムはコンパイルは出来ますが、デバッグを行うことができません。
デバッグのためにはオンラインのコードをローカルに保存し、オフラインコンパイル環境を用いる必要があります。
この方法については以下のページを参照し、「Exporting to GCC ARM Embedded」でGCC用のコードをエクスポートしてください。
私は普段はMac OS Xを用いています。Windows機も所持していますが、もっぱらゲーム専用機としてしか使っていません。
残念なことに、ARM社謹製の統合開発環境 MDK-ARMは、現状Windows専用ソフトウェアです。
そのためMac環境ではライセンス料が云々の前に、使うこと自体ができません。
それでもなんとかMacで開発を行うため、GNUのフリーな環境を用いて開発環境・デバッグ環境を整えます。
その方法は以前ブログ記事にまとめたので、こちらを参照してください。
Tips: GNU開発環境でのアセンブリ利用時の注意
GNUな開発環境とMDK-ARMでは、アセンブリコードの書き方が異なるため、アセンブリコードの互換性がありません。
そのため、アセンブリで開発する際は、デバッガの使えないオンライン上で完結させるか、WindowsでMDK-ARMを用いて開発を行うか、もしくはオンラインへ戻ることを諦めてGNUな書き方を行うかを判断する必要があります。
私は青mbedのプログラムフラッシュが豊富であり、MDK-ARMを用いずともメモリが足りているので、GNUなツールで開発することにしました。
オンラインへの復帰は、開発が完了した後に手動でアセンブリコードを書きなおして行う予定です。
GDBの操作方法（簡易説明）
GDBを用いてデバッグする方法を、簡単に説明します。
GDBサーバーへの接続
(gdb) target remote localhost:3333
プログラムのmake
(gdb) make
プログラムのロード
(gdb) load
なお、以前ロードしたプログラムと新しくロードするプログラムに差異がある場合は、後述のdisplayの設定が削除されます。
breakpointの設定は残ります。
状態の表示
displayコマンドを用いると、レジスタやメモリの値を逐次表示することができます。
自分のおすすめは以下。
(gdb) display/i $pc
(gdb) display/x $r0
(gdb) display/x $r1
(gdb) display/x $r2
(gdb) display/x $r3
(gdb) display/x $r4
(gdb) display/x $r5
(gdb) display/x $r6
(gdb) display/x $r7
(gdb) display/x $r8
(gdb) display/x $r9
(gdb) display/x $r10
これでプログラムカウンタの指すアセンブリコードを表示しつつ、レジスタr0~r10までの値を１６進数で確認できます。
再実行
(gdb) continue
プログラムカウンタの指す場所から処理を再開します。
後述のbreakpointに引っかかるまで止まらないので注意してください。
強制的に止めたい場合はCtrl+Cを入力します。
breakpoint
(gdb) breakpoint *0x0000a410
特定のアドレスにbreakpointを仕込んで、その位置で処理を止めることができます。
上記のコマンドでは、プログラムカウンタがメモリアドレス0x0000a410になった時、処理を止めることができます。
なお、本来condition等を用いれば変数の値が変化した際に止める……ということができますが、pyOCDの環境で使ったらpyOCDがハングしました。
再現性の確認等ができていないので、バグ報告は行えていません。
１命令実行
(gdb) stepi
(gdb) nexti
アセンブリでは１命令ごと実行する必要があるため、
C言語のstep命令はstepi、next命令はnextiとなります。
おわりに
以上、Macでmbedをデバッグする方法についての簡易デバッグ説明でした。
デバッグ時にgdbサーバーを建てるため使用したpyOCDをもう少し活用すると、より柔軟なデバッグも可能ですが……今回はここまで。
要望があれば、PyOCDを使ってHard Fault原因を探る方法を、再度advendカレンダーに書こうかとおもいます。
緩募
- ARMマイコン発売から現在までのシェア情報の書かれた資料
- mbed発売から現在までのシェア情報の書かれた資料
次の人
次はjksoftさんです。よろしくおねがいします。
