18F4550とPICkit2の接続は一発でOKになり、簡単なスイッチ読取、LEDチカチカなどの動作も問題なく確認できました。
それではと、カウンタ・メモリなどを制御する本ちゃんのプログラムを書き、これもハードデバッグをする意味を含め少しづつダウンロード、実行を繰り返していると
ある時点からダウンロード時に急に以下のようなエラーが出るようになってしまいました
DLL時にベリファイ失敗 PK2Error0027、再度ベリファイを実行しても再びPK2Error0027 が発生してしまいます。
これは悩みました。
初めはPICが壊れた（たった数回のDLLで？）かと思い、といってもQFPだから簡単に交換するわけにもいかず。ネットで検索するとこの「Pk2Error0027」で嵌まってしまっている人は結構いて、それに対するアドバイスとしては
・PICの品種が違わないか？
・PICが逆向き挿入？
・PCKとPCDの配線合ってるか
・ターゲットへの電源供給はされてるか
・・・
などど云われてますが、真っ先にそれらは確認するし、そもそも最初の数回は正常にDLLできていたので
これには当たりません。
DLL時のベリファイ異常が0x30000C→コンフィグレーション領域で起きているので、
プログラムに埋め込んだコンフィグ設定を見直してみました。
デフォルトで設定されているところも含め、全てのビットを再設定するようにしています↓
ここで思い出したのが、液晶表示パネルの制御のとき、ON/OFFのマクロ定義がコンフィグ設定に影響を与えてしまったことです。
で、確認してみるとやはり、今回もコンフィグ設定より前に読み込んでいる自作ヘッダファイルの中でこれをやらかしてました ↓
プログラムが少しづつ大きくなって、#define等で整理始めたところで入れ込んだようで
またまた同じミスです。全然学習できてないし・・
ともかくこのマクロ定義をコンフィグ設定をするプラグマの前でやってしまうと、
コンフィグ設定の、特に負論理で意味を持つビットが逆の意味合いに設定されてしまいます。
以下は上の同一のプラグマの前にマクロ定義がないときとあった場合、
生成されたコードに埋め込まれたコンフィグビットのダンプリストを合成したものです
正常 異常
↓ ↓
（マクロなし） （マクロあり）
まあPOR、BORの違いだけなら大勢には影響ありませんが、
コードプロテクション、読出しプロテクションあたりはことごとく逆設定→プロテクトされてしまい、これではベリファイリードのときにエラーになるのは当然でした。
防止策としてはON,OFFなどというどこかに使っていそうな語をマクロ定義したり
デフォルトのままで使用できるコンフィグ設定はわざわざ再設定するな・・ってことでしょうか。
