xc3sprog-users — Generic user and developer list

[Xc3sprog-users] About the D2XX library and other things

[Joris v. R. <jo...@sr...>]

Hi Uwe,

Thanks again for your excellent work on XC3SPROG.
I just upgraded to SVN r632, and I'd like to make a few comments.

There seems to be no way to make xc3sprog read a custom cablelist.txt
file at run time. I think this is unintentional, so I filed a bug report
in the SF tracker.

Xc3sprog now requires the FTDI D2XX library in order to compile. It
used to be a compile-time option. I think it is very unpractical for a
free software project to have a hard dependency on a closed-source
library. Especially since libD2XX does not seem to offer any advantage
over libftdi.

Would you consider making the use of D2XX optional again? For my own
purpose, I have put the "#ifdef USE_FTD2XX" conditionals back in place
so that I can compile without D2XX. I can send you the diff if you like.

If you are only concerned about the ifdef-mess in the source code, I
am willing to do some cleanup work. I believe the choice between
D2XX/libftdi can be isolated in a very small part of ioftdi.cpp.

Lastly, my feeling is that the built-in help message of xc3sprog has
become a little less user friendly over the last year. In particular,
the "-p" option is not mentioned. I consider myself an experienced user
of xc3sprog, yet I had to look in the source code to figure out how to
run it.

Greetings, Joris van Rantwijk.

Re: [Xc3sprog-users] Digilent JTAG HS1 cable

[Joris v. R. <jo...@sr...>]

On 2011-07-29, Joris van Rantwijk <jo...@sr...> wrote:
> The JTAG HS1 cable from Digilent looks interesting; cheap, fast and
> compact. However it seems to use a closed protocol.
> http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,395,922&Prod=JTAG-HS1

For the record: It turns out that the cable is based on an FT2232 chip.

XC3SProg already supports FTDI-based cables, but this HS1 cable is wired
slightly differently. It can be supported by adding the following line
to the cable database, cablelist.txt:

jtaghs1  ftdi  0x0403:0x6010::0:0x80:0x80:0x00:0x0  1500000

The cable can then be accessed as "xc3sprog -c jtaghs1 ...."
It seems to work very well, although I have only tested with one board
so far.

Uwe, could you add this line to the cable file in the repository?

Thanks,
Joris van Rantwijk.

[Xc3sprog-users] Digilent JTAG HS1 cable

[Joris v. R. <jo...@sr...>]

Hello,

I am looking to replace my old parallel JTAG cable.

The JTAG HS1 cable from Digilent looks interesting; cheap, fast and
compact. However it seems to use a closed protocol.

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,395,922&Prod=JTAG-HS1

I'm toying with the idea of ordering this cable and trying to add
support to xc3sprog.

Has anyone here used this cable?
Any idea how it works on the inside?

Thanks,
Joris van Rantwijk.

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:

    Joris> On Friday, July 09, 2010 11:15:13 Uwe Bonnes wrote:
    >> What is the program time now?

    Joris> About 480 seconds to program 24 Mbit.

Versus 140 in Impact. Bad...

    Joris> In the Linux kernel that I used, the option for high resolution
    Joris> timing was turned off. Today I figured out that high resolution
    Joris> timing greatly improves the accuracy of usleep. I will enable
    Joris> this setting and test again next week.

At some point in time I will switch to libusb-1.0 and use asynchronous
read. This could bring downprogramming time to.

    >> Btw: Any chance to look at the TDO driving gate on the S3 kit?

    Joris> I did not precisely understand your remarks (I'm not an
    Joris> electronics engineer). But let's try. On the S3 starter kit
    Joris> schematics, the type of IC2A is not specified. On the actual
    Joris> board, I can see an IC2 which is a tiny surface mounted thingy,
    Joris> marked something like "WOC".

Any manufacturer sign visible?
The smd marking sites don't bring anything sensible with WOC. But I think it
is a "strong" device.

    Joris> The Pender GR-XC3S1500 also fails with the parallel cable. Its
    Joris> schematic shows that TDO is driven directly from the FPGA's TDO
    Joris> pin without any components in between.

But the FPGA TDO output should also be "strong", so it will win against the
"weak" HC125 on the DLC5. On my clone is a "strong" LVC125, so my results
are different.

I will drop this unreliable test soon.

    Joris> Just to be sure, let me say again that the issue is only with the
    Joris> check for "missing power" at initialization time (which then
    Joris> aborts the program). If that check is skipped, programming with
    Joris> the parallel cable works absolutely fine for me.

Another reason to drop the test.

Cheers
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Joris v. R. <jo...@sr...>]

On Friday, July 09, 2010 11:15:13 Uwe Bonnes wrote:
> What is the program time now?

About 480 seconds to program 24 Mbit.

In the Linux kernel that I used, the option for high resolution timing 
was turned off. Today I figured out that high resolution timing greatly 
improves the accuracy of usleep. I will enable this setting and test 
again next week.

> Btw: Any chance to look at the TDO driving gate on the S3 kit?

I did not precisely understand your remarks (I'm not an electronics 
engineer). But let's try. On the S3 starter kit schematics, the type of 
IC2A is not specified. On the actual board, I can see an IC2 which is a 
tiny surface mounted thingy, marked something like "WOC".

The Pender GR-XC3S1500 also fails with the parallel cable. Its schematic 
shows that TDO is driven directly from the FPGA's TDO pin without any 
components in between.

Just to be sure, let me say again that the issue is only with the check 
for "missing power" at initialization time (which then aborts the 
program). If that check is skipped, programming with the parallel cable 
works absolutely fine for me. 

Greetings, Joris.

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:

...
    Joris> I added it as a second file under the XCFxxxP ticket.  (Sorry.)

What is the program time now?

Btw: Any chance to look at the TDO driving gate on the S3 kit?

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Programming Virtex-5 FPGAs

[Joris v. R. <jo...@sr...>]

On Wednesday, July 07, 2010 19:47:34 Uwe Bonnes wrote:
> >>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
> Joris> XCF32P, so it should be considered experimental. I'm
> Joris> look at Virtex 5 as well, but I have no idea what
> Joris> of that.
> 
> We now have V4 hardware in house, so I either can test your code or you
> mine...

I submitted an attempt at Virtex-5 programming. It has only been tested on 
XC5VSX50T but it should in theory work for all Virtex-5.

The Spartan-3 flow also works for Virtex-5, so it was just a matter of 
tweaking the XC3S code. Much easier than I had anticipated.

There were a few Virtex-5 ID codes in devlist.txt that are not consistent 
with the information in the Xilinx BSDL files. I updated those entries to 
match the BSDL files. But if the old entries came from a more reliable 
source, they should of course not be changed.

Greetings, Joris.

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Joris v. R. <jo...@sr...>]

On Thursday 08 July 2010 18:25:24 Uwe Bonnes wrote:
> Could it be that IMPACT polls for erase/write reporting finished while your
> approach uses fixed maximum timing?

This is exactly what I change in the latest patch.
Plus my maximum timing was too short.

> I don't see a patch in the tracker yet

I added it as a second file under the XCFxxxP ticket.
(Sorry.)

Joris.

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:

    Joris> On Wednesday 07 July 2010 19:46:03 Uwe Bonnes wrote: I noticed
    Joris> that programming big files is quite slow (20 minutes for a 20
    Joris> Mbit image). I'm using a Xilinx DLC10 USB programmer.
    >>  What are Impact programming times?

    Joris> Much faster, about 140 seconds for erasing plus programming.
    Joris> With xc3sprog, programming takes between 320 and 980 seconds,
    Joris> depending on the Linux timer frequency (1000 or 100 Hz).

Could it be that IMPACT polls for erase/write reporting finished while your
approach uses fixed maximum timing?

I poll for these time in progalgspi.cpp.

For read request, also asynchronous read might improve speed/

    Joris> There is a slight change to the XCFP programming loop that I'd
    Joris> like to make (patch in sourceforge tracker). My previous code
    Joris> would actually sleep shorter than the recommended time between
    Joris> commands.

I don't see a patch in the tracker yet

    >> Xc3sprog used the reversed engineered devices handling from
    >> ixo.de. Perhaps impact uses not-yet documented APIs for those big
    >> chunks. Can you perhaps send some log like the Linux usbmon api
    >> delivers?

    Joris> I captured a usbmon log file. It looks like Impact uses only A6
    Joris> commands during programming, just like xc3sprog. However Impact
    Joris> always sends large packets, 9398 bytes.

    Joris> I'm thinking that my programming time may be mostly due the
    Joris> Usleep calls in the algorithm. Short sleeps (10 - 100 us) may be
    Joris> rounded up by the OS scheduler, so this is very inefficient.

    Joris> In fact I think xc3sprog could be a lot smarter about sleeping
    Joris> when a USB programmer is used. If the bit rate of the programmer
    Joris> is known, sleeping could be done much more accurately inside the
    Joris> programmer by inserting NOPs in the bit stream. I think this is
    Joris> how Impact handles it.

With infinite time writeing clever algorithms you can gains infinite amount
of programming time...


-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Joris v. R. <jo...@sr...>]

On Wednesday 07 July 2010 21:32:43 Uwe Bonnes wrote:
> Did you try the hints at 
> http://rmdir.de/~michael/xilinx/
> ?

Yes. It's a very nice solution and it works fine with ISE 12.1 on my laptop.

But for some reason it does not work with ISE 11.2 on my PC at work. It
just says "cable initialization failed" or something.

Greetings, Joris.

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Joris v. R. <jo...@sr...>]

On Wednesday 07 July 2010 19:46:03 Uwe Bonnes wrote:
>     Joris> I noticed that programming big files is quite slow (20 minutes
>     Joris> for a 20 Mbit image). I'm using a Xilinx DLC10 USB programmer.
> 
> What are Impact programming times?

Much faster, about 140 seconds for erasing plus programming.
With xc3sprog, programming takes between 320 and 980 seconds,
depending on the Linux timer frequency (1000 or 100 Hz).

There is a slight change to the XCFP programming loop that I'd like
to make (patch in sourceforge tracker). My previous code would actually
sleep shorter than the recommended time between commands.

> Xc3sprog used the reversed engineered devices handling from ixo.de. Perhaps
> impact uses not-yet documented APIs for those big chunks. Can you perhaps
> send some log like the Linux usbmon api delivers?

I captured a usbmon log file. It looks like Impact uses only A6 commands
during programming, just like xc3sprog. However Impact always sends large
packets, 9398 bytes.

I'm thinking that my programming time may be mostly due the Usleep
calls in the algorithm. Short sleeps (10 - 100 us) may be rounded up
by the OS scheduler, so this is very inefficient.

In fact I think xc3sprog could be a lot smarter about sleeping when
a USB programmer is used. If the bit rate of the programmer is known,
sleeping could be done much more accurately inside the programmer by
inserting NOPs in the bit stream. I think this is how Impact handles it.

Greetings, Joris.

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Wojciech A. K. <wk...@Fr...>]

On Wed, Jul 07, 2010 at 06:36:19PM +0200, Joris van Rantwijk wrote:
> Hello,
> 
> I just submitted a patch to support Xilinx XCFxxP series flash PROMs.
> It seems to work but it has only been tested with XCF32P, so it should
> be considered experimental. I'm planning to look at Virtex 5 as well,
> but I have no idea what will come out of that.
> 
> I noticed that programming big files is quite slow (20 minutes for a
> 20 Mbit image). I'm using a Xilinx DLC10 USB programmer.
> 
> What is currently the fastest cable type for xc3sprog?
> 
> Also, I'd like to mention again that the Xilinx Parallel Cable III still
> does not work for me. It says "Missing power for Parallel Cable III".

Hi Joris,

You probably want to get a USB cable of any kind. It should be faster.
There's a hack we talked about on this mailing list in the past. It's all
about how to enable Xilinx Parallel Cable III. Unless Uwe decides to commit
it you may want to browse the archives and apply the fix temporarily and let
us know, whether it fixes a problem in your case.

-- 
Wojciech A. Koszek
wk...@Fr...
http://FreeBSD.czest.pl/~wkoszek/

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <J.F...@sr...> writes:

...
    Joris> I don't know; could not get Impact to work on Linux :-).  I will
    Joris> check tomorrow on a different machine.

Make sure that your ISE/Impact installation has loaded the FX2 hex files on
your system. For me on Linux these files are loaded to /usr/share

/usr/share> ls -l *hex
-rw-r--r-- 1 root root 22231 25. Jul 2009  xusbdfwu.hex
-rw-r--r-- 1 root root 22274 25. Jul 2009  xusb_emb.hex
-rw-r--r-- 1 root root 22274 25. Jul 2009  xusb_xlp.hex
-rw-r--r-- 1 root root 23542 25. Jul 2009  xusb_xp2.hex
-rw-r--r-- 1 root root 21275 25. Jul 2009  xusb_xpr.hex
-rw-r--r-- 1 root root 23542 25. Jul 2009  xusb_xse.hex
-rw-r--r-- 1 root root 22231 25. Jul 2009  xusb_xup.hex

You can find the hexfiles on the Xilinx site too.

The appropriate hex files are loaded on the initial VID/PID of the
dongle. For me this happens with udev and the file
/etc/udev/rules.d/xusbdfwu.rules

> cat /etc/udev/rules.d/xusbdfwu.rules
# version 0003
SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", MODE="666"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I
/usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xup.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I
/usr/share/xusb_emb.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xlp.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="0013", RUN+="/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xp2.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",
SYSFS{idProduct}=="0015", RUN+="/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xse.hex -D $TEMPNODE"

You can load the hexfile with fxload by hand too. The arguments might
differ. There may also be a mismatch with large hexfiles and the arguments
in  xusbdfwu.rules. The -t argument amy need a change.

After a successfull load of the hexfile, the device reenumerates as
03fd/0008. This is the VID-PID combination xc3sprog looks for.

But as you tested the cable with xc3sprog, this seems to work fine.

Did you try the hints at 
http://rmdir.de/~michael/xilinx/
? 
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:

    Joris> Hello, I just submitted a patch to support Xilinx XCFxxP series
    Joris> flash PROMs.  It seems to work but it has only been tested with
    Joris> XCF32P, so it should be considered experimental. I'm planning to
    Joris> look at Virtex 5 as well, but I have no idea what will come out
    Joris> of that.

We now have V4 hardware in house, so I either can test your code or you
mine...

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Programming XCFxxP flash PROMs

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:

    Joris> Hello, I just submitted a patch to support Xilinx XCFxxP series
    Joris> flash PROMs.  It seems to work but it has only been tested with
    Joris> XCF32P, so it should be considered experimental. I'm planning to
    Joris> look at Virtex 5 as well, but I have no idea what will come out
    Joris> of that.

I checked in you patches. Please check that I got everything right. I would
appreciate if you add a copyright header with your name at least in the
progalgxcfp files.

    Joris> I noticed that programming big files is quite slow (20 minutes
    Joris> for a 20 Mbit image). I'm using a Xilinx DLC10 USB programmer.

What are Impact programming times?

Xc3sprog used the reversed engineered devices handling from ixo.de. Perhaps
impact uses not-yet documented APIs for those big chunks. Can you perhaps
send some log like the Linux usbmon api delivers?

    Joris> What is currently the fastest cable type for xc3sprog?

The FT2232H is quite fast and can be used for fast communication with a PC
too, look at the ftdi_stream.c code in libftdi-1.0. I use it on several
boards.
At present xc3sprog is very conservative with JTAG speed, but for an
on-board JTAG adapter the fast data rate of the FT2232H (5 up to 30 MBaud)
would improve speed. If the JTAG dongle is external and connected with
flying wires, speed has to be substantial slower (i.m.h.o.) as with an
om-board adapter.

A good approach should have some concept of JTAG speed with sensible
defaults and not hard code as ioftdi.cpp  at present.

Also asynchronous libftdi-read would improve read speed for big chunks.

    Joris> Also, I'd like to mention again that the Xilinx Parallel Cable
    Joris> III still does not work for me. It says "Missing power for
    Joris> Parallel Cable III".

Remote debugging hardware is hard. We have to single step throught the
ioparport code and measure the voltage level at relevant program steps and
decide where the algorithme is wrong.

I also don't have at hand if your setup is with a genuine DLC5 or some
clone.

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] Programming XCFxxP flash PROMs

[Joris v. R. <jo...@sr...>]

Hello,

I just submitted a patch to support Xilinx XCFxxP series flash PROMs.
It seems to work but it has only been tested with XCF32P, so it should
be considered experimental. I'm planning to look at Virtex 5 as well,
but I have no idea what will come out of that.

I noticed that programming big files is quite slow (20 minutes for a
20 Mbit image). I'm using a Xilinx DLC10 USB programmer.

What is currently the fastest cable type for xc3sprog?

Also, I'd like to mention again that the Xilinx Parallel Cable III still
does not work for me. It says "Missing power for Parallel Cable III".

Greetings, Joris.

[Xc3sprog-users] Missing power for Parallel Cable III

[Joris v. R. <jo...@sr...>]

Hello,

(this has also been reported in the Sourceforge tracker ...)

I get "Missing power for Parallel Cable III" when I run detectchain  
SVN r405 or SVN r440 with a Xilinx Parallel Cable III connected to my  
Digilent Spartan-3 200 board. I am certain that the hardware works  
and is correctly plugged in.

A while ago, SVN r405 used to work fine with a different Digilent  
board (Spartan-3E 1600).

I changed the code of ioparport.cpp to continue after the "Missing  
power" message. That makes the program work just fine.

Strangely, after I run the modified detectchain once, the "Missing  
power" message is absent on subsequent runs. Afterwards, the  
unmodified version of the program also works. Apparently something  
had gotten into a bad state, which got fixed by running the modified  
version of detectchain.

After putting a bitfile into the FPGA with xc3sprog, the "bad state"  
returned. Again, the "Missing power" message. Again one run of  
modified detectchain appears to fix it. The "bad state" does not  
return after unplugging/replugging the parallel cable. The "bad  
state" does return after unplugging/replugging the power of the  
Digilent board.

I added code to print the values of "status" and "data" at the point  
of the error message.
In the "Missing power" condition, status=0xde and data==0.
On subsequent runs, status==0xce and data==0.

All of this is perfectly reproducible so far.

Summary:
* Consistently "Missing power ..." message with Digilent Spartan-3  
200 board.
* One run with a modified version of detectchain makes the problem go  
away.
* Uploading a bitfile with xc3sprog makes the problem reappear.
* Power cycling the FPGA board makes the problem reappear.
* Replugging the parallel cable does not make the problem reappear.

I'm using Linux 2.6.32 on x86_64.

I suggest to turn the error into a warning, since that clearly  
increases the number of boards that can work with xc3sprog.
I'll make a patch, should be trivial.

Greetings, Joris.

Re: [Xc3sprog-users] xc3sprog on Linux - CPLD erase failed

[Uwe B. <bo...@el...>]

>>>>> "Vaclav" == Vaclav Peroutka <vac...@se...> writes:

Hello Vaclav,

there are still some pending question I asked regarding your first posting.

    Vaclav> Hello all, I found another problem with xc3sprog, I don't know
    Vaclav> if it is caused by myself or something in the sw. I programmed
    Vaclav> CPLD XC9572XL for the first time but second time I can't erase
    Vaclav> it. Please have a look below.

    Vaclav> Is it caused by older sw version which did not support erase ?
    Vaclav> Is there any newer version with erase supported ? Or is the
    Vaclav> error caused by something on my PCB ?

    Vaclav> Thank you in advance, Vaclav

    Vaclav> $ ./xc3sprog -v -c ftdi

With problems reports, be sure to give as muchy information as
possible. Don't fear to repeat agains a former message, as other people have
other problems and daytime work and probably won't remenber exact. E.g. what
kind is you cable?

On a XP machine, I tried recent SVN and could read the Chain, read out the
Jedec File, compare the Jedec file and program it twice.

I suspect your  cable isn't a pure FTDI cable, with no enable between the
FT2232 and the buffers. So probably you have to give a subtype. 
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] xc3sprog on Linux - CPLD erase failed

[Vaclav P. <vac...@se...>]

Hello all,

I found another problem with xc3sprog, I don't know if it is caused by myself or something in the sw. I programmed CPLD XC9572XL for the first time but second time I can't erase it. Please have a look below.

Is it caused by older sw version which did not support erase ? Is there any newer version with erase supported ? Or is the error caused by something on my PCB ?

Thank you in advance,
Vaclav

$ ./xc3sprog -v -c ftdi ../../programovani/xilinx/mzcard_2_addrdec/e_mz800arbiter.jed
Release $Rev: 215 $
Please provide feedback on success/failure/enhancement requests! Check Sourceforge SVN!
Using built-in device list
JTAG chainpos: 0 Device IDCODE = 0x59604093     Desc: XC9572XL
Programming: Device is not blank
Erase failed
USB transactions: Write 6 read 4 retries 4

Re: [Xc3sprog-users] detectchain r401 application error on Windows

[Uwe B. <bo...@el...>]

>>>>> "Vaclav" == Vaclav Peroutka <vac...@se...> writes:

    Vaclav> Hello, I downloaded xc3sprog r401 and wanted to run it on
    Vaclav> Windows. I start it with "detectchain.exe -c ftdi".

    Vaclav> Immediatelly, the error window appears - "The instruction at
    Vaclav> "0x7c90100b" referenced memory at "0x31683065".

    Vaclav> What is the problem ? FT2232 dongle is detected correctly and is
    Vaclav> on COM6 and COM7 ports.

Did you install libusb-win32? Does testlibusb-win.exe list the dongle?
I suspect so, as you write "FT2232 dongle is detected correctly", but your
wording is not exact. If the libusb basic layer works. What happens when you
press cancel on the "Application. Do you gat a backtrace? if not, any chance
you compile the program from source and debug a little?

Thanks
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] detectchain r401 application error on Windows

[Vaclav P. <vac...@se...>]

Hello,

I downloaded xc3sprog r401 and wanted to run it on Windows. I start it with "detectchain.exe -c ftdi".

Immediatelly, the error window appears - "The instruction at "0x7c90100b" referenced memory at "0x31683065".

What is the problem ? FT2232 dongle is detected correctly and is on COM6 and COM7 ports.

Am I doing something wrong ?

Best Regards, Vaclav

Re: [Xc3sprog-users] xc3sprog support for FreeBSD and the Spartan-3 Board 200K

[CeDeROM <tom...@gm...>]

Hello!

On Wed, Feb 10, 2010 at 3:59 PM, Grzegorz Behrens
<grz...@gm...> wrote:
> With those particular lines, I'm getting this error :
> (...)
> Missing power for Parallel Cable III
> Could not open parallel port /dev/ppi0
>
> without, it looks like this :
> (...)
> Found Xilinx Parallel Cable III

This happens because code does not want to run when cable is not
connected to a device, or the device is not powered on.
Reading parallel port might look different in different OS - so this
could be related to some ioctl reading parallel port control lines?
Where is the "power detect" line located - at data lines or control
lines?

Maybe the first invocation of the program sets the control register of
the parallel port and the second reads the value..? What happens if
the port is being read twice (two read functions before to detect
power?

Regads,
Tomek


-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [Xc3sprog-users] xc3sprog support for FreeBSD and the Spartan-3 Board 200K

[Grzegorz B. <grz...@gm...>]

>    Grzegorz> xc3sprog works, with FreeBSD 8 and the Spartan-3 Board 200K
>    Grzegorz> from Digilent, when this source code (in ioparport.cpp):
>
>    Grzegorz> if ((status & PCIII_TDO_MASK) && (!(data & PCIII_PROG_EN_N)))
>    Grzegorz> { fprintf(stderr,"Missing power for Parallel Cable III\n");
>    Grzegorz> return NO_CABLE;
>
> Could you please elaborate why this doesn't work on FreeBSD and your board?
> The check "works for me (R)" on linux and windows...
> --
> Uwe Bonnes                bo...@el...


With those particular lines, I'm getting this error :

darkstar# ./xc3sprog -d /dev/ppi0 -j -v
Release $Rev: 426 $
Free software: If you contribute nothing, expect nothing!
Please provide feedback on success/failure/enhancement requests!
Check Sourceforge SVN for updates!
Missing power for Parallel Cable III
Could not open parallel port /dev/ppi0

without, it looks like this :

darkstar# ./xc3sprog -d /dev/ppi0 -j -v
Release $Rev: 426 $
Free software: If you contribute nothing, expect nothing!
Please provide feedback on success/failure/enhancement requests!
Check Sourceforge SVN for updates!
Found Xilinx Parallel Cable III
Using built-in device list
JTAG chainpos: 0 Device IDCODE = 0x01414093	Desc: XC3S200
JTAG loc.: 0	IDCODE: 0x01414093	Desc:         XC3S200	IR length: 6
JTAG loc.: 1	IDCODE: 0xf5045093	Desc:          XCF02S	IR length: 8
Total bytes sent: 13

There is one interesting issue: using only once the software free from
the "Missing power for Parallel Cable III" code block causes  the
original one (without any modifications) to work correctly.

Re: [Xc3sprog-users] xc3sprog support for FreeBSD and the Spartan-3 Board 200K

[Uwe B. <bo...@el...>]

>>>>> "Grzegorz" == Grzegorz Behrens <grz...@gm...> writes:

    Grzegorz> xc3sprog works, with FreeBSD 8 and the Spartan-3 Board 200K
    Grzegorz> from Digilent, when this source code (in ioparport.cpp):

    Grzegorz> if ((status & PCIII_TDO_MASK) && (!(data & PCIII_PROG_EN_N)))
    Grzegorz> { fprintf(stderr,"Missing power for Parallel Cable III\n");
    Grzegorz> return NO_CABLE;

Could you please elaborate why this doesn't work on FreeBSD and your board? 
The check "works for me (R)" on linux and windows...
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Bringing FreeBSD support to xc3sprog.

[Wojciech A. K. <wk...@Fr...>]

On Tue, Feb 09, 2010 at 07:47:45PM +0100, Uwe Bonnes wrote:
> >>>>> "Wojciech" == Wojciech A Koszek <wk...@Fr...> writes:
> 
>     Wojciech> Was something wrong with the patch?
> 
> 
> Probably lost in work and mail overflow. Can you redo against recent
> SVN. Roger started xc3sprog 2004, so start copyright there. Also please
> check crosscompiling on Win32, at least with mingw. I don't see uname() in
> any mingw header ...

I've redone the patch.

	http://freebsd.czest.pl/~wkoszek/fpga/xc3sprog.2.patch

Pick stuff that you accept. I don't work too much with Windows, however here's
the patch that should address your problem with ifdef.

FreeBSD:

	wkoszek@laptop:/media/Multimedia/fpga/XC3SPROG/d/xc3sprog/trunk/build$ ./xc3sprog 
	XC3SPROG (c) 2004-2010 xc3sprog project $Rev$ OS: FreeBSD
	Free software: If you contribute nothing, expect nothing!
	Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 
	Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop for updates!
	Could not access parallel device '/dev/parport0': No such file or directory
	No cable selected. You must use -c option. See xc3sprog -h for more help

Qemu (Linux):

	 debian:~/xc3sprog/trunk/build# ./xc3sprog                                       
	 XC3SPROG (c) 2004-2010 xc3sprog project $Rev$ OS: Linux                         
	 Free software: If you contribute nothing, expect nothing!                       
	 Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?g
	 roup_id=170565                                                                  
	 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop 
	 for updates!                                                                    
	 Could not access parallel device '/dev/parport0': No such file or directory     
	 No cable selected. You must use -c option. See xc3sprog -h for more help        
	 debian:~/xc3sprog/trunk/build#                                                  

-- 
Wojciech A. Koszek
wk...@Fr...
http://FreeBSD.czest.pl/~wkoszek/