ＰＩＣＢＡＳＩＣコンパイラ
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
［第６９回］
●ＨＥＸファイル比較データの検証（２）
この４日ほどの間ＰＩＣ ＷＲＩＴＥＲの闇の中を迷走しておりました。
危うく底なし沼にはまってしまうところでした。
危ないところで正気にかえりました。
そのあたりのことも書いておかなければなりませんがまずは前回の続きです。
前回はもとになるＨＥＸファイルと書き込み後のＰＩＣから読み出して作成したＨＥＸファイルとでは同じＦＦでも扱いが異なってくると書きました。
そのように考えることで左右のＨＥＸファイルを比較して「なにもない」ところが「ＦＦ」になっていてもそれはそれでよいのだと納得することができました。
ところがそのＦＦデータの中にちょっとおかしなところがあることに気が付きました。
途中の１行です。
これは何でしょう？
ＦＦが連続している中に
０２０００００４００Ｆ００Ａ
という１行があります。
これはおかしなデータです。
先頭の０２はこのレコードに含まれるデータのバイト数です。
その次の００００はふつうのレコードではアドレスですがその次にあるレコードの属性によっては意味の無い数になります。
このレコードの属性は’０４’です。
属性が０４のときはその次の２バイトの値が最上位アドレスを示します。
ＰＩＣ１８Ｆ１３Ｋ５０の場合メモリアドレスは２２ビットです。
００００００～３ＦＦＦＦＦなので通常のレコードで表現できる００００～ＦＦＦＦを越えてしまいます。
そこで６４ＫＢごとに分けた各メモリブロックの先頭にこの’０４’レコードを置いて上位アドレスを示すルールになっているようです。
このレコードが示す上位アドレスは００Ｆ０なのでここからはメモリアドレスはＦ０ＸＸＸＸになるわけなのですが、そこがおかしいのです。
それではアドレスが２２ビットではなくて２４ビットになってしまいます。
そこからアドレスＦ０００００～Ｆ０００ＦＦのデータが続いていることになります。
下はＰＩＣ１３Ｋ５０のメモリマップ（ＲＯＭ）です。
［出典］Ｍｉｃｒｏｃｈｉｐ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｃ． ＰＩＣ１８Ｆ１３Ｋ５０／１４Ｋ５０Ｆｌａｓｈ Ｍｅｍｏｒｙ Ｐｒｏｇｒａｍｍｉｎｇ Ｓｐｅｃｉｆｉｃａｔｉｏｎ
このマッブからもわかる通りアドレスＦ０ＸＸＸＸは存在しません。
本当に何も無いはずのところからデータを読んでいることになります。
それ以外にもまだおかしいところはあります。
先ほどのＨＥＸデータではおかしなデータのあとに
０２０００００４００３０ＣＡ
というレコードがあってこれは次に続くデータのアドレス上位が００３０であることを示しています。
上のメモリマップではＣＯＮＦＩＧのエリアになります。
すると。
メモリマップの０２００００～１ＦＦＦＦＦ（’０’が読み出されるはず）が飛んでいます。
なんだかおかしいです。
そこで。
秋月のＰＩＣ ＷＲＩＴＥＲでＰＩＣ１３Ｋ５０に同じプログラムを書き込んだものから同じように読み出して作成したＨＥＸファイルとの比較をしてみました。
すると。
左右が完全に一致しました。
おかしなデータとして読み出されたところは秋月のＰＩＣ ＷＲＩＴＥＲのせい（おそらくはＭｉｃｒｏｃｈｉｐのＰＩＣＫｉｔⅡソフトウェアのバグ？か、あるいは何か意味があってのことか）だと思います。
ということで。
ここまで一件落着です。
このあとのところについても書くつもりだったのですが時間がなくなってしまいました。
それについては次回に書くことにいたします。
ＰＩＣＢＡＳＩＣコンパイラ［第６９回］
２０２３．８．２７ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る