昨日の書き込みで、GDBがステップ実行されない件について書いたけど、どうも気持ち悪いの引き続き調べてみた。
原因は、リモートデバッグの's'コマンドに対して、ブレークしたときにはSIGILLではなく、SIGTRAPを返さないといけないようだ。そんなこと、どこに書いてある？！いちおうGDBのマニュアルとか読んでみたんだけどなー。

実際には、これに気付く前から's'で止まったときにはSIGTRAPをつもりで作ってはいた。しかし、うまく動いていなかっただけだった。ターゲットのARMのマニュアルを見直してみると、BKPT命令はデバッグモニタ割り込みではなくて、HardFault割り込みで実行される＜ことがある＞らしい。ってか、レジスタをいじってBKPTがデバッグモニタ割り込みで動作するように切り替えないといけなかったらしい・・・。そんな落とし穴・・・簡単に気付くかよ！ってんだ。

タイトルに「健忘録」という言葉を使ってみたが、嫁にそれはちょっとおかしい、[ぼうびろく]じゃないかと突っ込まれた。
調べてみると・・・・、正しくは

　[びぼうろく]（備忘録）

というのが一番正しいらしい。
でもどうやら一概に間違いだと切って捨てるにはまだ早いかもしれない。Google先生によると、

　備忘録＞＞忘備録＞健忘録

の順でそれなりの数でhitする。ま、もちろん備忘録がダントツに多いわけだが・・・。

なんだか恥ずかしい。
でも言葉なんて生き物、使い続ければそれが一番正しいってことになるかも知れない。ガンバレ、「健忘録」族！（なんて、強がりです・・・）

ARM thumb2(Cortex-M3)開発環境構築

かなり手こずった。

C級出版の付録Cortex-M3開発ボードを手にして、直ぐに具体的な開発（という名のお遊び）に取りかかれると思ったのに、意外と大変だったワイ。ちなみに目標はSDカードへのFATファイルシステムアクセスをモノにすること！！
とりあえず、interface誌にならってbintuils、GCC、GDBをインストールしてコンパイルするのは無問題。GDBのスタブもinterface誌にあるものを流用して、とりあえずはターゲットとconnectしてダウンロードとかCtrl+Cでブレークするところまでは直ぐに確認できた。しかし、ここからが長かった・・・

まず、's'でステップ実行ができない！'s'でも'c'でも同じようにLEDチカチカが走り続けてしまう。なんでだ？

'b'でbreakpointを張ってみる。とりあえず、止まるのだが訳の分からないところで止まっている。アドレスから見るとGDBスタブの中で止まっているように見えるな。なんでだ？

では、ソフトの方にBKPT命令を入れてGDBでキャッチできるかどうか見てみよう。とりあえず止まる。が、やはりbreakpointを張ったときと同じように、スタブの中で止まっているように見える。breakはできないのか？GDBの意味無いじゃん！なんでだろう？

まあよい、'c'でcontinueはできるはずだ。Ctrl+Cでブレークした時はstepはできなくてもcontinueはできていたんだ。breakpointの続きから実行再開してくれるはず・・・、あれっ？しないな～。同じアドレスで止まったままGDBに戻ってくるな。なんでだ？

ここから堂々巡り。
GCCは正式にはthumb2命令には対応していないらしく、ややこしいことにCortex-M3はthumb2命令しか対応していないため、ARMモードに戻るようなコードは御法度！。何か変なコードが紛れ込んでるのかと思って、GDBからdisassembleしてみるとどうもおかしい。thumb命令って基本16bit長じゃなかったっけ？逆アセの結果は全部32bit単位で出てる。メモリの内容がおかしいのか、それとも・・・「GDBがthumb2のデバッグに対応していない！」なんてオチなのか？そんなことはあるまい。
しかし確かにdisassembleの結果はおかしい。ダウンロード前のelfバイナリをobjdumpすればちゃんとthumb2で逆アセされてるから、おかしなコードがあるわけでもないようだ。困った困った・・・

それからも、いろいろ紆余曲折した挙げ句に分かった原因は・・・。

interface誌のGDBスタブが間違がっとるやないかいっ！

GDBスタブ側の割り込みハンドラから、ユーザープログラム側の割り込みハンドラへ飛んでくるときのユーザーベクタアドレスは、0x02000000じゃなくて、0x20000000ね。もう一度言う、にひゃくまんエイチじゃなくて、にせんまんエイチです！ったく、だからいつまで経ってもC級なんだよ！

もう面倒だから、スタブの方を改造してデバッグモニタ割り込みは全部スタブ側だけで処理するようにしてしまった。ユーザープログラム側に渡そうとして変な動きしてたからとりあえずはより安定して動くことを目標にした方がよさそう。

それから、GDBでシングルステップ実行ができない件。なんだよ、このスタブ、's'も'c'も同じ扱いじゃねーか！そりゃ's'したら走り続ける罠。ううぅぅ、オノレ、C級出版め。余計な面倒かけやがって。
途中で入手したCortex-M3のマニュアルを見て、サクッと's'コマンドに対応させてみる。う～ん、いい感じ、stepもできるようになったゾ。breakpointも張れるし、これで苦節半年、ようやく本来の目標に戻れる。と思いきや、正月休みも終わりタイムオーバー。
やっぱり今年も中途半端な一年に終わりそうな予感。。。

あっ、disassembleがうまく行かなかった件、これはもしかするとGDBがTバリアントを見てARMモードかthumbモードかを見て逆アセしてたからなのかなぁ。今はちゃんとdisassembleできてる。GDB6.8はthumb2で何とか使えそうではある。

それから疑問が１点残った。's'はソースレベルのstep実行、'si'がアセンブラレベルのstep実行だったような記憶があるのだが、なぜか's'でも'si'の動きをしている。GDBは's'でも'si'でも同じパケットをスタブに投げているようなので、どうもGDB自体がソースレベルでstep実行しようとはしていない模様。なんでだ？これも今後の課題だ。

とりあえず、breakpointを張って止める、変数のinspectionができる、これだけでも大進歩だ。あとは時間を確保すること・・・それが問題だな。

MP610故障？（エラー6A00）

ちょうど１年前に買ったCanon MP610にエラーが出るようになってしまった。
「ちょうど１年・・・」、ソニータイマーならぬキャノンタイマーなのか？なんちて。

エラーコードらしき6A00が見えているので調べてみようと、PCを立ち上げると・・・
こっちも立ち上がらない。どうなってるんだ！？

ま、会社から持ち帰っていたノートPCがあったのでそちらで検索してみると、エラー6A00というのは
よくあるエラーのようで、2chには「簡単に直るヤツ」と書いてあるにも関わらず、
直し方orチェックすべきポイントを教えてくれるサイトはどこにもない。ガセネタか？

とりあえず、kakaku.comの掲示板ではインクポンプのパージユニットの故障or不具合らしいとあるので、
インクカートリッジを外して見てみたり、ヘッドの定位置（？向かって右側）に何か異常が見えないか
注意深くみてみた。パッと見では何もないのだが、電源を入れてしばらくすると、そのプリンタ内部の
右下の方にある細長く黒い部品がピクッと動いた瞬間にエラーが出ていることが分かった。
「もしかして、この部品は動くべきなのか？」と思って、直接は見えない部品のウラ側に手を差し入れてみると、
何やら柔らかい布のような、インクリボン（ってかインクジェットにリボンはないんだけど、以前あった
リボン式プリンタのころに見たことがある）のような真っ黒い物体がベロンと出てきた。
よく見ると、紙ですかね～、これは。どうやらインクまみれで真っ黒＆くたくたになっているだけのようで、
どうやらこの見えないウラ側に紙切れが挟まっている模様。
この動くと思われる細長い部品は案外簡単に動いた（向かって奥の方に）ので、動かしてみるとまだまだ
紙片が出てくる出てくる。インクで手がギトギトになりながらも全部の紙片を取り除いてから電源を入れると・・・、
「ひぃやゃっほぅ～～！」、エラーが消えましたぜぃ！。
う～ん、年賀状印刷の時期に、大枚を叩いて修理しなくて済んだぜぃ！

しばらくはインクが滲んだり、位置がずれていたりしたので、ヘッドクリーニングと印刷位置調整を行うと、
元通りにもどったようだ。修理代約1万円って、もう１万円出すと新品が買えてしまうから、
ビミョーに悩むところだったんだよねー。助かった。

写真をUPできたら、同じエラーで悩んでいる人の助けになるんだろうけど、ちょっと用意できなかった。