JTAG総合情報サイト>MITOUJTAG開発日記>2017年の開発日記

2017年の開発日記

 ST39VF801CというROMのCFIは間違っている

2017.10.06

あるお客様から、MITOUJTAGのフラッシュROMプログラマ機能でSST社のFlashROM、「ST39VF801C」への書き込みができないというご指摘がありました。

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

例えば、

 

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

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

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

Sst_top

Sst_bot

 

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

Sst1_2

sun

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

Sst2

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

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

Sst3

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

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

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

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

Sst4

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

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

Sst5

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

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

Sst6

sun

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

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

 

祝!MITOUJTAG BASIC出荷1000台

2017.08.29

MITOUJTAGは、2003年度の未踏ソフト創造事業で採択されて開発をスタートしたJTAGソフトウェアですが、期間後も開発を続けて14年。ついに、MITOUJTAG BASICの出荷が1000本に達しました。(MITOUJTAG ProとLightを入れれば1000数百台になります。)

Mjb1

Mjb2

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

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

Brd_sp3a_13

 

MITOUJTAGでDDR3メモリ基板の不具合を発見

2017.07.11

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

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

 

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

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

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

MITOUJTAGがあります。

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

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

Mjpro

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

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

sun

 

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

1478579840_cosmok

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

 

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

 

というものです。

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

 

Ddr3_ok

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

Dq_path

と表示されます。

sun

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

Dq7_err

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

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

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

Calib_done_2

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

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

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

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

 

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

2017.02.06

Kintex-7にDDR3 DIMMを接続している装置があるのですが、不具合が生じたとのことで、検査依頼が来ました。

この装置は特電製なので、USB3.0からDDR3メモリの読み書きができる例のコアが入っています。そこで、USB3.0を通じたDDR3の読み書きテストをしてみたところ、確かに16384バイト以上のバーストアクセスでエラーが出ています。

今回はDDR3 DIMMを使っているので、データバスは64bitです。8192バイトまではアクセスできるので、A10あたりが切れているのかな・・と思ったのですが、実際の基板でそれを確かめるのは結構大変です。 

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

sun

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

 

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

Ddr3buzz

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

Ddr3_buzz2

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

Ddr3_conn


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

Ddr3_ba0

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

Ddr_a10

 

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

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

 

GR-PEACHのJTAGを使ってみた

2017.01.21

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

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

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

Grp_1

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

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

Jtag_circuit_2

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

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

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

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

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

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

R108

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

Grpeach_jtag

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

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

Detect_arm

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

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

Detect_unknown

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

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

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

Dnd

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

Detected1

 

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

Detect_rz

 

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

Sample_2

Detected

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

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

Grpeach_logana_2

sun

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

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

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

 

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


Toggle

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

 

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

sun

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

Trst


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

R29

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