Followup: USB cable, Xilinx XUP, EDK/ISE 7.1, Fedora Core 3

- K
- Kris Heyrman
  
  Contact options for registered users
posted
18 years ago

Fri, Sep 2, 2005 7:33 AM

I have been working off and on trying to use the Xilinx XUP board on Linux Fedora Core 3 with EDK 7.1 and ISE 7.1. I have been fairly succesful with the software, but downloading the bitstream over the USB cable has got me baffled. It has worked a few times, but most of the time there seem to be errors in transmission and this makes the board trying to do this:

WARNING:iMPACT:2301 - Platform Cable USB firmware must be updated. This

operation may take up to 10 minutes on a USB 2.0 port

or up to 30 minutes on a USB 1.1 port. Please do not stop the process or

disconnect the cable prior to compeletion. The cable

STATUS LED will be RED for the duration of the update process.

In the process, I then get:

Doing update for waitTime.

and after a while:

write cmdbuffer failed 20000015.

When it works correctly, it is like this (downloading the Basic System Build):

Downloading Bitstream onto the target board

*********************************************

impact -batch etc/download.cmd

Release 7.1.03i - iMPACT H.41

// *** BATCH CMD : setMode -bs

// *** BATCH CMD : setCable -port auto

AutoDetecting cable. Please wait.

Connecting to cable (Parallel Port - parport0).

21:13:57.

parport0: baseAddress=0x378, ecpAddress=0x778

LPT base address = 0378h.

ECP base address = 0778h.

Cable connection failed.

Connecting to cable (Parallel Port - parport1).

21:13:57.

Cable connection failed.

Connecting to cable (Parallel Port - parport2).

21:13:57.

Cable connection failed.

Connecting to cable (Parallel Port - parport3).

21:13:57.

Cable connection failed.

Connecting to cable (Usb Port - USB21).

Checking cable driver.

File version of /home/krish/binaries/Xilinx/bin/lin/xusbdfwu.hex =

1018(dec),

03FA.

File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1018(dec),

03FA.

Calling setinterface num=0, alternate=0.

DeviceAttach: received and accepted attach for:

vendor id 0x3fd, product id 0x8, device handle 0x92d9af0

Max current requested during enumeration is 150 mA.

Cable Type = 3, Revision = 0.

Setting cable speed to 6 MHz.

Cable connection established.

Firmware version = 1018.

CPLD file version = 0006h.

CPLD version = 0006h.

// *** BATCH CMD : identify

Identifying chain contents ....Version is 0001

'1': : Manufacturer's ID =Xilinx xc2vp30, Version : 1

INFO:iMPACT:1777 -

Reading /home/krish/binaries/Xilinx/virtex2p/data/xc2vp30.bsd...

INFO:iMPACT:501 - '1': Added Device xc2vp30 successfully.

----------------------------------------------------------------------

Version is 0000

'2': : Manufacturer's ID =Xilinx xccace, Version : 0

INFO:iMPACT:1777 -

Reading /home/krish/binaries/Xilinx/acecf/data/xccace.bsd...

INFO:iMPACT:501 - '1': Added Device xccace successfully.

----------------------------------------------------------------------

Version is 1111

'3': : Manufacturer's ID =Xilinx xcf32p, Version : 15

INFO:iMPACT:1777 -

Reading /home/krish/binaries/Xilinx/xcfp/data/xcf32p.bsd...

INFO:iMPACT:501 - '1': Added Device xcf32p successfully.

----------------------------------------------------------------------

done.

Validating chain...

Boundary-scan chain validated successfully.

Elapsed time = 2 sec.

// *** BATCH CMD : identifyMPMElapsed time = 0 sec.

// *** BATCH CMD : setAttribute -position 3 -attr configFileName -value

"implementation/download.bit"

'3': Loading file 'implementation/download.bit' ...

done.

INFO:iMPACT:501 - '3': Added Device xc2vp30 successfully.

----------------------------------------------------------------------

// *** BATCH CMD : program -p 3

Validating chain...

Boundary-scan chain validated successfully.

'3':Programming device...

done.

'3': Reading status register contents...

CRC error : 0

Decryptor security set : 0

DCM locked : 1

DCI matched : 1

legacy input error : 0

status of GTS_CFG_B : 1

status of GWE : 1

status of GHIGH : 1

value of MODE pin M0 : 1

value of MODE pin M1 : 1

value of MODE pin M2 : 0

value of CFG_RDY (INIT_B) : 1

DONEIN input from DONE pin : 1

IDCODE not validated while trying to write FDRI : 0

write FDRI issued before or after decrypt operation: 0

Decryptor keys not used in proper sequence : 0

INFO:iMPACT:2219 - Status register values:

INFO:iMPACT - 0011 0111 1101 1000 0000 0000 0000 0000

INFO:iMPACT:579 - '3': Completed downloading bit file to device.

INFO:iMPACT:580 - '3':Checking done pin ....done.

'3': Programmed successfully.

Elapsed time = 5 sec.

// *** BATCH CMD : quit

----------------------------------------------------------------------

I am using a fully patched Fedora Core 3 system, with a locally compiled kernel 2.6.12-local (basically identical to

2.6.12-1.1372_FC3), have observed FPGA-FAQ 0044, Xilinx Answer #21650, and am using Jungo System's WinDriver v7.00 Jungo (c) 1997 - 2005 Build Date: Apr 26 2005. Xilinx patches for ISE and EDK have been applied.

Is there a good way to determine what is causing this unreliability? Are there any tests I can perform? I would be very grateful for any suggestions.

Kind regards,

Kris Heyrman Asst. Prof. in Electronics Hogeschool Gent (you can also respond to snipped-for-privacy@geenspam.hogent.be if you delete 'geenspam.')

- S
- S.T.
  
  Contact options for registered users
Vote on answer
posted
18 years ago

Tue, Sep 13, 2005 12:00 PM

So you are more successfull than i. I asked Xilinx about it 2 month ago and the answer was that in a later revision the usb adapter of the XUP will work. But it seems as if ise71sp4 still doesn't do the trick for me. But in my case i am not able to upload some code since the three chips are marked as unkown. Digging around i found that this seems to be a special version of the ez-usb device which needs a firmware loaded via fxload (take a look at the /etc/hotplug/usb/xusbdfwu xusbdfwu.fw files). My suspection is that this XUP doesn't work with the standard firmware distributed with ise71 (bin/lin/xusbdfwu.hex). Probably there is a way to extract this hex from a windows driver version. But at a first glance i found no hexfile in the windows ise.

ise xinfo tells you the exact version. Could you give me your version number? I would be interested which firmware is loaded into your board. does diff /etc/hotplug/xusbdfwu.fw/xusbdfwu.hex $XILINX/xusbdfwu.hex give some output?

The easiest way is to use an good old paralell cable V and connect with this cable. But i would also be really interested in a real usb solution :-(

Hope this helps S.T.

Hey Xilinx are you listening?

- P
- Paul Hartke
  
  Contact options for registered users
Vote on answer
posted
18 years ago

Tue, Sep 13, 2005 2:28 PM

Hi S.T.,

You don't mention which specific OS version or windrvr you are trying to use. As you probably know, only RHEL is officially supported. Various folks--including myself--have played around and gotten FC and other Linux distros to work. However, the further from RHEL the more likely you are to have issues.

Just making sure you have seen Xilinx solution records 18612 and 20762. Note that you certainly have to recompile the drivers as described for any other version of Linux you are using. The problem with the version numbers is discussed in SR2150 and has indeed been fixed in the latest service packs.

Paul

"S.T." wrote:

- S
- S.T.
  
  Contact options for registered users
Vote on answer
posted
18 years ago

Thu, Sep 15, 2005 7:12 AM

Hi Paul

I tried Centos 3 with ise71sp2 but i have got the same problems with undefined chips found. Since the automounter didn't work i switched back to debian sarge.

Ok, i have seen these, but 2150 isn't solved for me in sp4. I recompiled the whole drivers and tried even the jungo 7.0 version. I would be really interested which versions you have been using so i can rebuild it here.

Thanks S.T.