2017年の開発日記

SSTは以前から標準規格を無視した仕様のICを出していて、JTAG通じたフラッシュメモリの書き込みでは問題が発見されていました。

例えば、

• SST39VF3201（http://nahitafu.cocolog-nifty.com/nahitafu/2013/05/sstrom-5abf.html）
• SST38VF6404（http://nahitafu.cocolog-nifty.com/nahitafu/2012/04/01/index.html）

 

XILINXのアンサーによれば、「Flashwriter では、SST フラッシュ デバイスはサポートされていません 」と、あきらめられています。

そんな定評のあるSSTですが、ST39VF801Cも同様におかしなCFIをもっていました。

そこで、このROMを取り寄せ、変換基板と万能基板に乗せてSpartan-6ボードにつなぎ、バウンダリスキャンでフラッシュROMの端子を1つずつ操作をしてみました。

 

JTAGバウンダリスキャンでCFIを読みだしてみると、ブロックが65536個あると表示されてしまいます。

データシートによれば、SST39V801Cのセクタは19個、ブロックは4個であるはずです。

同じサイズのセクタの塊をブロックというのですが、内訳として、16Kセクタが1個、8Kセクタが2個、32Kセクタが1個、64Kセクタが15個の、4つのブロックでできています。

しかしながら、SST39V801CのCFIコードには、ブロックが5個あると記されています。

この先にはCFIコードがなく、FFFFFFFF・・・が読み出されるので、そのまま読むと、変なことになってしまうのです。

さて、SST39V801CのCFIの間違いはこれだけではありません。

CFIのブロックの情報の上位16bitはセクタサイズ(256バイト単位)が、下位16bitはセクタの数が書かれているのですが、ここには実際に存在するセクタの数は-1された値が書かれることになっています。

したがって、16Kセクタが1個、8Kセクタが2個、32Kセクタが1個、64Kセクタが15個という構成であれば、0、1、0、14となっていなければなりませんが、このROMのブロック情報では・・

となっていて、最後のブロックにセクタが16個あることになってしまいます。

このため、普通に解釈するとセクタ構成がおかしくなります。

なので、SST39VF601Cの場合は最後のセクタの数を-1するような修正を加えなければなりません。

これでようやくセクタ情報が正しく表示されるようになりました。

なお、このROMは1ワード書くたびにプロテクトを解除しなければなりません。FUJITSUやAMD、Spansionに比べると、書き込み手順が長くなり、非常に遅くなります。

SSTのエンジニアには、規格をちゃんと理解してからICを作ってほしいと切に願います。  

1000台に達するまでいろいろなことがありましたが、これもひとえに、購入してくれたお客様のおかげです。

これからもGUI版バウンダリスキャンの先駆けとして頑張りますので、今後ともよろしくお願いします。

あるお客様からの依頼で、DDR3を搭載した基板のデバッグをすることになりました。

いわゆるコンサルティングのご依頼です。

 

DDR3メモリを搭載した基板のキャリブレーションが終了しない(init_doneが立ち上がらない)とのことなのですが、確かに動きません。MIGの設定で数か所間違いはあったものの、直しても動きません。

クロック速度を下げても、データバス幅を狭くしても動かきません。オシロで見た感じでは波形の反射とかでもなさそうです。

普通ならここであきらめるしかないのですが、特電は違います。

MITOUJTAGがあります。

MITOUJTAGを使うと、FPGAの動作状態にかかわらず、JTAGを使って端子だけを操作するという強力なデバッグができるからです。

しかも、MITOUJTAG Proには、C言語のスクリプトを使って波形を作り出す機能があり、DDR3メモリの波形パターンを作るライブラリも用意されています。

FPGAを論理合成して動かす普通のやり方だと、規定された標準的な信号パターン以外は出せません。たとえば、DQSの配置が間違っていたり、配置できないピンにつないでいたりすると、どうしようもありません。

ところが、C言語でソフトウェア的にI/Oの端子を動かすのであれば、どのようなパターンでもFPGAから出力できます。

 

そこで、まずはツール自体の動作をテストするために、確実に動作する特電のKintex-7ボードを使ってMITOUJTAGのスクリプトを試してみました。

DDR3メモリのテストのやり方は、

 

1. データバスを1本1本Hにした書き込みを行ってデータバスのオープン/ショートを発見する
2. その後、アドレスバスを1本ずつHにした書き込みを行って、アドレスバスのオープンショートを発見する

 

というものです。

実際には下の図のようなパターンを作り出します。波形の赤いところは出力している信号、緑は入力している信号です。

 

このとき、コンソールには

と表示されます。

次に、お客様の基板でやってみると、データバスのうち何本かで読みだしたデータが常にLになっていて、断線してることがわかりました。

DQ7が切れていたので8bitに縮退させても動かなったのです。

そこで、中間のDQ[39:8]だけを使って32bitに縮退させたデザインをMIGで作って動かしてみると、問題なくDDR3 SDRAMが起動することが確かめられました。

FPGAを普通に動作させて、動作中の状態をバウンダリスキャンで見てみると、ちゃんとinit_doneの信号が上がるのがわかります。ちゃんと1600MT/sで動作しています。

どうやら基板のパターンの不具合のようでした。

エンドユーザさんに聞いたところによると、この問題でもう数か月止まってしまっているとのことでした。MITOUJTAG ProのJTAGスクリプト機能とDDR3ライブラリを使うことで、長い間かかっていた問題が、わずか1日で解決できました。

MITOUJTAGについて、詳しくはこちら↓をご覧ください。

http://www.tokudenkairo.co.jp/jtag/

 

DDR3 DIMMのアクセス不具合の原因を瞬時に発見

なぜならば、FPGAとDDR3 DIMMとの接続を調べるだけのために、わざわざFPGAにテスト用の回路をプログラミングするのはとても面倒だからです。

そんなとき、MITOUJTAGというソフトを使うと便利です。MITOUJTAG(みとうジェイタグ)はJTAGバウンダリスキャンを活用するソフトなので、FPGAを書き換えることなく、I/Oの端子だけを自由に操作できます。

 

画面に表示されたKintex-7の絵を見ながら、マウスクリックで操作したい端子をクリックします。

MITOUJTAGの2.9あたりからは、BUZZ機能といって、クリックした端子から100Hzくらいの矩形波を出す機能を付けました。

これを使うと端子の状態が自動的にHLHLHL・・・とチカチカするので、DDR3のソケットにオシロのプローブを当てておけば、問題のある個所が瞬時にわかります。

実際にやってみると、BA0やA15、RAS、CASなどの端子は1.8Vくらいの振幅でトグルするのですが、

A10の端子だけは、なぜか、振幅が異常に小さいという結果になりました。

 

MITOUJTAGを使ったら、あっという間にDDR3メモリの不具合の原因が発見できました。

もし、MITOUJTAGを使わなかったら、どれだけ面倒なことになっていたでしょう。

あるお客様からRZ/A1HのR7S721000VCBGというCPUでJTAGバウンダリスキャンができないか、というお問い合わせをいただいたので、試してみることにしました。

RZというのはARMのコアが乗ったルネサスのCPUで、R7S721000の評価ボードというと、GR-PEACHというのが出てきました。GR・・！？

秋月で売っているようなので、買ってみました。

そして、回路図を見ながらJTAGの配線を引き出します。

JTAGの信号は、下のようにCN2に出ているのですが、この回路図上のCN2のピン配置は基板を裏から見た順序になっているので注意が必要です。

基板の表面から見たピン配置は下の図のようになります。

TRST ●●　GND
TDI  ○●　GND
TDO  ●●　GND
TCK  ●●　GND
TMS  ●■　VCC(3.3V)

 

さて、ルネサスのR*系のCPUのJTAG機能はバウンダリスキャンとICE(エミュレータ)が共用されています。BSCANPという端子があって、BSCANPがLのときにはICEになって、BSCANPがHの場合にバウンダリスキャンになります。

GR-PEACHの回路図を見ると、BSCANPは22kΩの抵抗でGNDに接続されています。

プルダウン抵抗があってよかった。

このプルダウン抵抗がなくてBSCANPがGNDに直結されてしまっていたりすると、何もできないので、本当にこの抵抗があってよかったです。

ただ、R108がどこにあるかを探すのが大変です。この基板にはシルクがないだけでなく、仕様書に記載されている部品番号は文字が潰れて読めないからです。

R108とBSCANPの信号は、ここにありました。

このBSCANPも含めて配線を引き出しました。

そして、MITOUJTAG（今回はLight）を起動して、自動認識させます。

おおっ！ ARMのCortex-A9か何かが認識されました。このRZも例外ではなく、BSCANPがLの場合にはARMのCortex-A9として認識されてしまいます。

次に、BSCANPをHにして、リセットをかけてから再度認識させてみます。

すると、何か不明なデバイスが認識されました。IDCODEを見てみると、08178447となっています。

これがRZなのですが、MITOUJTAGのデフォルトのデータベースには登録されていないようです。

そこで、ルネサスのWebサイトからRZのBSDLファイルをダウンロードします。

ダウンロードしたBSDLファイルをドラッグアンドドロップでMITOUJTAGの画面に落とします。

すると、このBSDLファイルが登録されて、端子の形が表示されます。

 

BSDLファイルの登録は最初の1回だけ行えばよく、二回目からは自動認識できるようになります。

 

そうしたら、端子の可視化も自由自在です。

デフォルトで動いているLEDチカチカ（７色のグラデーション）をさせているときの、LEDの端子の様子を波形で見てみました。

途中、何度かリセットスイッチを押していますが、リセット中にはLEDの端子が入力状態に切り替わっているのも見えます。

端子を見るだけではつまらないので、EXTESTをしてみましょう。

メニューバーの「端子操作」ボタンを押します。

すると、CPUの動作が停止するので、

 

例えば、H2を押して、ポップアップが出たら「自動トグル出力」を選びます。

すると、H2端子から自動的にHLHLHL・・・のパルスが出るので、LEDがチカチカ光ります。

 

これはプログラムを書きこんで操作しているのではなく、端子の状態だけをJTAGバウンダリスキャンで操作しています。なので、JTAG-ICEとは根本的に動作原理が異なります。

GR-PEACHを使っていて気になったのは、JTAGのTRST信号がデフォルトではコネクタに出ていないことです。TRSTはR29の抵抗を介して端子に出ているのですが、回路図を見るとシステムのリセット(nRZRST)にもつながっています。TRSTはJTAGのリセットなので、本来ならばシステムのリセットと一緒にすべきではありません。TRSTとRESは分けるのが正解です。

このR29はどこにあるか探したら、はここにありました。

私はこれをジャンパしましたが、TRSTとシステムのリセットがつながってしまうので、つなぐべきかどうかは一概には言えません。これだとリセット時の動作の振る舞いのデバッグができなくなります。