Android携帯からJTAGバウンダリスキャンを行う

JTAGバウンダリスキャンの結果を、Android携帯に出すための方法を研究しています。

これができると、移動中でもどこでも、AndroidにUSB-JTAGアダプタを接続して、バウンダリスキャンがFPGAの書き込みができるようになります。

どうやっているかというと、
・RXマイコンをUSB(ホスト)にして、AndroidとADBプロトコルでつなぐ
・RXマイコンでJTAGバウンダリスキャンを行って、その結果をAndroidに送る
というわけです。

今回作ったRXマイコンのプログラムでは、I/O端子からJTAG信号がでてきます。

最初は、自分自身のJTAG端子に入れてセルフJTAGスキャンしてみます。
ちゃんとJTAGのIDCODEが認識されて、その結果がAndroid携帯の画面に表示されました。

拡大してみましょう。

なにやらエラーが出ていて、「R5F562N8BDBG.bsdというファイルがない」と言っています。今回実装したシステムは、SDカードの中のファイル名を8.3形式に限定しているのでロングファイル名が認識できないためです。本質的な問題ではありません。

次に、他のボードをつないでみます。とりあえず手元にあったSpartan-3のPCI Expressボードをつないでみました。

問題なく認識できました。IDCODE=21C2E093のデバイスがみつかったと言っています。

次はSpartan-6ボードをつないでみます。

ちゃんとIDCODEを認識して、デバイス名を言い当てています。

最後に、XCF02S→XC3S200という2つのデバイスがつながっているボードで試してみました。(古いですね・・)

自動認識はされたのですが、XCF02SのBSDLファイルをロードしにいったまま固まってしまいました。
ファイルシステムに何かバグがありそうです。

RXマイコンでJTAGコントローラを作ろう

RXマイコンは、USBを備えていて、内蔵メモリもたくさんあり、そのうえ高速です。
これはスタンドアローンで動くUSB-JTAGアダプタを作るのに最適なマイコンだと思います。

そこで、RXマイコンをインテリジェントなUSB-JTAGアダプタにするプログラムを作ろうと思います。
目標は、
①JTAGで接続されたデバイスを自動認識できること
②バウンダリスキャンで接続されたデバイスの端子状態を読めること
③SVFプレイヤーとして動作させることができること
④XILINXのFPGAやCPLDに書き込みができること
⑤BSDLファイルを読み込む機能を持たせて、未知のデバイスにも対応できること
⑥パソコンからでも、Android携帯からでも上記の操作ができること
です。

これができれば、電車の中でFPGAのコンフィギュレーションが出来ますゆえ。

そういうわけで、開発をスタートしました。

以前、MITOUJTAGのライブラリをSH4に移植したことがあった(スタンドアローンのJTAG検査装置として受託開発した時のもの)ので、それをさらにRXマイコンに移殖してみました。

JTAG信号はRX62Nボードの汎用I/Oポートから出てくるようにしたので、それを自分のJTAGポートに入れます。
まさにセルフJTAGスキャンって感じです。

TCKと、TDOをオシロで見てみると、ちゃんと出ています。
こんな感じでポートを操作したところ、
PORT0.DR.BIT.B0 = 1;
PORT0.DR.BIT.B0 = 0;
TCKの速度は約1MHzでした。

JTAGライブラリはRXでもちゃんと動いてくれて、TeraTermの画面には検出されたデバイスのIDCODEが表示されました。

BSDLファイルやSDカードの中に入れておいたものを読み込めるようにしました。
とりあえず、JTAGライブラリ、SDカード、USBのすべてが連携して動きました。
SDRAMを使わなくてもRAMが足りそうなので、RaXino♪でも動けばいいなと思います。

現時点でのプログラムのサイズは130kBくらい。内蔵RAMも70kB以上余っているので、まだまだ入ります。FPGAの書き込みアルゴリズムくらいは入るんじゃないかと思います。

連休中に少し進めたいと思います。

RXマイコンからAndroidを操作するプログラムを公開

お待たせしました！RXマイコンからAndroidを操作するプログラムを公開します。
ターゲットボードは究極のRX62Nボードです。

このプログラムを使うと、つぎのようなことができます。
・ Androidのデバッグシェルを、COMポート経由で操作する
・ RXマイコンのprintfの出力先をAndroid携帯の画面に出す
・ RXマイコンからAndroidへファイルを転送したり、アプリをインストールしたりする

※デバッグシェルをCOMポートにリダイレクトすることのメリットは、パソコンにADBをインストールするときと違って携帯の種類が変わってもドライバをインストールしなおす必要がないことです。
※printfの出力をAndroidにリダイレクトできるので、電車の中など、ノートPCがつかえない状態でもRXマイコンを動かせます。

使い方を簡単に説明します。

①RXマイコンにはあらかじめ、アーカイブの中にあるadbtest.motを書き込んでおきます。

②それから、究極のRX62NボードとAndroidをUSBケーブルで接続し、究極のRX62NボードとホストPCをUSBケーブルで接続します。

③ホストPCでTeraTermなどを立ち上げ、仮想COMポート経由でRXマイコンに接続します。

④ホストPCとRXマイコンがつながると、RXマイコンは自動的にAndroidに接続します。（Androidからピロリーンと音がします）
そして、ＴｅｒａＴｅｒｍの画面にベンダIDやプロダクトID、エンドポイントの構成が表示されます。

その後、COMポート経由でAndroidのデバッグシェルに接続されるので、lsやpsなどのコマンドを自由に実行することができます。

⑤このとき、TeraTermの画面でCTRL-X CTRL-Cを押すと、シェルをいちどクローズして再度接続します。Androidの反応がなくなったときにはこの操作を行うと復活できます。

⑥TeraTermの画面でCTRL-X CTRL-Xを押すと、メニューが表示されます。

⑦このメニューからは、ファイルの転送（Push）、アプリケーションのインストール、アンインストール、リブート（rootをとっていないので実際には機能しない）、特電のWebサイト表示、MemoSendアプリの起動、MemoSendアプリモードでの通信、シェルコマンドの実行ができます。

⑧次の画面は、Wキーを押して、Androidの画面に特電Webサイトを表示させたときのものです。

この操作を行うと、AndroidでWebブラウザが開き、特電サイトが開きます。
じつは、内部でシェルを起動して、am start -a android.intent.action.VIEW http://www.tokudenkairo.co.jp/ コマンドを実行させています。ADBなので自由自在にアプリやコマンドが実行できるのです。

⑨CTRL-X CTRL-X iコマンドを実行すると、Androidの中の/sdcard/フォルダにあるMemoSend.apkのインストールが始まります。

⑩CTRL-X CTRL-X mコマンドを実行すると、MemoSendアプリが起動します。

⑪MemoSendアプリというのは、特電が開発したAndroidアプリで、RXマイコンと通信するためのいわば端末です。
MemoSendが立ち上がった状態で、TeraTermでCTRL-X CTRL-X Aを押すと、MemoSendアプリとの通信モードに入ります。以後、TeraTermの画面に打ち込んだ文字は、Androidの携帯のアプリの画面に表示されます。

⑫逆に、Androidのほうで入力した文字列がTeraTermのコンソール上に表示されます。

さて、この秘蔵のプログラムを特電のRX62Nボードのお客様向けに公開することにしました。こちらから無償でダウンロードできます。

MOTファイルは究極のRX62Nボード用にビルドされていますが、ソースコードも含まれているのでいろいろいじってみてください。printfの出力先をAndroidにするには、グローバル変数のADBstdio = 1としてください。printfなど、標準出力がMemoSendにリダイレクトされます。

このプログラムは、4月27日までの間は、ソースも含めて公開します。

なお、上記のアーカイブの中にはMemoSend.apkも含まれているので、Androidに転送してインストールしてください。MemoSend.apkがMemoSendのインストールパッケージです。
これをMicroSDカードに入れて究極のRX62Nボードに挿しておけば、このアプリからpコマンドでファイル転送してAndroidにインストールすることもできるでしょう。

EZ-USB FX3のSlaveFIFOが遅い理由

EZ-USB FX3をSlaveFIFOで使うと、思ったほど速度が出ません。
ファームウェアかデバイスドライバのどちらかに原因があるのだと思っていましたが、おそらくファームウェアにありそうです。

次の図は、EZ-USB FX2をUSB2.0 HighSpeedモードで動かして、BulkOutしたときの動作をUSBアナライザで見たものです。

サンプルプログラムにデフォルトで付いているSlaveFIFOを使っているのですが、10 PING-NAKのような箇所が随所に見られます。
PNKGとは、送信先のターゲットデバイスのバッファに受け入れる余裕があるかどうかを尋ねるプロトコルで、NAKが10回も返ってきているということは、ターゲットデバイス(FX3)のバッファがなかなか空かないことを示しています。

つまり、FX3の反応がとても鈍くて、SOFの間隔(125μ秒)の間に2パケットしか送れていません。ダブルバッファが有効になっていないのかもしれません。

EZ-USB FX3とFPGAをつなげて動作テスト

ようやく重い腰を上げてEZ-USB FX3のSlaveFIFOとFPGAをつなぐ実験をしています。

FX3のSlaveFIFOは、GPIF IIを利用して作られています。FX2のGPIFはSlaveFIFOに内部でステートマシンを付け加えたものだったのですが、FX3では逆にGPIF IIのほうが先に存在していて、SlaveFIFOの各種信号をGPIF IIで作り出しているようです。

このデフォルトのSlaveFIFOの使い方がわかってきました。

・受信のやりかた
[A1:A0]="11"にして、SLCSを'0'にすると、数クロック後にFLAGAに読み出しFIFOの状態が出力される。FLAGAが'1'ならデータあり。その場合、SLCS=0、SLRD=0、PKTEND=1、SLOE=0にしてデータを読み出す。FLAGA='0'になったら終了。

・送信のやりかた
[A1:A0]="00"にして、SLCSを'0'にすると、数クロック後にFLAGAに書き込みFIFOの状態が出力される。FLAGAが'1'ならFIFOに余裕あり。その場合、SLCS=0、SLWR=0にしてデータを与えることができる。FLAGA='0'になったらFIFOがいっぱい。ただし、FLAGAの反応は鈍いので、最後の3個分くらいのデータはFIFOに入らずに破棄されるらしい。

どうしてもSlaveFIFO接続がうまく動かないな～、という時があるのですが、いろいろわかってきたことがあります。

① ファームウェアを更新すると、GPIF IIが動かなくなることがある。その場合、リセットではなく電源ON/OFFしたほうがよい。
② ファームウェアの転送前にFLAGA、FLGAGBにノイズが入ると、GPIF IIが動かなくなることがある。
③ そもそもFLAGAとFLAGBの区別がよくわからん。（GPIF IIの設定による）
④ インタフェースクロックを50MHzにするとデータが化ける？100MHzならOK。要検証。
⑤ Read時には、PKTENDを1にしておかないと全く動かない。
⑥ A0,A1を操作してからFLAGA、FLAGBが変化するまでに２～３クロックかかる。遅い！
⑦ そもそもPCLKを入れないと、FLAGA、FLAGBがハイインピーダンスのまま動かない。
⑧ SlaveFIFOとFPGAの間は100MHzの速度で、16あるいは32bitでインタフェースできるので、1つのパケットの読み出し速度は最大400MB/secになる。しかし、パケットとパケットの間隔が平均して90μ秒かかっているので、毎秒平均して11MB/secしかでない。IN方向もOUT方向も同じ。

とりあえずSlaveFIFOとFPGA間で接続はできるようになってきたのですが、どうしても速度が出ません。
これはFPGAの回路や、ファームウェアの問題ではなく、おそらくCyUSB.sysのデバイスドライバに問題があるか、EZ-USB FX3のライブラリの問題か、何かのディスクリプタの設定が忘れていてバースト転送できないようになっているとしか思えないような動作です。

※USB_SUPERSPEED_ENDPOINT_COMPANION_DESCRIPTOR をいじったり、USBEndPoint->ssmaxburstをいじっても変化なし。

下の写真は、SLRD（あるいはSLWR）とFLAGAの状態を表したものです。

FLAGAが'1'になると、FIFOにデータがある（あるいは書き込み可能）を示します。それを見てSLRD(あるいはSLWR)を与えているのですが、1024バイトを転送(5.12μ秒)した後、次のFLAGA（データあり）が送られてくるまでに数十μ秒かかってしまっています。

なお、CypressのControlCenterに代わるプログラムを自作しています。コマンドラインからRAMへのダウンロードと、I2C ROMへのダウンロード、BulkIn、BulkOutの操作ができようになりました。

実験に用いているSlaveFIFOのファームウェアと、FPGAのデザイン、コマンドラインアプリは、こちらからダウンロードできます。

ArduinoはどうしてPDEファイルをコンパイルできるのか

普通、C++のプログラムは#include文を頭にいっぱい書きます。
Arduinoのプログラム（スケッチ）の実体はC++ですが、#include文を書きません。
何もinlcudeしなくても各種関数が使えてしまいまうｓ。
では、どうやってPDEファイルをコンパイルしているのでしょう。
気になったので調べてみました。

適当なExampleをロードして、ビルドしてみました。
Arduinoの統合環境でShiftキーを押しながらビルドすると、コンパイル中のメッセージが見えます。

Arduino統合開発環境は、ソースコードの入っているフォルダには何も中間ファイルを残しません。

C:\Document and Settings・・・の中のTempにbuild数字.tmpというフォルダを作って、そこに中間ファイルを押し込めているようです。そして、その中に怪しげなCPPファイルが！

開いてみると、元のファイルに3行付け加わったファイルがCPPファイルという名前で出来ていました。

付け加わった3行は、

#include "WProgram.h"

void setup();

void loop();

です。
そして、avr-g++でこのCPPファイルをコンパイルしているようです。

※この3行はコメントが終わって最初の意味のある行が始まる直前に挿入されるようです。

つまり、PDEファイル結合→include文を含めた3行挿入→CPP作成→CPPをコンパイル、という手順のようです。

このあたりを行っているのがSketch.javaというプログラムです。
StringBuffer bigCode = new StringBuffer();
というのがあるので、おそらく関連するすべてのPDEファイルを1つにくっつけているのではないかと思われます。
3行挿入を行っているのがPdePreprocessor.javaというファイルのPdePreprocessorクラスです。

コンパイル時にエラーが生じたときに表示される行番号は、どうやら、この挿入した行を補正して表示するしくみがあるようです。

よくできていますね

空中配線ロボットを修理

遅ればせながら、エレキジャック・フォーラムに出展が決まったので、報告します。

展示内容は、「RXマイコンにAndroidをつないで楽しむ電子工作」 というテーマで行います。
RXマイコンにAndroidをつないで、printfの出力がリダイレクトできたら、とても面白いことができます。
そんなデモを行います。

また、明日のエレキジャック・フォーラムでは空中配線ロボットも展示します
初めての一般公開です。

もう、作ってからかれこれ１５年くらい経ちます。あちこち痛んでいましたので、修理をしていました
車輪が回って、その辺にあった半田線を巻き込んでから、動力系がショートしてしまいました。
うーん。直るんだろうか・・って感じですがイルミネーション系は問題なく動いています。

エレキジャックフォーラムは、明日14日に秋葉原UDXで開催されます。
趣味人のコーナーに私がいますので、見つけたらぜひお声をかけてください！

なお、基板チョコレートと、年賀状基板の即売も行います。

Androidの画面を組み込みマイコンのprintf出力先にする

組み込みマイコンのprintf出力先を、USBでつないだAndroidの画面にすることができるようになりました。

RXマイコン上で、printfとやると、Androidの画面に出てきます。

上の写真の画面表示の部分では、こんなプログラムを動かしています。

while(1){

・・・

  static int first = 1;

  if(first) {

    printf("=======================================\n");

    printf("RX-Android bridge Version 0.93\n");

    printf("(C)Copyright 2012 Tokushu Denshi Kairo Inc.\n");

    printf("=======================================\n");

    printf("Hello I'm RX62N. Redirect stdio to Android!\n");

    ShowDescriptors();

    first = 0;

  }

  if(timer_get_ms() - last_send_time > 500) {

    last_send_time = timer_get_ms();

    printf("Current time=%ldms\n",timer_get_ms());

  }

}

こういうことをするには意外と面倒です。
普通、ノートパソコンなどから組み込みマイコンボードをいじるときには、マイコン側に仮想COMポートを作っておいて、TeraTermなどから触ります。

しかし、Androidの場合は逆で、マイコン側がUSBホスト、Android側がUSBターゲットになります。仮想COMポートとかいった標準的なプロトコルはないので、表示したいテキストデータをADBパケットに包んで投げるようにします。受信側（Android）にも、それを解読できるプログラムを入れておきます。

マイコンのプログラムがprintfを呼び出すと、C言語のライブラリは低レベルI/Oのwriteという関数を呼び出します。そこで、独自のwrite関数を作っておき、ADBのTCP:4567番ポートに向かってデータを投げるようにします。Android側ではあらかじめTCPの4567番ポートを開いておき、何か受信したら画面上に表示するようにします。
さらっと説明しましたが、紆余曲折あって、とても面倒なことをしています。

逆にAndroidからデータを送ってRXマイコンでgetch()で受け取ることもできるようになりました。
これで、電車の中で立ったままマイコンのプログラムを開発するというということも夢ではなくなってきました。

# 日本語表示はまだです。文字化けしてしまいます。
## こんなネタでエレキジャック・フォーラムに申し込んだけど、審査の結果がまだ来ない。だめかな・・

MITOUJTAG RX特別版の更新

RX-MEGAや、究極のRX62Nボードに添付されていた「MITOUJTAG BASIC RX特別版」の更新パッチをリリースします。

お客様は、更新パッチを下記のリンクから無償でダウンロードできます。
●MITOUJTAG BASIC RX特別版2.40c更新パッチ

このパッチを適用すると、以下のような改善が行われます。
・「究極のRX62Nボード」のオンボードJTAGがMITOUJTAGで使えるようになって、(昨年の夏ごろと比べて)約3倍に高速化された。
・RX用JTAG ICEで、SDRAMにプログラムをロードできるようにした
・RX用JTAG ICEで、内蔵フラッシュROMにプログラムをロードできるようにした
最初のころ(2011/4/1ごろ)にお買い上げいただいた方でも、最新版のMITOUJTAGになります。

また、オンボードUSB-JTAGの64bit版デバイスドライバには署名を施し、Windows7 64bitでも使用できるようになりました。64bitドライバは下記のリンクからダウンロードできます。

●Windows7 64bit版オンボードUSB-JTAGドライバ

これらのパッチを適用すると、まず、Windows7 64bit版でもRX62Nの視覚的なバウンダリスキャンができるようになります。

そして、JTAG ICEの画面で「SD INIT」と表示されたボタンが追加されています。これを押すと、JTAG ICEからSDRAMコントローラを設定してリセット後でもSDRAMが見えるようになります。
（※本来、RX62Nはリセット直後はSDRAMが見えないのでコントローラを初期化しなければならない）

そのため、開始番地を0x08000000としたプログラムを、JTAG ICEからSDRAM上にダウンロードして実行させることができるようになります。

内蔵RAMに入りきらない大きなプログラムでも、JTAGを通じてSDRAMにダウンロードして実行できれば、内蔵フラッシュを書き換えずに動作させられます。

RXduinoライブラリを更新しました

おまたせしました。
RXduinoライブラリと、ソースコードを更新しました。
バージョンは0.66になりました。

主な更新点は、
　・USBホスト対応と割り込みのバグフィックス
　・hwsetup()を2回呼んでも大丈夫なようになった
　・nahimonがSDRMA上にMOTファイルをロードできるようになった
です。

ホストのバグフィックスを行ったので、RX-MEGAをUSBホストとして使用する際の動きが少しだけ良くなりました。

また、nahimonを使って、SDRAM上にプログラムをダウンロードできるようにしました。
0x08000000～0x08F00000番地に配置されたプログラムであっても、nahimonのloadコマンドで転送して、rebootと打てばロードできて起動できるようになりました。

ダウンロードはこちらからできます。
http://rx.tokudenkairo.co.jp/downloads

伝統的な基板屋さんとの決別

その基板メーカーから、ついに見積書が来ました。
そこには驚愕の内容が！！！

なんだか、本当にやばいんじゃないかと思えてきました。

①その基板屋さんができると言っていたから頼んだはずの特注仕様ができないことになっている。
②４月６日に納品して欲しいと最初から口をすっぱくして言っていて、それなら金曜日までにデータを送ってくれと言われたから金曜日までにデータを送ったのに、やっと届いた見積書には『基板は４月１２日御社着になります。納期調整をお願いします。』と書かれている。
③４層基板で仕様書やデータを送っているのに、「２層板」と書かれている。（電源プレーンを抜くつもりか）
④２種類の基板を
■■■◆
■■■◆
■■■◆
という面付けでデータを送って、全部で４０個ほしいから４×１２＝４８ということで４シートお願いします、といったのに、２シートで見積もりを送ってきた。
⑤金フラッシュ仕上げと書いて依頼したのに、記載がない。（たぶん半田めっきで作るつもりだったのでしょう）

つまり、要求仕様を完全に無視した見積書が送られてきたのです。

即効で電話して、「そちらが４月６日までに特注仕様で作れるっていうから頼んだのに、なんで今頃になってできないって言うんですか？」と聴いたら、「そうはいったけど、それはさ、あれでしょ。だーかーらー、」と返事にならない返事。

４層基板でデータを送っているのに２層基板との見積書が送られてきたことについては、「ただの書き間違いですよ」だってさ。そんな重要な部分を間違える基板屋さんがいるのだろうか。

「何で２シートの見積もりなの？４シートでしょ？」
というと、
「４０個欲しいんでしょ、だから２０個を２シートでしょ？」

なんと、その基板屋さんにとっては、
■■■◆
■■■◆
■■■◆
これが２０個に見えるらしい。

もう私ぶちきれて、「私が出したメール読んでますか？」「読んでますよ」「理解できてますか？こういう１２面付けで送ったのに、どうして２０面付けに見えるの？それに御社が『できる』といっていたから頼んだ特注仕様ができないことになっているし、納期もwｑせｄｒｆｔｇｙふじこｌｐ；」と言ったら、向こうも切れて

「じゃあ、いいですよ、よそに発注してください！」
「そうします。あんたとこみたいないい加減な業者には発注しません！」

最初からそうしとけばよかった。
まぁ、たぶん４回出したメールの２回目までしか読んでいないんでしょうね。

ネット検索で上位に入るからって、うかつに頼んだ私が悪かったのです。
でも、できないんだったら最初からできないって言って欲しかった。大変多くの時間を無駄にしました。

細かな仕様のやりとりや確認を人的営業や記憶やメールに頼るのではなく、Webで機械的に設定できて履歴も含めて『見える化』が行われている「ネット時代の基板屋さん」の偉大さが分かりました。人的営業は仲良くなれば融通が利くのでしょうが、今の時代にふさわしくありません。

幸いなことに、その後いろいろな基板業者さんに電話をかけまくって、その特注仕様ができるところを見つけました。納期も問題なさそうです。

いわゆる伝統的な基板屋さん

私はだいたいいつもはP社さんに基板の製造をお願いしているのですが、いま設計している基板は特別な事情があって、日本国内のある基板屋さんにお願いすることにしました。

いわゆる伝統的な基板屋さんです。

以前、「プリント基板」などのキーワードで検索してその会社を見つけました。前に見積もり依頼をしたら、わざわざ新幹線に乗って遠くから東京まで挨拶に来られたので、その件に感謝して、今回はそこにお願いしてみることにしました。

ホームページは結構立派でした。基板製造だけではなく実装もやっておられるようだし、○○見積フォームとかも複数あるので、納期や価格もすぐにわかりそうでした（後から気づいたが、自動の見積もりフォームはJavaScriptエラーで動かないし、もう一つの無料お見積もりフォームは中で人が動いて見積もり回答をよこすもだった）。

ホームページには、こんな多層基板を作ったとか、こんな細いのを作ったとか、内層Viaも作れるとか、いろいろな凄い写真が載っています。しかし、ホームページを見ても、どのくらいの細かい線幅まで作れるかとか、ドリルは何mmまでできるのかとか、内層クリアランスは何mmなのかといった、具体的な数値は一切わからない。また、どの程度の価格なのかわからない。納期もわからない。見積もりを依頼しても返事がない。電話で聞くと、ブツッ、ブツッと断片的にしか教えてくれない。

ホームページを見ると、従業員は10人ほどいて専属の営業の人もいるはずなのに、必ず社長さんが回答するのです。電話で、「○日までに欲しいなら、金曜日中にデータを送って」というので、それでもおっかなびっくり、ガーバデータを送ってみました。

すると、木曜の夜に電話がかかってきて「こんなんじゃ作れないよ！」と何か怒っています。
0.3mmのドリル径に対してViaの直径が0.5mmしかないから駄目だそうです。φ0.55mmなら良いというので0.55mmに修正しました。
金曜日の未明に「修正しました。これなら作れますか？チェックしてください」と２回目のガーバデータを送信。

すると、返事がない。

面付けするもう一種類の基板を徹夜で描いて、金曜日の朝に「デザインルールのチェックをお願いします」とメール送信。

またしても返事がない。

金曜の昼頃に電話してみるが、「社長は外出中で17時まで戻りません」とのこと。デザインルールチェックも、見積もりの回答もまだないので、戻ったら電話をくれるように頼んでおきました。

当初は面付けを向こうに任せるという話だったけど、不安なので、メイン基板9枚とサブ基板3枚を自分で面付けして、完全なガーバデータにして、4回目のメール送信。

つまり、
1回目のメール・・木曜朝 メイン基板チェックの依頼。Via直径の問題で駄目。
2回目のメール・・金曜未明 メイン基板のチェック依頼
3回目のメール･･金曜朝 サブ基板のチェック依頼
4回目のメール･･金曜昼 面付けした後の完全なガーバデータ
という感じで、4回メールを送りました。
返事が来たのは最初の1回だけで、4打数1安打。

夕方、社長さんが戻ってきたようで、電話が来ました。
「電話をいただいたようですが、何か？」

何かじゃねーよ

怒りを抑えつつも、「基板は問題なく作れそうですか？」
と聴いてみると、「ふーん、大丈夫じゃない？取数が良くなるようにこっちで20面で面付けしておいたから。もう製造に流した」
との回答。
「何ですと？その20面というやつは。私が送ったのは12面付けされたデータですよ？大9枚・小3枚。最終版のガーバデータを昼の2時ごろにメールで送ったはずですよ。」

「ああそうですか、昼から外出していたので、メール見てなかった。ちょっとまって・・」

なんと、古いデータで製造を開始しようとしていたようです。しかも、見積もりも出さずに。
「ちょっと確認しますので、あとで折り返し電話します」

とのことなので、待っていたら、電話が来ない。こちらから電話してみると、
「社長は外出しております」
とのこと。逃げられた～！

その後、社長のPHSに電話しても会社に電話しても、ぜんぜんつかまりません。
私の基板が本当に作られるのかどうか、非常に不安な気持ちのまま週末を過ごしました。

まぁ、こんな具合で非常に腹立たしかったのですが、これがいわゆる普通の伝統的な基板屋さんなのかなと思いました。それと比べると、ネット時代の基板屋さんはだいぶん違います。

●対応者
・伝統的基板屋さん・・・社長が一手に引き受けて回答。
・ネット時代の基板屋さん・・・社内データベースで情報を共有。担当者が変わっても即座に対応できる。

●製造可能な仕様（線幅、ドリル径、クリアランス等）
・伝統的基板屋さん・・・社長が口頭で回答。
・ネット時代の基板屋さん・・・製造仕様書として文書化し、ダウンロード可能。

●データ入稿方法
・伝統的基板屋さん・・・メールで送る。受け取った返事はない。
・ネット時代の基板屋さん・・・Webフォームで送る。届いたかどうかは確認できる。

●電話対応
・伝統的基板屋さん・・・ぶっきらぼうで、何かいつも怒っている。
・ネット時代の基板屋さん・・・トレーニングが行き届いていて、感じがよい。

●価格・納期
・伝統的基板屋さん・・・標準価格・標準納期はなく気分で決まる。要問合せ。
・ネット時代の基板屋さん・・・基準が明確に定められていて、Webフォームで計算できる。

●製造の工程
・伝統的基板屋さん・・・いつ製造を開始したのかもわからない。
・ネット時代の基板屋さん・・・受付完了、製造開始、製造完了のメールが届く。

というわけで、比べてみると伝統的基板屋さんの勝ち目はないわけです。
ネット時代の基板屋さんがどんどん伸びているのも至極当然な話です。

やはり次に頼むのであれば、ネット時代の基板屋さんに頼みたいと思うわけですし、つきつめて考えてみるとネット基板屋さんが伸びている本当の理由がわかってきました。

長くなってきたので、続きはJTAGひろばの日記に書きます

SST社のパラレルフラッシュROM

MITOUJTAGには、パラレル接続のフラッシュROMに書き込む機能があります。
JTAGバウンダリスキャンで操作できるデバイスを媒介して、任意のパラレル接続フラッシュROMを操作することができます。

この機能を使って、SST社のパラレルフラッシュROMに書き込みを行ってみました。

SST社はおそらく、最近出てきたフラッシュROMベンダーで、激安のSPIフラッシュROMで存在を知りました。最近はパラレルフラッシュでも見かけるようになってきました。

JTAGバウンダリスキャンを使うと、JTAGデバイス（例えばFPGAやCPU、CPLD）の端子をパソコンから自由に操作することができるので、それにつながったフラッシュROMに、アドレス信号やデータバス、書き込み制御信号（WR,OE,CE）を与えることができます。
いわば、ROMにつながったJTAGデバイスを汎用のパラレルポートのように動かして、ROMにアクセスする波形を与えてやることでフラッシュROMを読み書きしようというわけです。

そういうわけで、バイト君に作ってもらったのがこの下の写真の装置。Spartan-6ボードのFPGAのI/O端子からSST社のSST38VF6404の端子に１本１本配線をつないでいます。タタリガミのようでいい感じに仕上がっています。

そして、FPGAのどの端子に、フラッシュROMのどの端子をつないだかを、GUIの画面で設定していきます。

さて、最近のフラッシュROMにはCFI(Common Flash Interface)という領域に、セクタ構成や書き込み時間などのパラメータが書かれています。MITOUJTAGのフラッシュROMプログラマは、このCFIコードを解釈することで自動的にセクタ構成を調べます。

ID CFIと書かれたボタンを押すと・・・

よっしゃ、セクタ構成が読み出せた！・・と思いきや、アドレスが変です。
7E000000Hなんていう番地から始まっていますし、1152個ものセクタが見つかっています。

かれこれ１時間くらい調べていて、原因がわかりました。

なんと、このSST社のROMは、CFIコードが間違っていたのです！！

まず、このROMの構造はどうなっているかというと、64Mbit(4Mワード)の領域を128個のブロック、もしくは1024個のセクタに等分しています。128個のブロックはそれぞれ32kワードです。1024個のセクタに分割するときにはそれぞれ4kワードになります。

つまり、1ブロック=8セクタの構成で、同一のアドレスをセクタかブロックかどちらかの方法でアクセスできるようになっています。消去するときはブロック単位でざっくり消すか、またはセクタ単位で細かく消すことができます。

このような構成なのですが、CFIコードは次のようになっています。

なんと、「Number of Erase Sector/Block sizes supported by device」が2になっています。
おそらくSSTの設計者は、ブロックでもセクタでもアクセスできるよ、という意味で2にしたのだと思いますが、この数字はリージョンの数を示すものです。

上のCFIコードだと、ブロック（青）とセクタ（紫）が別々に存在してしまうことになり、総アドレスがデバイスサイズをオーバーしてしまいます。

しかも、「Sector Information」の項目のアドレス30Hが0001Hになっています。これだと1セクタが64kBytesという計算になってしまいます。(実際のデバイスは8kBytes)

要するにCFIコードが目茶目茶なのです。

そこで、MITOUJTAGではSST社のROM(マニュファクチャコードとデバイスコードで識別)を発見したら、128ブロックのみを見るよう、得られたCFIを修正するようにしました。

これによって、SST社のROMに対しても問題なく、読み書き消去ができるようになりました。

MITOUJTAGのこのSST社のパラレルROMへの対応は、次回のバージョンアップ時に行います。
JTAGって、ほんとにいろいろありますね・・。そこが面白いところです。