AVR-JTAG(14) SPARTAN3EのIDCODE成功

.30 2011 AVR-JTAG comment(0) trackback(0)
今まで2.5VデバイスのID取得がこけていましたが、漸く安定して取得できるようになりました。
修正箇所は2箇所です。
まず、ベース接地にしてaいるトランジスタのベース電圧を分圧してターゲット電圧の1/2にした点。
それから制御側でTCKを上げてから入力値を読むまで3clk程待つようにした点です。
パラレルポート接続の旧ライタでも2.5Vデバイスの認識はしょっちゅうこけていたので、これが安定してできるようになったのはかなり嬉しいです。
# 認識できたところでまだ書き込みが出来ないので両手を挙げて喜ぶには時期尚早です…

3.3Vのときはこの辺の処理をしなくても動いていたので2.5Vではトランジスタのスイッチング速度が遅いとかFPGAの出力電圧が少し低めだとかそういうことが考えられます。
そろそろ大学が始まってしまうのでSPARTAN3への書き込みは来春の課題として、とりあえず今まで終わったところを整理してあとで見たときにすぐに始められるようにします。

それからいい加減部屋の掃除しないと。
歩いてたらプラスチックネジの破片とかピンヘッダのかけらとか錫めっき線とか部品の足とかチップ抵抗とかいろいろ足にくっついてきてあまり良くないです。
ただでさえ埃がだいぶ溜まっているのに…

AVR-JTAG(13) 新基板

.26 2011 AVR-JTAG comment(0) trackback(0)
昨日書いた新基板を配線しました。
new_writer_top
左がJTAG(CPLD, FPGA)で中央がSPI(AVR)、右がライタ自身のメンテナンス用のポート。メンテナンスポートはライタの完成後取り外す予定です。
new_writer_bottom
取り外す気満々のメンテナンスポート。

これでデバイス側の電圧が5V, 3.3V, 2.5Vでも大丈夫で、さらに書き込み用のポートが兼用ポートになっていていろいろ付いている場合でも問題なく書き込めるはずです。
今回はサイズを犠牲にしていろんな場合に対応できるように作ってみました。というわけで贅沢に小基板を丸々一枚使っています。

基板ですが、厚さ0.8mmの小基板を使っています。理由は昨日の記事に掲載したあの基板から取り出した水晶発振子の足が短くて普段使ってる基板だと裏まで届かないためです。
写真では74ABT125を使っていますが、2.5Vでは動かないので74AC125あたりに取り替える必要があります。
また、74AHC125のような5Vトレラント品を使う場合は写真上部のトランジスタが不要になります。
今回は入手性を考慮してトランジスタ付けました。

とりあえず旧基板で動作していたところまでは新基板でも正常に動くことを確認しました。
(XC9536, XC9536XLへの書き込みまで確認)
続いてAVR側も整備していきたいのですがコネクタが手元にないので水曜日に買出しに行きます。
FPGAへの書き込みは74ABT125では無理なので(FPGA側が2.5V)これも先送りです。

TODO:
  • USBエラーで復帰できなくなる可能性を排除する(WDT使うだけ)
  • ソースコードの整理
  • ドキュメント作成

  • なお、今回のライタは以前のAVRライタと互換性がありません(ツールも別のものを作る)。

AVR-JTAG(12) 現状まとめ、タイマIC備忘録など

.25 2011 AVR-JTAG comment(0) trackback(0)
少し間があいたので現状を整理します。

XC9536(5V)への書き込み:高速化して4秒切るくらいです。
XC9536XL(3.3V)への書き込み:低速化してしまいましたが9秒くらいです。
SPARTAN3E(2.5V)の認識:これだけ数ビット狂います。基板新調したらトランジスタのベース抵抗にスピードアップコンデンサを並列につないで実験してみます。よく考えたらベース接地なのでスピードアップコンデンサ入れようがないですね。

XC9536は文化際の日にaitendoで買ってきたものです。
買ってきたのはこれ(すでにCPLDだけ外したあとですが)。

xc9536_before

↑Before
↓After

xc9536_after_1
xc9536_after_2

普通にXC9536買うよりよっぽど安かったのでわざわざこんな変な物買ってきたのでした。
戦利品:XC9536VQ44, AVRの前身のデバイス(AT89S...)、12MHzの水晶発振子、かなり高輝度の7seg 4桁。
これで50円だったので超お買い得です。
とはいってもXC9536は呆れるくらい内蔵の素子が少ないので「CPLDをちょっと触ってみる」以上のことはできませんね。
以前はXC9572とXC95108をよく使っていましたがさすがに9536までは手を出していなかったので今更ながら驚いています。

ここで使っているタイマICの555ですが、ちょっとクセのある石で、データシートとかに載ってる発振回路はduty比がRb/(2Rb + Ra)となっています。
そうするとduty比50%にしたければRa = 0にすればいいのかと思ってしまうわけです。
配線後、あれ?発振してないじゃん・o・ってことで555の内部回路をチェックしたところRa = 0で発振しないことに気づいたのでした。
そんで申し訳程度にRaにRbの1/100くらいの抵抗突っ込んだのですが残念ながらそれでも発振は不安定で、最終的にRa = Rb / 10くらいまで引き上げて解決したのでした。
データシートにはduty比50%で使う場合の回路もちゃんと載っていますが、555の機種依存という噂もあるようなので(??)使う場合はきちんと自分の使う555のデータシートを見る必要がありそうです。

今後の課題
  1. JTAGが兼用ポートになっているデバイスを考慮して基板を作り直す
  2. SPARTAN3Eに書き込めないとどうしようもないのでまずはこれをなんとかする
  3. 暇だったら少し低速化した36XLへの書き込み速度を上げる
  4. ARMもJTAGで書き込めるとか?その辺の調査
  5. PIC24もJTAGで書き込めるらしいが純正品はJTAG以外のインターフェース使ってるらしいのでそっちも調べる

まず1に関してですが、以前示したベース接地+プルアップの回路ではJTAGが兼用ポートだったときに問題があります。
この回路ではLはちゃんと「強いL」として出力されるのですがHはあくまでプルアップなので「弱いH」になります。
兼用ポートとして使っていてそのポートが強くプルダウンされていたりするといくらHを出してもHとして認識されないということになります。
そこで以前5Vトレラントのトライステートバッファをトランジスタの代わりに入れるということを書きましたが、たまたま転がっていたのが74HCT245なのでできればわざわざ買いに行きたくないのです。
そこでベース接地+プルアップの先にさらにこのICをくっつけることにします。ただHCTの遅延は10nsくらいなので速度面でかなり不安が残ります。

とりあえず今日は机の上を整理して基板買って調理するところまでいきたいです。

AVR-JTAG(11) 高速化

.17 2011 AVR-JTAG comment(1) trackback(0)
昨日のログでタイムアウトしたときにいろいろバグると書きましたが、それはタイムアウトしないように設計すればいいだけの話。
タイムアウトするってことは何度も無駄なパケットが飛んでいるわけで、特に今回の場合はAVRのCPU時間をガリガリ消費していきます。
# 単純にさっさと高速化に取り掛かりたいだけです。こんな直しても誰も得しないバグは回避するに限る。

usb_control_msg関数はタイムアウト値を設定できるのでとりあえずこの値を大きめにすればいいわけです。
ただ、それでもRUNTESTのような時間のかかる処理をしている間に次のリクエストを投げるのは無駄なのでホスト側で処理の終わる時刻を予想してusleepをかけています。

とりあえずここまででタイムアウトしなくなり、安定して書き込めるようになりました。
しかし異様に遅い。XC9536XLPC44で30秒とかどういうことなの?

jedファイルからimpactのバッチモードでxsvfを作ってそれを実行しているのですが、その中身をじーっくり見るといろいろ高速化の案が浮かんできます。
とりあえず思いついた高速化を適当に施してやったら7.777秒まで縮まりました。

% sudo ./jtagc test.xsvf

real 0m7.777s
user 0m0.004s
sys 0m0.028s

xsvfを解析した感じ200msのRUNTESTが2回、20msのRUNTESTが220回あるので4.8sは切れないことが保証されています。
もうちょっと無駄な努力をすれば6sくらいまでいけるかもしれませんがそろそろ飽きてきたのでこの辺で終わりにします。

あとはFPGAへの対応(今回はXC9536のxsvfで使われているコマンドしか実装してない)とかAVRライタの組み込みとかすればこのプロジェクトも完了です。
今更気づいたのですが今使ってる回路(以前掲載)だとJTAGとかSPIが兼用ポートだったときにまずいです。
やっぱり5Vトレラントのバッファとか間に挟むのが手っ取り早いんでしょうか。VHCとかAHCとかLVXとかその辺のやつ。
トランジスタ引っ剥がしてチップICに取り替える面倒なお仕事。
どっかで安く売ってないかなー

--

昨日、一昨日と8kmのリハビリをやったのですが、特に痛みは悪化しなかったので今日は14kmのリハビリに行ってきました。
今回処方していただいた薬が優秀で、スティックのりみたいな形で手を汚さずに気が向いたときにサクッと塗れるので治りが速いのかもしれません。
この調子で治ってくれれば次の遠征は今月中に行けそうです。

AVR-JTAG(10) 書き込み安定まであと一歩

.15 2011 AVR-JTAG comment(0) trackback(0)
昨夜は1時に寝たのですが、2時半頃ツクツクボウシの馬鹿野郎が部屋の網戸に張り付いて全力で鳴いたせいで目が覚めてしまいました。そのせいで一日中クソ眠かったです。

眠い眠い言っていても始まらないので、書き込めない理由を特定するためにErase, Verifyを先に検証してみました。

Erase:
  1. 旧ライタで何か書きこむ
  2. 新ライタでErase
  3. 旧ライタでReadBack : erase1.jed
  4. 旧ライタでErase
  5. 旧ライタでReadBack : erase2.jed
  6. diff erase1.jed erase2.jed
結果:OK

Verify:
  1. 新ライタで書きこむ
  2. 旧ライタで書き込んだjedファイルを使ってverify
長さが8の倍数でないときに少しバグっていましたがすぐに修正。

というわけでErase, Verifyは問題なさそう。

書き込みで一番怪しいのはRUNTESTを実行するところ。
RUNTESTを実行している間にUSB経由で次のRUNTESTが送られてくると無限ループになるようです。
# デバイス側:延々とRUNTESTを実行しまくる、ホスト側:NAKが返ってくるので再送

USBを処理しているアセンブリ層に問題があるのは明らかなので該当箇所(recvLen != 0でパケットが来たときの処理)をじーーっと眺めていたらあきらかにおかしい箇所があり、そこを修正したら動作がかなり改善しました。
それでもまだバグっていたのですが、RUNTESTのように時間のかかる処理についてrecvLenを0にするタイミングやtxsizeをセットするタイミングを処理完了時に移動したらだいたいうまく行くようになりました。

今残っているバグはusb_control_msgがタイムアウトして戻ってきたときに起こるものなので、タイムアウトしたあとにもう一度同じパケットが送られてくると何かまずいことが起こるようです。
起きる現象は「デバイスが常にNAKを返す無限ループ」or「必ず照合に失敗する」の2種類で、どこをどう弄るとどっちになるのかなどまだ把握しきれていないので明日はこの辺りからになりそうです。
タイムアウト値を大きくすればとりあえず回避できますが原因を調査しています。

高速化に関しては、パケットをとにかく減らすしかないのでTDIコマンドを送ったらライタ側で勝手にRUNTESTまでやらせておき、RUNTESTの間に次のパケットを受信できるようにすればそこそこ高速化が見込めます。


右足首はまだ痛みますが、軽いリハビリに行ってきたところ変な駐車場見つけました。



 HOME