最近YouTubeでNゲージのスローアクションのポイントマシンを見ていると、ポイントを転換する部分の機構が極シンプルなものが見られるようになった。アタイのはシンプルからほど遠い。今なら引き返せるぞ・・・ウン!引き返えそう!
MPLAB X IDEで、はまる・・(2)
MPLAB 8からMPLAB X IDEに移行し、ついでに今後はC言語じゃ~ということで・・ドツボにはまっている状態。
ビルドして、PICKit3、ICPS書き込みアダプターキット経由でPICに書き込もうとしているのだが、
The following memory area(s) will be programmed: program memory: start address = 0x0, end address = 0x26 configuration memory Programming... program memory Address: 0 Expected Value: 280f Received Value: 2805 Failed to program device
という感じで、書き込みができない。
で、「MPLAB X IDEで、はまる・・(1)」のようにしてひとまず、PICKit3が正常に動作し、ターゲットとなるPICも正常に書き込めることは確認した。
できあがった.hexファイルを以前のようにPICKit3 Programmerで書き込もうとしてもエラーになる。
試しに、以前作った.hexファイルをMPLAX Xを使って書き込んでみるとちゃんと書き込める。
つまり、MPLAB XからはちゃんとPICKit3を制御できているようだ。
ならば、以前のアセンデラのソースをMPLAB Xでアセンブルから処理したらどうなるのか試してみた。
結果は、書き込めなかった。
コンペア
何が悪いのかと、MPLAB 8で作成した.hexとMPLAB Xで作成した.hexファイルをコンペアしてみた。
MPLAB 8でアセンブルした.hexファイルの先頭
:020000040000FA :020000000528D1 :0800080009008316FF2390009C
MPLAB Xでアセンブルした.hexファイルの先頭
:020000040000FA :020000000528D1 :040002000034003492 :0800080009008316FF2390009C
どうやら、:04というレコードが余分に出力されているようだ。
で、04てなんなんだ!?
調べたら、拡張リニアアドレスレコードらしい。
MPLAB 8での手順を思い出したら、プロジェクトをMakeするときに、「Absolute or Relocatable?」というダイアログがでていたような。
そこで、Absoluteを指定したような。
Absoluteモードの指定
じゃ、MPLAB Xはどこで指定するんじゃと探してみたら、プロジェクトのプロパティ設定画面にあった。
左上のペインからプロジェクト名を選択して右クリックするか、ダッシュボードの工具のアイコンをクリックするとプロパティ設定画面が表示される。
Build in absolute modeという項目があるので、この項目をチェック。
リビルドすると出力された.hexファイルには04というレコードはなくなっていた。
これを書き込むと、ちゃんと書き込めた。
64bit対応としてアナウンスされているMPLAB X IDEからPICKit3経由で書き込みに問題がないことは確認できたので、今後はPICKit3 Programmerは卒業かも。
・・余談ですが、
当たり前といえば、当たり前かもしれませんが、エクスプローラーで、プロジェクトのフォルダにアクセスしている状態だと、ビルドでクリーンするときに失敗します。
で話を戻して、C言語で作成した.hexファイルをみてみても04というレコードはなかった。
これじゃないみたい。
じゃ、コンパイラの問題か?
今回使ってみたのがXC8コンパイラv1.21のFree版。
これを使って、MPLAB 8でビルドして出来上がった.hexをMPLIB Xでビルドしたものとコンペアしたら同じだった。
ならば、コンパイラを変えてみようとHI-TECH PICC(v9.81)を使ってみたが、こちらでやっても書き込みはできなかった。
そもそも、PICに応じたconfigが設定できているのか?
物理的に書き込めない状況ではないなら、論理的。
PICに書き込めないコード等があるのか?
PICを使うときは、そのデータシートをみてconfigの定義をおこなっていた。
実際には、そのPICに対応したファイルをincludeして、__CONFIGを記述。
#include p16fxxx.inc __CONFIG _CP_OFF & _CPD_OFF & _BODEN_ON & _MCLRE_OFF &
等々
c言語でも同じようにp16fxxx.hというファイルが用意されているので、
このファイルをinclude・・・しなくても、xc.hをincludeしておけばいいらしい。
#include <xc.h> #pragma config CPD = OFF #pragma config CP = OFF
などと、定義していく。
#pragma configで値を定義するときにはヘッダファイルにどういう名前で定義されているかをp16fxxx.hから探す必要があるのか・・
Config Bitsについては旧バージョンではメニューの「Configure」のなかにあって、Output to fileという項目を選ぶとファイルに出力することができたが。
Config Bitsの設定
メニューから、「Window」「PIC Memory Views」「Configuration Bits」を選択
ここには、フィールド名と設定できるオプションの説明などが表示されている。
セレクトボックスがあって、設定する値を変更することができる。
画面下に表示された「Generate Source Code to Output」というボタンを押すと生成されたソースが表示される。
いちいちファイルに出力しなくても、そのままコピペできる。
と、いうことで特にヘッダファイルは探し出さなくてもいいみたい。
ちなみに、「PIC Memory Views」の機能にはほかにもいくつかある。
Program Memory
生成されたプラグラムのコードが先頭からディスアセンブルされたコードと一緒に表示されているようだ。
そこで、みっけ。
そもそも今回、コンパイルした.hexをPICに書き込もうとしたときに出たエラーメッセージは
program memory Address: 0 Expected Value: 280f Received Value: 2805 Failed to program device
アドレス0番地、280fかと思ってたら2805だもんなぁってことみたい。
program memoryを見ると、0番地はOpcodeが280fで、0xf番地へのGOTO命令。
で、要求されている2805は5番地へのGOTO命令。
0番地はPICが動作を開始するアドレスで、4番地には割り込み開始時のアドレス。
アセンブラでは割り込みの4番地の後の5番地にメインルーチンを置いて、0番地には動き始めたらGOTO 5番地のメインルーチン。(2805)
などとなっていることが多いと思うのだが・・
ここらで頭がこんがらがってくる。
IDE上で見る限り、Program Memoryの先頭の0番地は280fとなっている。
書き込み時には 280fを要求したが、Received Valueは2805だったということらしい。
じゃ、だれが2805を返してきたんだ!?
一旦、MPLAB X IDEから離れて、再びPICKit3 Programmerで試してみる。
- 現在のPICの中身をEraseで消す
- c言語で生成した.hexをインポートする
- 画面に表示されたProgmam Memoryの先頭(インポートしたファイの中身)は280Fになっている
- 書き込みを行う
- エラーになる
Progmamming failed at Program Memory address 0x000000 - Readで読み込んでみると先頭は2805になって、そのあとも中身が違っている
PICKit3で書き込みができていなかった
なにか別モノが書き込まれたみたい。
要は、ソースは280f・・だったのに、書かれたのは2805・・ということでベリファイでエラーになったようだ。
じゃぁ、PICがおかしいのかと思って、以前アセンブラで作ったのと、今回c言語で作ったのを何度か入れ替えながら書き込みを試したが、どうやらc言語で作ったものは書けないけど、アセンブラで作ったものは問題なく書けるようだ。
もしかしたら、PiCKit3のバグ!?
c言語で書き込めないから、申し訳ないので自分自身のモジュールでも書き込んでいるのか!?
ちなみに、今使っているPICKit3のバージョンは、
Application Version 3.10.00
Device File Version 1.62.15
OS Firmware Version 2.00.05
現時点の最新バージョン。
なんとなく、絞り込まれたきた感じはするが・・どうすりゃ、解決するんだ!?