ちょっとズルをした

ようやくPIC_coloの自動起動を実現することが出来ました。

PIC_colo_Update2を使って自動起動する機能を組み込む所までは、すんなり進みました。PIC_colo_Update2が再起動する度にSTKPTRがインクリメントして行きます。

このコードをPIC_coloデバッガに移してPIC_colo_Blinkが再起動すれば完成・・・と思ったのですが、起動してくれません。PIC_coloコンソールとPIC_coloデバッガ間の通信に異常が起きています。orz

何故、PIC_colo_Update2の再起動は上手く行くのに、PIC_colo_Blinkの再起動は駄目なのでしょうか？

PIC_coloデバッガのコードにBREAK_POINTを仕込むという技を使って、再起動の処理が正しく進んでいるかどうか調べることにしました。何度もPIC_coloデバッガのコードを書き換えたので、PICkitで書き換えることにしました。

（PIC_colo_Update2を使うべきなのですが、ちょっとだけズルしました。）

どうやら、PIC_colo_Blinkのmain関数は呼び出されているようです。今度はPIC_colo_BlinkのコードにBREAK_POINTを仕込んで動作を調べて行くと・・・TIMER1を初期化した後にPIC_coloコンソールとPIC_coloデバッガ間の通信異常が起きることが判りました。

それにしても、一体何が起きているのでしょうか？

（原因が判ってしまった今は、この時点で不具合原因を推定出来なかったことを不甲斐なく思います。）

やむなく（<==PIC_colo単独のデバッグを諦めた）PICkitのデバッガを使って動作を追いかけることにしました。

PIC_coloコンソールとPIC_coloデバッガ間の通信異常を確認して、PICkitでブレークを掛けてみると割り込みハンドラの中でした。そこからステップ実行で処理を調べて行くと、PIC_colo_BlinkのCustom_ISR関数が呼び出されていないことが判りました。

あ～っ！

プログラムをロードするときに行っていたCustom_ISR関数の登録手続きのことを忘れていました。プログラムをロードせずにFlashメモリに書き込まれているプログラムを起動する場合、cinitのアドレスから実行を開始する前にCustom_ISR関数を登録する必要があったのです。

Custom_ISR関数の登録は、PIC_coloコンソール（JAVAプログラム）側の処理だったので見落としていました。

Flashメモリにauto_startフラグ、cinitアドレス、Custom_ISR関数アドレスを登録して、再起動時にそれを読み取ることにしてようやく、リセットでPIC_colo_Blinkが再起動するようになりました。

これは、PIC_coloコンソールの無い環境でPIC_coloアプリケーションを動かすための重要な一歩になります。

 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

それにしても、今回の不具合調査にPICkitデバッガを利用したのは、大変残念です。PIC_colo単体でもう少し不具合調査を進めることも出来たように思います。成果を急ぎすぎたのかもしれません。

私自身、PIC_coloのデバッグ・スキルをもっと高める必要がありそうです。