TagLostExceptionをどうたどろうか考えていたら、先生が教えてくれた。
さすがだ。
そんなわけで、transceive()しているデータを見直すことにした。
先に書いておくと、「結果としてその通りだった」ということになる。
NFC-Fの場合、先頭に送信データサイズが1byteあり、それに続けてコマンドが続く。
つまり、送信データサイズは、コマンド長+1になる。
Read w/o Enc(NFC Forumでいうところの、CHECK)は、こんな構成。
説明を簡単にするために、2byteブロックリストで1ブロックだけ読み出すときの例とする。
([0] 送信データサイズ)
[1] コマンド:0x06
[2~9]IDm(NFCID2)
[10]サービス数:0x01
[11~12]サービスコード
[13]ブロック数:0x01
[14~15]ブロックリスト
FeliCaチップに送信するときはもう少しデータを追加するのだが、transceive()にはこれくらいあればいいようだ。
データを見直してみると、どうもサービス数を書き込む配列の添字が間違っていて、IDmと重なっていたようだ。
修正して送信すると、TagLostExceptionは発生しない。
うむ、よかろう。
ということは、TagLostExceptionが発生するのは、InCommunicateThruに相当する命令を実行して、コマンド自体は成功したけれども、相手から応答がなくてタイムアウトした場合にも発生すると考えていいのかな。
では、うまくいかなかったPUSH(三者間通信)の方もやってみよう。
これも似たような間違いをしていて、IDmとデータ部が重なっていたり、データ長が違ったりしていた。
なんでそういう間違いが多いかというと、AndroidからPaSoRiを操作するライブラリを作ったとき、先頭のデータ長はライブラリで自動的に突っ込むようにしていたためだ。
それを、データ長付きのパラメータに変更したとき、いろいろ間違ったというところだ。
やれやれ。
修正して送信すると、TagLostExceptionは発生しない。
うむ、よかろう。
では携帯電話の方は・・・。
出てない。
エラーにならないのに・・・。
transceive()の戻り値を見ると、コマンドは通っているがエラーが返ってきているっぽい。
つまり、個別部のフォーマットが間違っているとかなのか?
ああ、IDmと個別部数の間に、パラメータ長がいるんだ。
修正している間に、間違って消してしまったらしい。
パラメータ長を追加すると、うまくいきましたとさ。
めでたしめでたし。
https://github.com/hirokuma/NfcTest3
今日わかった、transceive()によるTagLostException
- Targetから応答がなかった場合に発生する
- Targetから応答があれば、データの中身がエラーであっても成功したことになる。
つまり「行って返るまで」の責任を負っている。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。