[felica]FeliCa Linkの続き

とある筋より情報をいただき(ありがとうございます)、FeliCa Linkの電源状態が稼働状態にまだなっていないのではないか、という感じになってきた。

でも、SDA=Lにしてから10msecも待ったのに・・・。
んじゃあ、20msecにしてやってみるか。リトライもしてみよう。

んあ？？

ACKが返ってきた？？
その後の書込みがおかしいのは、まあソフト要因だからよいとして、ACKが返ってきたのだ！

でも、20msecで一度スレーブアドレスを書き込み、そこで失敗して815usecくらい待ってからリトライして成功したのか。
初期化状態から稼働状態までの待ち時間が20msecでも足りないってこと？？？

 

気になったので、時間を10msecにだけしたアプリにしてみた。
つまり、前回失敗したときとの違いはリトライをするかどうかだけだ。

あれ・・・。

1回目に失敗して、やっぱり815usecくらい後で成功している。
このロジアナ波形は、A2がSDAで、開始トリガはA2の立ち下がりエッジだ。

スタンバイから初期化になるトリガは、本当にSDA="L"だけなのだろうか？
いや、もちろんVDDが供給されるとかあるんだろうけど、SDA="L"だけだったら待ち時間を10msecにした場合には815usecがもっと長くなってから成功しないとつじつまが合わないように思う。
あるいは、私のハードウェア構成がよろしくないか。。。

 

とりあえず、SDA="L"になっている時間を延ばす作戦はやめて、リトライ回数を増やすことにした。
増やす、といってもどのくらいの時間が妥当かわからないので、無限繰り返しにした。

・・・これだと、2msec以内にはうまくいったことになる。

こうやって見ると、SDA="L"だけじゃなくて、SDAとかSCLがある程度ぱたぱた動くというところにも条件がありそうに見えた。

なんか、私が知っているI2Cデバイスとは異なる動きをするので、正直なところどうしてよいかわからない。
時間について記載が無いチップというのは、ちょっと使うのには厳しいなあ。

[nrf51]SoftDeviceがKeilやMakefileから焼けるようになったらしい

Flashing SoftDevice directly from ARM Keil uVision and Makefile (nRF51 SDK 8.0.0)

いつもSoftDeviceはnRFgo Studioから焼いていたのだが、どうやらKeil(4 or 5)やWindows環境のMakefileから焼けるようになったそうだ。
Windows環境なのは、nrfjprog.exeというツールを使っているかららしい。

 

試していないのだけど、nRFgo Studioを今後はメンテしなくなる方針ということだろうか？
まあ、今のところSoftDeviceを焼くか、UUIDを生成してもらうのにしか使ってないのだけど。

[felica]なぜにFeliCa Linkのドキュメントには時間のことが書かれていないのだろう？

まだ、FeliCa LinkのNACKから抜け出せない。
たった1bitが立ち下がらないだけなのに、うぅ・・・。

---

あてずっぽうにやるのも疲れてきたので、いくつか仮説を立てることにした。

1. ハンダ付けがうまくいってなくて、チップまで届いていない
2. ピンが実は逆順になっていた
3. ロジアナに吸い取られている
4. 時間が足りてない
5. チップが壊れている

 

仮説1

テスターでチェックしたが、大丈夫そうだ。

 

仮説2

RFDETは思っていたピンで応答していたので、大丈夫そうだ。

 

仮説3

ロジアナを外してやってみたが、変わらず。
APIからエラーが返ってきたらLEDでわかるようにしたし、NFC R/Wで読み取れば動いたかどうかわかるのだ。

 

仮説4

VDDが供給されてからチップが動くまでに時間がかかるのでは？と5秒くらい待たせてみたが、変わらず。

SDA=Lになってから初期化が始まり、初期化が完了して稼働状態にならないと有線インターフェースからのコマンドは受信できないそうだ。
メモリアクセスをコマンドと解釈するのかどうかわからんが、ストップスタートコンディション(3/17 誤記修正)の状態を10msecほど作り出すようにしたけど、変わらない。

そもそも、どこにどのくらいの時間がかかるかって記載がPDFにないのだけど、なんでだろう？

 

仮説5

はい、うちにはFeliCa Linkが1枚しかないので、先ほどスイッチサイエンスさんに注文しました・・・。
無駄になりませぬよう。

---

ユーザーズマニュアルにもスターターマニュアルにも時間の情報が見つけられない。
これ以外で関係しそうなのは「RC-S967/1Vデータシート」というドキュメントなのだが、これは特約店から提供されるタイプらしい。
スイッチサイエンスさんに、ご提供いただけるかどうか確認してみよう。

[felica][mbed]FeliCa LinkからACKが来ない

mbedが来て、早2週間。
うちに新しいマイコンが来たら、何かFeliCa関係のデバイスを動かすのがルールになっている。
・・・というわけではないのだが、それなりに通信させる確認ができるので、RC-S620/SとかRC-S802とかを動かしていた。

今回は、FeliCa LinkであるRC-S730を動かすことに決めた。

---

FeliCa Plugが変形SPIでの接続だったのに対して、FeliCa LinkはI2Cでの接続になっている。
変形じゃないので、mbedのI2Cをそのまま使えばよいだろう。
LCDのST7032iが動いたから、そんなに難しくないはず。

はずだったのだが、スレーブアドレス書込み後のACKが返ってこない。
うーむ。

以前の反省を元に、プルアップ抵抗の値をいくつか変えてみたのだが、変わらず。

ちょっと心配なのが、しばらくプルアップするピンを間違えてて、GNDに接続していたこと。
RFDETは反応するんだけど、これは搬送波に合わせて脊髄反射的に動いているだけのような気がする。
IRQはデフォルトでは全部無効みたいなので、RC-S967/1V(FeliCa Linkに載っているチップ)が生きているかの判断ができそうにない。
なんとなく大丈夫な気はするんだけど、私のハードウェアに関する判断は当てにならないしなぁ。

とりあえず、もう1枚FeliCa Linkを買うことにした。
この前は、どうにもわからずにロジアナを注文したら来る前に解決したのだが、今回はどうなることやら。
まあ、FeliCa Linkはもう1枚あってもよいかと思っていたので、割り切ろう。

[win8]ロジアナZeroplusのドライバインストール

うちには、ロジアナとしてZeroplusのLAP-C(16064)がある。
Windows7で使っていて問題ないのだが、Windows8だとインストール時にドライバが入らないという問題がある。
Windows8ではあまり使っていないとはいえ、使えるに越したことはないのでバージョンアップで対応されないかな－、と思っていたのだが、最近FAQを見ると「こうやってね」と書いてあることに気付いた。

Logic Analyzers-Zeroplus

手動でやってくれ、ということらしい。
「Win8(or above)」とあるから、今後も対応する気はなさそうだ。

[mbed]ST7032iを動かす

せっかくNUCLEO-F411REを買ったので、mbedっぽく使ってみたい。
まずはI2Cデバイスを動かそう、ということで、以前買っていたST7032iをつなぐことにした。

I2CのドライバはAPIがあるのはわかっていたので、uITRONで作っていた初期化とかを移植するか。
と思っていたら、mbed用のライブラリが既に作られていた。
SB1602E (ST7032) | mbed
これが・・・mbedの威力か。

結果的に、1時間程度で動かすことができた。
その1時間も、程よい抵抗器を探したり、ブレッドボードにどうやって配置しようか悩んだり、SDAとSCLを逆にしててロジアナで波形取ったりとかいう時間がほとんどだ。

記念なので、接続したときの写真を載せておこう(動かしたときの写真じゃない)。
今回のプルアップ抵抗は、4.7kΩにした。

I2Cの最初のアクセスも載せておこう。

 

I2Cの仕様としては、アドレスは7bitだ。
I2Cマスターが送信するときは、アドレス7bitに続けて、1bitのRead(1)/Write(0)情報を載せる。
ライブラリで提供されているとき、指定するアドレスが7bitのものにするのか、Read/Write情報まで含めた8bitのものにするのか、あるいはRead/Write情報をライブラリ側でORすればいいように8bitのものにするのかは、調べた方がよいだろう。
mbedの場合は2番目のパターンになるようだ。

---

確か、私はストロベリーリナックスさんから購入したのだが、今はスイッチサイエンスさんからも出てるみたいだ。
I2C接続の小型LCD搭載ボード(3.3V版) - スイッチサイエンス
Arduinoは直接挿せるようだけど、ピンとしてはアナログのA1～A5に挿す想定のようだ。
NUCLEOで同じことができるかわからない。
ストロベリーリナックスさんのHW構成(コンデンサ内蔵)に加えて、スイッチサイエンスさんのはI2Cのプルアップ抵抗も取り付けてあるので、そのまま接続するだけで使えそうなのが良いですな。

[mbed]export toolchain

mbedのプロジェクトはオンラインでやれるようなのだが、オフラインでもビルドできる、というのを読んだことがあった。
これはオフライン版SDKをインストールして、使われているコンパイラを引っこ抜くとARM純正の環境が作れるのでは、ふふふふ、と思っていた。

が、そんなことはなく、オンラインで作ったプロジェクトをエクスポートできるということだった。
残念だが、まあそうだろう。

---

どういうエクスポートができるのか見てみたら、こんな感じだった。

はて、グレーアウトされているのは何だろう？
私のPC環境を読み取って、インストールされているものだけを選んでいる、というわけでもないし。
GCCも、ARM EmbeddedができてCode Sourceryができないってこともなさそうなんだけどなぁ。

Exporting to offline toolchains - Handbook | mbed

こちらを見ると、大きく4タイプのエクスポートができるとみなしているようだ。
Code SourceryもMakefileタイプだろうから、できないわけではないんだろうけど。
有償な環境は除外しているのかと思ったけど、それならIARが残っている理由にならない。
もしかすると、Nucleoだから、という制約があったりするのかもしれん。

が、今のところMakefileでやるつもりだし、なるべくオンラインでやった方がよさそうなことが書いてあったから、こだわるのはやめておこう。

[usb]USBPcapはコマンドプロンプト自体を管理者権限で立ち上げよ

追記：2015/12/15
WireShark v2からUSBPcapが取り込まれたので、もうちょっと使いやすいです。
http://hiro99ma.blogspot.com/2015/11/wireshark20usbpcapti.html

PaSoRiを自分で制御したい、ということから使い始めたlibusbだが、世の中にはUSB機器が多いのであれこれ応用が効く。
しかし、デバッグがしたいとなるとUSBパケットそのものを見たくなる。
お遊びでやっているのでお金をかけたくはないのだが、はてどうしたものか・・・ということでUSBPcapを使うことにした。
USBPcapのよいところは、pcap形式になっているのでWireSharkが使えるところだ。
しかも、WireSharkではUSBのパケットキャプチャとしてUSBPcapの説明を書いているくらいなのだ。
標準でUSBのパケットをある程度解析してくれるようになっている。
ただ、初めて使ったときはライブキャプチャ、すなわちUSBのパケットをリアルタイムでWireSharkに表示する機能が使えていたのだが、最近はうまくいってなかった。
Linuxとかのパイプでつなぐようなバッチファイルを作っていたのだけど、USBPcapが標準出力に吐き出すところと、標準出力からWireSharkで吸い取るところが別々に動いてしまってダメだったのだ。
動いていたときからWireSharkのバージョンが上がったからかな？とか思っていたのだが、検索すると以下のサイトで解決されていた。
USBの解析ソフト - きょうはなに色？
コマンドプロンプト自体を管理者権限で起動する、だ。
バッチファイルを管理者権限で起動すれば済むんだろうと思っていたのだが、まさにこの方が書かれていた内容が私にもあてはまったのだ。
助かりました。

---

おかげで、作ろうとしていたものが何とかできた。
普段だったら、それまでの過程とか調べたことをここに書くのだけど、今回はちょっと毛色が違うので書けないのだ。
うーん、残念。
まあ、これでまたBLEの調査に戻れるので、よしとしましょう。

Free Device Monitoring Studioは1日5セッションまでだった

USBスニファとして使い始めたFree Device Monitoring Studioだが、前回は「12分まで」と書いたが、もう1つ制約があった。
1日5セッションまで、という制限だ。

うーん・・・、この制限はちときつい。
いまはデバイスのつなぎ初めとかを見たいので、しょっちゅう入り切りしていたのだ。
かつ、タイミング悪いとPCがブルースクリーンになってしまい、再起動という・・・。

 

そんなわけで、USBPcapとWireSharkで進めることにした。
お仕事だったらツールを購入するところなのだけど、お遊びでやってることだし。
それに、キーボードのカスタマイズをするのと同じようなもので、どこでも同じ環境を作りやすい方が優先されてしまう。
まあ、場合によりけりってとこですかね。

[win]休止状態にならないのはアクティブパーティションがないためだった

私はWindows7を主に使っている。
週に一回くらいはシャットダウンするが、通常は休止状態で電源を切っている。
SSDだと負担がかかってよろしくないような記事を見たことがあるが、うちは普通のHDDだし、まあそこまで目くじらを立てることはなかろう。

が、その休止状態が急に動作しなくなった。
いつも寝る前に休止状態にしているのだが、朝起きてもまだ電源が入っていたままだったのだ。
なんというか、スリープっぽい状態になっていただけというか。
休止状態に入ると復帰するには電源ボタンを押すしかないのだが、今回の状態だとマウスとかキーボードを触ると復帰してしまうのだ。

私のイメージでは、休止状態というのは現在動作しているアプリなどのプロセスが使っているRAMをディスクに退避させる技術だ。
ほら、RAMが少なかったらディスクにスワップさせるではないか。あれのRAMが0バイトになってしまった版。
プラス、プロセスの管理情報とかも一緒に保存して、とにかくRAMのものを全部消してしまっても復元できるようにしてしまう技なんだろうと思っている。

まあ、私のイメージがどうだろうと、休止状態にならないことには変わりがないが・・・。

---

急にならなくなったのだが、なんとなく思い当たりがあった。
週末からUSBのスニファをあれこれ試したりしていたので、そこら辺じゃないか、というものだ。
検索すると、USBキーボードが・・・とかでよく出てくるし。
しかし、今回はそれではなかった。
インストールしたスニファもアンインストールし、USBデバイスも外し、スリープから復帰させることができるようにする設定も外したが、現象変わらず。

次にそれっぽい情報として、パーティションがアクティブになっていないのがダメだった、というのがあった。
そういえば、「システム」の「既定のオペレーティングシステム」が何も表示されなくなっているな・・・。
ということで、ディスクの管理からCドライブの先頭パーティションをアクティブ設定にした。
そしたら、休止できるようになった！

 

アクティブなパーティションがなくなったから休止状態になれなくなったのか、というのはわからない。
次回、似たようなことが発生した場合の対処として残しておこう。