2019.04.11

LAN9514のEEPROMをLinuxから設定する方法

Micrichip社のLAN9514というICがあります。

USBのハブとホストに加え100BASEのUSB-LANを搭載しているICで、コネクタをつなぐだけで4ポートのUSBホストと100BASEのLANが実現できます。

Lan9514

RaspberryPiやZynqberryにも搭載されています。(RaspberryPiではEEPROMにMACアドレスを書いていないという話もあるので、この方法で変わるかどうかは試していない。ZynqberryはOK)

このICが作るLANのMACアドレスはEEPROMに設定されていなければ電源を投入するたび(リセットするたび)ランダムで決まります。

ランダムになってしまうと、例えばDHCPサーバが割り当てるIPアドレスがリブートのたびに変わるので、困る場合があります。例えば、Windowsでホスト名でファイル共有をするのに時間がかかるとか。

そこで、このICのMACアドレスをLinuxから設定することを試してみました。

LAN9514のEEPROMを設定するには、まずデバイスドライバを読んでみたところethtoolsという構造体があったので、ethtoolsとは何ぞやということで調べてみると、PHYの管理などができるそういうツールがあるようです。

これはZYNQのLinuxからサクッとapt-getでインストールできました。

zynqberry@zynqberry:~$ sudo apt-get install ethtool
[sudo] password for zynqberry:
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
bind9-host geoip-database libavahi-core7 libbind9-90 libdaemon0 libdns100
libgeoip1 libisc95 libisccc90 libisccfg90 liblwres90
これを削除するには 'apt-get autoremove' を利用してください。
以下のパッケージが新たにインストールされます:
ethtool
アップグレード: 0 個、新規インストール: 1 個、削除: 0 個、保留: 0 個。
84.5 kB のアーカイブを取得する必要があります。
この操作後に追加で 284 kB のディスク容量が消費されます。
取得:1 http://ports.ubuntu.com/ubuntu-ports/ trusty/main ethtool armhf 1:3.13-1 [84.5 kB]
84.5 kB を 1秒 で取得しました (74.3 kB/s)
以前に未選択のパッケージ ethtool を選択しています。
(データベースを読み込んでいます ... 現在 50239 個のファイルとディレクトリがイン ストールされています。)
Preparing to unpack .../ethtool_1%3a3.13-1_armhf.deb ...
Unpacking ethtool (1:3.13-1) ...
ethtool (1:3.13-1) を設定しています ...

起動してみます。一般ユーザでやる場合はsudoを付けてください。

zynqerry@zynqberry:~$ sudo ethtool -e eth0
Offset Values
------ ------
0x0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

初期状態では、中身は全部FFのようです。

ethtoolsを使ってEEPROMを書き込むには、ethtools -E eth0 の後ろにmagicやoffset、lengthを指定する必要があります。LAN9514のmagicは0x9500です。offsetはEEPROMの何番地から書き込むかで、これは0。lengthは140にします。

書き込むべきデータはLAN9514のデータシートに載っているので、それをコピペするなどしてテキスト化し、それをもとにバイナリファイルを作ります。Linuxで16進のテキストからバイナリ列を作るには、echoの後ろに-enを付けて、エスケープシーケンスを含んだ文字列を書けばよいようです。

echo -en "\xA5\x12\x34\x56\x78\x9A\xBC\x01\x04\x05\x09\x04\x0A\x1D\x00\x00\x00\x00\x00\x00\x00\x00\x12\x22\x12\x2B\x12\x34\x12\x3D\x00\x00\x24\x04\x14\x95\x00\x01\x9B\x18\x00\x02\x00\x00\x01\x00\x01\x00\x32\x00\x00\x00\x00\x00\x21\x43\x05\x01\x0A\x03\x53\x00\x4D\x00\x53\x00\x43\x00\x12\x01\x00\x02\xFF\x00\x01\x40\x24\x04\x00\xEC\x00\x01\x01\x00\x00\x01\x09\x02\x27\x00\x01\x01\x00\xE0\x01\x09\x04\x00\x00\x03\xFF\x00\xFF\x00\x12\x01\x00\x02\xFF\x00\xFF\x40\x24\x04\x00\xEC\x00\x01\x01\x00\x00\x01\x09\x02\x27\x00\x01\x01\x00\xE0\x01\x09\x04\x00\x00\x03\xFF\x00\xFF\x00" > eeprom.bin

これで140バイトの設定データが出来ました。

上の赤い部分がMACアドレスなので、必要に応じて書き換えてください。なお、最初の1バイトのbit1が'1'になっている(つまり0x02)MACアドレスはプライベートアドレスなので、自分の責任で自由に使うことができます。

ethtool -E eth0 magic 0x9500 offset 0 length 140 < eeprom.bin

これで書き込まれました。
確認してみましょう

zynqberry@zynqberry:~$ sudo ethtool -e eth0
Offset Values
------ ------
0x0000: a5 12 34 56 78 9a bc 01 04 05 09 04 0a 1d 00 00
0x0010: 00 00 00 00 00 00 12 22 12 2b 12 34 12 3d 00 00
0x0020: 24 04 14 95 00 01 9b 18 00 02 00 00 01 00 01 00
0x0030: 32 00 00 00 00 00 21 43 05 01 0a 03 53 00 4d 00
0x0040: 53 00 43 00 12 01 00 02 ff 00 01 40 24 04 00 ec
0x0050: 00 01 01 00 00 01 09 02 27 00 01 01 00 e0 01 09
0x0060: 04 00 00 03 ff 00 ff 00 12 01 00 02 ff 00 ff 40
0x0070: 24 04 00 ec 00 01 01 00 00 01 09 02 27 00 01 01
0x0080: 00 e0 01 09 04 00 00 03 ff 00 ff 00 ff ff ff ff
0x0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0100: a5 12 34 56 78 9a bc 01 04 05 09 04 0a 1d 00 00
0x0110: 00 00 00 00 00 00 12 22 12 2b 12 34 12 3d 00 00
0x0120: 24 04 14 95 00 01 9b 18 00 02 00 00 01 00 01 00
0x0130: 32 00 00 00 00 00 21 43 05 01 0a 03 53 00 4d 00
0x0140: 53 00 43 00 12 01 00 02 ff 00 01 40 24 04 00 ec
0x0150: 00 01 01 00 00 01 09 02 27 00 01 01 00 e0 01 09
0x0160: 04 00 00 03 ff 00 ff 00 12 01 00 02 ff 00 ff 40
0x0170: 24 04 00 ec 00 01 01 00 00 01 09 02 27 00 01 01
0x0180: 00 e0 01 09 04 00 00 03 ff 00 ff 00 ff ff ff ff
0x0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

ちゃんと書き込まれているのがわかります。

起動時のメッセージを見ると、今まではランダムになっていたのが、

[    2.669168] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 2.675982] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2.686405] smsc95xx v1.0.5
[ 2.784367] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-ci_hdrc.0-1.1, smsc95xx USB 2.0 Ethernet, fe:c0:42:d9:23:f9
[ 7.477999] EXT4-fs (mmcblk0p2): recovery complete
[ 7.485256] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 7.493315] VFS: Mounted root (ext4 filesystem) on device 179:2.

下のように設定したが使われているのがわかります。

[    2.663831] init: ureadahead main process (1120) terminated with status 5
[ 2.688673] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 2.695469] usb 1-1.1: New USB device strings: Mfr=1, Product=0, SerialNumber=0
[ 2.705719] usb 1-1.1: Manufacturer: SMSC
[ 2.718420] smsc95xx v1.0.5
[ 2.823765] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-ci_hdrc.0-1.1, smsc95xx USB 2.0 Ethernet, 12:34:56:78:9a:bc

ifconfigで見てみると、

eth0      Link encap:イーサネット  ハードウェアアドレス 12:34:56:78:9a:bc
inetアドレス:192.168.1.215 ブロードキャスト:192.168.1.255 マスク:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 メトリック:1
RXパケット:99 エラー:0 損失:14 オーバラン:0 フレーム:0
TXパケット:75 エラー:0 損失:0 オーバラン:0 キャリア:0
衝突(Collisions):0 TXキュー長:1000
RXバイト:8532 (8.5 KB) TXバイト:9821 (9.8 KB)

lo Link encap:ローカルループバック
inetアドレス:127.0.0.1 マスク:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 メトリック:1
RXパケット:106 エラー:0 損失:0 オーバラン:0 フレーム:0
TXパケット:106 エラー:0 損失:0 オーバラン:0 キャリア:0
衝突(Collisions):0 TXキュー長:1
RXバイト:5300 (5.3 KB) TXバイト:5300 (5.3 KB)

ちゃんと書き変わりました。

なお、ethtoolsでは、140バイトのデータを正しく書かないとLAN9514が起動しなくなってしまいます。その場合はEEPROMを物理的に外すなどの処置が必要になるので多少の危険を伴います。最初の7バイトだけを書き込んだら動かなくなったので、復旧に苦労しました。

 

もっと簡単な方法としては、

ifconfig eth0 down
ifconfig eth0 hw ether 02:01:02:03:04:05
ifconfig eth0 up

で設定してしまうことです。これを/etc/rc.localに書いておけば起動時に設定されます。

ZYNQの内蔵のGigabitEtherは、Linuxのドライバの問題によりこの方法ではMACアドレスを変更できませんが、LAN9514経由のUSB-LANであればifconfigでMACアドレスを変更できるので、より安全で手軽です。

ユーザがSDカードをどんなふうに書き換えても動くようにハード的に固定値を書き込んでおきたいという場合にはethtooslでEEPROMに書き込むのがよいでしょう。

 

| | コメント (0)

2019.04.07

ZYNQのLinuxでMPC79411というRTCを使う方法

Microchip社のリアルタイムクロックMPC79411をZYNQのLinuxから使うには、DeviceTreeに以下のように書きます。

i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
status = "okay";
clocks = <0x1 0x26>;
interrupt-parent = <0x4>;
interrupts = <0x0 0x19 0x4>;
reg = <0xe0004000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
clock-frequency = <0x61a80>;
rtc@6F {
compatible = "mcp7941x";
reg = <0x6f>;
};
};

この6FというのがI2Cのデバイスアドレスで、compatible="mpc7941x"と書くことで起動時に探されます。clock-frequency=<0x61a80>というのはI2Cのクロックを400kHzにするという意味です。ぴったり400kHzになります。

# dtc -I dts -O dtb devicetree.dts > /mnt/devicetree.dtb

でデバイスツリーを作り、rebootします。

MPC79411のドライバはDS1307用の汎用RTCドライバを用いているので、起動時にはDS1307のドライバで認識され、

[    1.304585] i2c /dev entries driver
[ 1.308235] cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 23
[ 1.315197] rtc-ds1307 0-006f: SET TIME!
[ 1.320404] rtc-ds1307 0-006f: rtc core: registered mcp7941x as rtc0
[ 1.326682] rtc-ds1307 0-006f: 64 bytes nvram
[ 1.331237] cdns-i2c e0005000.i2c: 400 kHz mmio e0005000 irq 24

と、起動時に認識されます。

MPC79411はアドレス0のbit7がSTARTビットといってカウントを開始するためのレジスタとなっていて、アドレス3のbit3がバッテリバックアップの有効化ビットなので、これらをONにしないと動きません。

そのため、必ずMPC7941Xを指定してDS1307ドライバを使う必要があります。

これで電源が落ちても時間を保持できます。

» 続きを読む

| | コメント (0)

2019.04.05

ZYNQでEMIO経由でI2Cを動かす方法

ZYNQのI2CをEMIO経由で出すデザインを作ったのですが、全く信号が出てこないので困っていました。

I2CをEMIO経由で出すとIIC_0とIIC_1という2つのバスが出てきて、この中にはSDAとSCLの信号がI,O,Tで3本ずつ通っています。

I2cdesign5

このIIC_0の信号を外に出すために、次のようなコードを書いていたのですが、

	i2c_iobuf_inst : IOBUF port map (
IO => sda1_io,
O => sda1_o,
I => sda1_i,
T => sda1_t
);
scl1_io <= scl1_i;
sda2_io <= sda2_i;
scl2_io <= scl2_i;
scl1_o <= '0';
sda2_o <= '0';
scl2_o <= '0';

信号が何も出てこないという結果となっていました。

I2Cがそもそも動いていないのか、初期化などに失敗しているのかと考えられました。

しかし、PLはそのままにしてPSだけ修正し、I2CをEMIOに通すようにしたら、なんと、I2Cの信号が出てくるようになったのです!

I2cdesign4

U-BOOTでi2c probeを実行し、その時のPLの中の波形をMITOUJTAGを使ってみてみると、ぴったり100kHzのクロックで出てきています。

I2cdesign6

波形を目で読んでみると、0x03,0x05,0x07,0x09・・・と奇数番地にアクセスしています。

しかし、EMIOデザインにするとこの波形も出てきません。

Vivadoのバグかと思ってVivado2018.3にアップデートしてみても変化なし。

もうわけがわからないので、徹底的にデバッグすることにしました。

まず、EMIOを通すデザインとMIO50,51から出すデザインの2つを作って、export hardwareを行い、ps7_init.tclの内容を比べてみると、

mask_write 0XF80007C8 0x00003FFF 0x00001300
mask_write 0XF80007CC 0x00003FFF 0x00001300

mask_write 0XF80007C8 0x00003FFF 0x00001340
mask_write 0XF80007CC 0x00003FFF 0x00001340

になっているという程度の違いでした。

この0xf80007c8と0xf80007ccのレジスタ以外の違いはありません。ug585を読むとMIO50/51をGPIOにするかI2Cにするかの選択だけで、それ以外の変化はありませんでした。

I2cdesign7

したがって、MIO50から出てくるのであればI2Cのモジュール自体は正しく設定されていて、動いているといえるでしょう。

すると、MIOから出すのとEMIOから出すの違いは一体何なのか。

実はMIO50とMIO51に入力される値の違いと、SDA_OやSCL_Oは'0'から動かないということでした。

まず、上にあるMITOUJTAGの波形を見てみるとわかりますが、動いているのはSDA_TとSCL_Tであって、scl1_iとsda1_i
は常に'0'となっています。

I2cdesign12

つまり、I2Cの信号を出力するときには、SCLとSDAはトライステートバッファを利用して、0かZかを出力しろというわけです。

したがって、

scl1_io <= scl1_i;

という書き方はダメで、SCLについてもIOBUFTを使うか、

scl1_io <= '0' when (scl1_t = '0') else '1';

と書かなければいけないようです。

もう一つはZYNQコアのSCL_Iに入れる値を'0'のままに固定してはいけないということです。具体的には、

scl1_o <= '0';

というのが間違っていて、

scl1_o <= '1';

にしなければならなかったのです。

入力値が'0'のままだとZYNQのI2C内蔵ペリフェラルは動作をしてくれないようです。

まとめると、

i2c_iobuf_inst : IOBUF port map (
IO => sda1_io,
O => sda1_o,
I => sda1_i,
T => sda1_t
);
scl1_io <= '0' when (scl1_t = '0') else '1';
scl1_o <= '1';

にするか、SCLに対しても

i2csda_iobuf_inst : IOBUF port map (
IO => sda1_io,
O => sda1_o,
I => sda1_i,
T => sda1_t
);
i2cscl_iobuf_inst : IOBUF port map (
IO => scl1_io,
O => scl1_o,
I => scl1_i,
T => scl1_t
);

と、3ステートバッファを使えばよいようです。

SDAだけではなくSCLについても、素直にIOBUFTを使えばよかったのですね。

I2CにつないだRTCのMPC79411も動くようになり、Linux起動時に下記のような波形が出てきました。

I2cdesign8

内蔵レジスタも読めた!

I2cdesign13

こんなことで1週間近くもハマっていました。

てゆーか、AR#56858によれば末尾に_t、_o、_iが付いている信号は自動的にIOBUFTが推論されるそうなので、そもそもIOBUFTをラッパするだけのIPなんていうのは作る必要さえなかったようでした。IP CatalogのUtility bufferにIOBUFTが無い理由はそこにあるのかもしれません。

結論を言うと、これでよいようです。

I2cdesign9

バスの信号をそのままMake Externalするのはとても心理的抵抗があるのですが、Vivadoは信号名の末尾に_i,_o,_tという信号を見つけると、自動的にIOBUFTを入れて、_ioという名前の信号に置き換えてしまうので、HDL Wrapperの出力は

I2cdesign10

となります。

XDCファイルには

I2cdesign11

と、_ioの名前でピン配置を指定すればよいというわけです。

やらなくていいことを自分でやろうとしてI2Cが動かないという結果になっていた典型的なパターンでした。もう少しVivadoを信頼してもいいのかもしれません。

 

| | コメント (0)

2019.04.04

TrenzElectronicの製品を続々入荷中

TrenzElectronic製品は納期が3か月から半年かかるものもざらです。

そんな製品たちを、半年前に注文していたものがぞくぞく入荷しています。

TE0720-03-2IFTE0720-03-1CFA

Te0720

ZYNQのXC7Z020を搭載した標準的なSoCモジュール。Trenz社の代表的なZYNQボードなのに、納期が3か月程度かかりますが、今なら在庫があります。

ちなみに、2IFの方が高性能です。1CFAというのはスピード・温度グレードが1Cのもので、AはSPI ROMの型番が変わったことを意味しています。

TE0808-04-09EG-2IE

Te0808 

Zynq UltraScale+ ZU9EGという大容量のFPGAと、4 GByte DDR4 SDRAMを搭載たウルトラ級のボード。自動運転やAIの研究・開発、そしてコンパクトなサイズを活かしてAIの組み込みに最適です。

納期が平均して半年くらいかかるので、いま入手しないと次に手に入るのは秋ごろになるかもしれません。

TEC0053-04-K1

SDSoCを使ってモータコントロール回路を作るというチュートリアル的なボードです。

Tec0053

かくいう私もこのボードで勉強してSDSoCの使い方が理解できました。

昨年の11月にオーダーしてようやく入荷という超長納期ボードです。

 

TE0715-04-30-1IA

4×5cmの小さい基板にXC7Z030を詰め込んだ高密度ボード。いったいどうやったらこのサイズに詰め込めるのか?その技術を探ってみたい。

2個売れたので、在庫は残り1個。即納可能。

Te0715

 

ここに挙げた以外にも、TrenzElectronic社のボードをいろいろ在庫していますし、取り寄せもいたします。

https://www.trenz.jp/ へ。

 

| | コメント (0)

2019.04.03

EMIOからI2Cの信号が出てこない

開発中のZYNQボードでI2Cの通信がしたいのですが、EMIOからI2Cの信号が出てきません。

なぜなんでしょう。

ZYNQから生えているI2Cの信号は、SCL_I、SCL_O、SCL_T、SCA_I、SDA_O、SDA_Tの6本で、これをOBUFTでバッファするためだけのIPを作って通しています。

I2cdesign1_1

I2C0を叩いても、I2C1を叩いても、うんともすんとも言いません。

でも、EMIOではなくMIO50、MIO51などを使うデザインにすると、信号が出てきます。

U-Bootにはi2cコマンドというのが、あって、i2c probeとやるとデバイスアドレスの00~FFまでをスキャンして何かいるかを探してくれます。

I2cdesign3

I2C probeを実行している間、MIOの端子は下の波形のようにパタパタと動いています。

I2cdesign2

さて、何が原因なのでしょう。

 

| | コメント (0)

2019.04.02

MITOUJTAGでDigilentのUSB-JTAGが使えるようになった

MITOUJTAGで、DigilentのUSB-JTAGを認識させようとすると、ケーブル自体は認識されるのですが、下の図のようにNo Response. Cable downと出てしまいます。

Mj_usbjtag

この原因もようやくわかりました。

ログを見ると、

2019/04/02 11:23:11 XILCABLE: Attempting to launch hw_server...|
2019/04/02 11:23:11 XILCABLE: |****** Xilinx hw_server v2013.3| **** Build date : Sep 24 2013-19:42:04| ** Copyright 1986-1999, 2001-2013 Xilinx, Inc. All Rights Reserved.||INFO: hw_server application started|INFO: Use Ctrl-C to exit hw_server application||INFO: Set the HW_SERVER_ALLOW_PL_ACCESS environment variable to 1 to access any PL address memory in the TCF debugger memory window.||
2019/04/02 11:23:11 XILCABLE: Connection established.|
2019/04/02 11:23:11 |***Error:Command CseJtag_target_getPin failed.|

となっていて、CseJtag_target_getPinというコマンドがエラーを起こしていることがわかります。

DigilentのHS-JTAG USB等ではこのコマンドは通るのですが、Embedded Platform Cable USBでは通らないようです。

MITOUJTAGでXILINXケーブルのオプションを開き、ケーブルタイプをxilinx_platformusbに変更すると、CseJtag_target_getPinも通るようになり、認識されるようになります。

Cse_setting_1

これで手近にあった基板につないで・・

Zynq_board

やった、認識した!動いたっ!

Usbjtagzynq

ちなみにログはこんな感じです。

2019/04/02 12:01:19 ローカルホストでCSE Serverを起動します
2019/04/02 12:01:19 Cse_Server : D:\xilinx\14.7\ISE_DS\ISE\bin\nt64\cse_server.exe found|
2019/04/02 12:01:21 XILCABLE: Connecting to cable (Usb Port - USB21).|
2019/04/02 12:01:21 XILCABLE: Checking cable driver.|
2019/04/02 12:01:21 XILCABLE: Driver file xusbdfwu.sys found.|
2019/04/02 12:01:21 XILCABLE: Driver version: src=1027, dest=1027.|
2019/04/02 12:01:21 XILCABLE: Driver windrvr6.sys version = 10.2.1.0.
2019/04/02 12:01:21 XILCABLE: WinDriver v10.21 Jungo (c) 1997 - 2010 Build Date: Aug 31 2010 x86_64 64bit SYS 14:14:44, version = 1021.|
2019/04/02 12:01:21 XILCABLE: Cable PID = 0008.|
2019/04/02 12:01:21 XILCABLE: Max current requested during enumeration is 74 mA.|
2019/04/02 12:01:21 XILCABLE: Type = 0x0004.|
2019/04/02 12:01:21 XILCABLE: Cable Type = 3, Revision = 0.|
2019/04/02 12:01:21 XILCABLE: Setting cable speed to 6 MHz.|
2019/04/02 12:01:21 XILCABLE: Cable connection established.|
2019/04/02 12:01:21 XILCABLE: Firmware version = 1303.|
2019/04/02 12:01:21 XILCABLE: File version of D:/xilinx/14.7/ISE_DS/ISE/data/xusb_xlp.hex = 1303.|
2019/04/02 12:01:21 XILCABLE: Firmware hex file version = 1303.|
2019/04/02 12:01:21 XILCABLE: PLD file version = 0012h.|
2019/04/02 12:01:21 XILCABLE: PLD version = 0012h.|
2019/04/02 12:01:21 XILCABLE: Type = 0x0004.|
2019/04/02 12:01:21 XILCABLE: ESN device is not available for this cable.|
2019/04/02 12:01:21 JTAGケーブル xilcable と接続しました
2019/04/02 12:01:21 このJTAGケーブルの詳細情報はありません

XILINXのケーブルにつなぐためにISE 14.7を介しているので、まだまだISEは手放せません。

 

| | コメント (0)

2019.04.01

令和ボードを作ります

新元号が令和に決まりましたね。

とても良い響きだと思います。

この国の一大イベントで、自分にも何かできることはないかと思い、「令和」と記された基板を作ることにしました。

昨年開発していたSpartan-7ボードに「奉祝🇯🇵令和元年」とシルクで刻印してみました。

Reiwa1

点描画で描かれています。

Reiwa2

令和元年5月1日の発売が目標です。

| | コメント (0)

2019.03.31

DigilentのUSB-JTAG Programming Cableのドライバ

このDigilentのUSB-JTAG Programming Cableにはドライバがありません。

ドライバどころか、箱の中にはマニュアルさえありません。

デバイスドライバは、Firmware Loaderのまま止まっています。

何とかUG344にたどり着き、その中に記載されているug344_windows.zipをダウンロードすることはできました。

Ug344

UG344によればWindows7まではサポートされているようなのですが、Windows 10 64bitで動くかどうかはわかりません。何とかやってみましょう。

解凍してみると、install_xusb.batがあります。

Usbjtag8_1

nt64フォルダの中にはドライバやinf、catがあるので、これをインストールすればよさそうです。

Usbjtag9

基本的にはデバイスマネージャからではなく、install_xusb.batを実行するようです。

Usbjtag10

インストールが終わると、Xilinx USB Cableというそっけない感じのドライバが登録されました。

Usbjtag11

詳細を見てみると、2007/10/01の日付で、バージョンは2.0.0.2とあります。

Usbjtag12

プロパティを見ると、おおジュンゴ! これは嫌な予感しかしません。

Usbjtag13

実は、一発ではインストールは成功せず、いろいろガチャガチャやっているうちに、いつの間にか動くようになりました。

何をしたかというと、

  • Windowsアップデートからドライバを探す
  • ug344のドライバをインストール→うまくいかない
  • Vivado 2018.2のdata\xicom\cable_drivers\nt64の中にあるドライバを再インストール→認識しない
  • Vivado 2017.2のdata\xicom\cable_drivers\nt64の中にあるドライバを再インストール→認識成功
  • ug344のドライバを再インストール

Usbjtag15

わかってきたのは、このドライバはDLC9という、黒いPlatform USBの亜種であることです。

Vivado2018.2などの比較的新しいVivadoではなく、古い2017.2くらいのVivadoに付属のドライバを入れないとダメなようです。

下の図のように謎のエラーで止まってしまったり、認識すらされないようです。

Dlc9

Vivadoのフォルダのdata/xicomは拡張機能の宝庫なので、ここを探すといろいろなお宝が見つかります。

2017.2のドライバを入れ、ug344に戻すと、Vivadoからも認識できるようになりました。

Usbjtag14

うまくいくポイントは、2017.2の中にあるinstall_drivers.exeを管理者権限で実行することのようです。

●ug344
2007/10/01 2.0.0.2 iMPACT・・OK Vivado 2018.2 OK

●Vivado 2017.2のdata/xicomからインストール
2007/10/26 2.0.0.3 iMPACT・・OK Vivado 2018.2 OK

●Vivado 2017.3
そもそもdata/xicomに該当ドライバがない

●Vivado 2017.4
そもそもdata/xicomに該当ドライバがない

●Vivado 2018.1
そもそもdata/xicomに該当ドライバがない

●Vivado 2018.2のdata/xicomからインストール
2007/8/28 1.0.0.0 iMPACT・・NG Vivado 2018.2 NG

●Vivado 2018.3
そもそもdata/xicomに該当ドライバがない

 

必ずしも新しいVivadoが良いというわけではなく、古いVivadoが必要になるようでした。

Vivado 2018.2をパッケージングした際の手違いのような気がしますが。

| | コメント (0)

«Digilentの古いUSB-JTAG Programming Cableを試す(1)