２０２４．１１．３０
前へ
次へ
ホームページトップへ戻る


ＰＩＣＢＡＳＩＣコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第１６７回］



●／ＶＥＲＩＦＹの問題表示

前回はすでにプログラムを書き込み済みのＰＩＣ１８Ｆ２５５０に対して全消去をしないでテストプログラムを書き込んでしまったためにベリファイでエラーになってしまったことについて書きました。
エラーになるのは当たり前のことなのでそれ自体は問題はないのですが、その表示に問題がありました。
前回はちょっと時間がなくてどこがどのように問題なのかについて詳しく説明ができませんでした。
今回はそこのところをもう少し詳しく説明します。
下は前回もお見せしたログのうちのベリファイエラーになった部分のみを取り出したものです。
>/verify
startcode=01
i=6,b=2,[04]0000[01]*i=14,b=4,[00]0000[01]*i=22,b=4,[00]0008[0f]*verify error! 0,28-08
i=42,b=16,[00]0020[0f]*verify error! 8,a4-80
i=62,b=16,[00]0030[0f]*verify error!20,58-08
i=82,b=16,[00]0040[0f]*verify error!30,8e-82
i=102,b=16,[00]0050[0f]*verify error!41,ef-6e
i=122,b=16,[00]0060[0f]*verify error!50,7d-2c
i=142,b=16,[00]0070[0f]*verify error!61,f0-00
i=162,b=16,[00]0080[01]*i=182,b=16,[00]0090[01]*i=202,b=16,[00]00a0[01]*i=222,b=16,[00]00b0[01]*i=242,b=16,[00]00c0[01]*i=262,b=16,[00]

前回の繰り返しですが。
最初にエラーが発生したところの表示は
ｉ＝２２，ｂ＝４，［００］０００８［０ｆ］＊ｖｅｒｉｆｙ　ｅｒｒｏｒ！　０，２８−０８
です。
ここの表示がおかしいのです。
ｉ＝２２はもとのファイルの２２バイト目のデータでｂ＝４は書き込みをするデータが４バイトあって、［００］はそれがＨＥＸファイルの行コードで通常のデータであることを示していて、０００８は書き込みデータの先頭アドレスを示しています。
そこまでがＷｉｎｄｏｗｓ側からのＵＳＢ送信データです。
そのあとの［０Ｆ］はＰＩＣ側からの応答コードでエラーが発生したことを示します。
０，はそのアドレスの下位８ビットを示していて、２８−０８はもとのデータと書き込み後に読み出したデータです。
ここで問題なのは下位アドレスの０です。
ＨＥＸファイルの１行のデータは最大１６バイトなのでその行の開始アドレスが０００８の場合その行のアドレスは０００８〜００１７です。
ここで下位アドレス０はおかしいです。
もしもこの行のデータでベリファイエラーが起きたならばそのときの下位アドレスは０８〜１７のいずれかでなければなりません。
まずはここがおかしいのです。
エラーになった下位アドレスが００ということからすると、それよりも前の位置だと推測できます。
その１行前の表示は（改行はされていませんが）
ｉ＝１４，ｂ＝４，［００］００００［０１］＊
です。
この部分ではどういうデータを書き込んだのか、それを確認してみました。
下はＰＩＣ１８Ｆ２５５０に上書きしてしまったデータのＨＥＸファイルの先頭部分です。
:020000040000FA
:0400000028EF01F0F4
:04000800A4EF02F06F
:1000200058EF01F02EEF00F049EF00F07EEF00F006

上から２行目の
：０４００００００２８ＥＦ０１Ｆ０Ｆ４
が該当する部分です。
０４はデータバイト数（ｂ＝４）です。
その後ろの００００はデータの先頭アドレスでその後ろの００はこの行の型コードです。
／ＰＩＣＷＲ、／ＶＥＲＩＦＹでは表示順序は逆になっています。
その後ろの２８ＥＦ０１Ｆ０が書き込みを行なった４バイトのデータです。
最後のＦ４はチェックサムです。
ここにもとのデータの２８があります。
そのアドレスは００００です。
ベリファイエラーで表示された２８−０８はここに間違いありません。
なぜかそれがその次の行のところで表示されています。
そのこと自体はＷｉｎｄｏｗｓ側の送信データとＵＳＢ経由で送られてくるベリファイ情報とに時間差があるかもしれないということで納得できそうです。
しかし納得できないのは、このアドレス００００のところの表示が
ｉ＝１４，ｂ＝４，［００］００００［０１］＊
であることです。
ｉ＝１４，ｂ＝４，［００］００００
までがＷｉｎｄｏｗｓ側のデータ表示です。
それに対してＵＳＢ経由での返信が
［０１］
なのです！
ここで有り得ないことが起きています。
ここでベリファイエラーが起きていることはほぼ間違いありません。
その情報が遅延してその次のデータ（アドレス０００８のデータ）の送出後に届いたとしたら、この［０１］の返信は何なのかということです。
ＰＩＣからＵＳＢ経由で送られてくる［０１］は、「正常完了」を示すコードです。
もしもベリファイでエラーが発生したら［０１］の代わりに［０Ｆ］が送られてきます。
ＰＩＣのプログラムでは異常終了のときに［０１］を送信することはありません。
すると。
可能性としてはＷｉｎｄｏｗｓ側のプログラム（Ｃｐｐコンパイラプログラム）が誤ってすでに受信済みのそれ以前の着信データを二重に表示してしまったことぐらいしか考えられません。
そんなことがあるのでしょうか？
さらに追求して確かめてみようとしたのですが、このエラーのあとでよく考えもしないで／ＥＲＡＳＥを実行したあと／ＰＩＣＷＲを実行してしまったのでＰＩＣ１８Ｆ２５５０にもとからあったプログラムは消去されてしまい再現テストができなくなってしまいました。
ＰＩＣ１８Ｆ２５５０にもとは何が書かれていたのかは全く不明で今となっては再現テストをすることはほぼ不可能です。

次回に続きます。

ＰＩＣＢＡＳＩＣコンパイラ［第１６７回］
２０２４．１１．３０　ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る