xc3sprog-users — Generic user and developer list

[Xc3sprog-users] Patch for TIAO USB Multi-Protocol Adapter

[Go L. Go <go...@ya...>]

Hi, I have patched xc3sprog source to works with TIAO USB Multi-Protocol Adapter (TUMPA) from here:

http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html

and manual:

http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27s_Manual

TUMPA uses FTDI's VID but they use their own PID 0x8a98, thus the ioftdi.cpp has to be patched:

Replace line 272:

          ((product != 0x6001) && (product != 0x6010) && (product != 0x6006)))

to:


          ((product != 0x6001) && (product != 0x6010) && (product != 0x8a98) && (product != 0x6006)))

File cablelist.txt:

add the following line:



tumpa         ftdi    0x0403:0x8a98:TIAO USB Multi-Protocol Adapter:1                                     1500000


That's it.

Can someone please update the source code? I am not sure if I am allowed to do so, if yes, I can do it.

thanks

[Xc3sprog-users] What product description string has BBV2/BBV2_2/jtaghs1 cable

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

Hello,

the BV2/BBV2_2/jtaghs1 cables entries in cablelist.txt have no cable
description string entry for now. As I don't have any of these cable, I
can't add the entries. Can people with these cables perhaps send me the
description string?

If there is no cable description string, any device on the USB bus with the
same VID/PID could be adressed by xc3sprog, depending on what device comes
first in the device tree.

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

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

Re: [Xc3sprog-users] Trouble opening FT2232-based "cable" with xc3sprog

[Matt <li...@bu...>]

On 05/12/12 15:35, Daniel Kirkham wrote:
> Hello,
> 
> I'm trying to get xc3sprog working to program an XC9572XL using an
> FT2232H-based module. I've managed to get it to compile, but it fails to
> open the device:
> 
>     % ./xc3sprog -c ftdi
>     XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 655 $ OS: Linux
>     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
> 
>     Could not open FTDI device (using libftdi): device not found
>     Unable to access FTDI device with either libftdi or FTD2XX
> 
> 
> The FT2232 works ok in UART mode, and starts up ftdi_sio and usbserial
> automatically, and other programs are opening the device ok (eg. my
> eeprom reprogramming code).
> 
> I have been building a variety of libusb and libftdi libraries (to
> program the FT2232H's EEPROM) so my linux setup now has a mix of
> libusb0.1, libusb1.0, libftdi1 and libftdi2, which may be complicating
> matters.
> 
>     % ldd ./xc3sprog 
>     linux-gate.so.1 =>  (0xb76ef000)
>     libftdi.so.1 => /usr/lib/libftdi.so.1 (0xb76db000)
>     libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb76d3000)
>     libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75dd000)
>     libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb75b7000)
>     libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7599000)
>     libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7453000)
>     /lib/ld-linux.so.2 (0xb76f0000)
> 
> 
> Here are some ltrace and strace outputs from near the end of the execution:
> 
> ltrace:
> 
>     ...
>     ftdi_new(0xbf8e0786, 0x9d32c36, 47, 0xb7791a16, 0xb74fe866)        
>                                       = 0x9d348e8
>     ftdi_set_interface(0x9d348e8, 0, 47, 0xb7791a16, 0xb74fe866)        
>                                      = 0
>     ftdi_usb_open_desc(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)          
>                                       = -3
>     ftdi_get_error_string(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)        
>                                      = 0xb777925b
>     fprintf(0xb762e560, "Could not open FTDI device (usin"...Could not
>     open FTDI device (using libftdi): device not found
>     )                                            = 61
>     ftdi_free(0x9d348e8, 0x807ee00, 0xb777925b, 0xbf8e0786, 0)          
>                                      = 4641
>     fwrite("Unable to access FTDI device wit"..., 1, 59,
>     0xb762e560Unable to access FTDI device with either libftdi or FTD2XX
>     )                                      = 59
>     exit(1 <unfinished ...>
>     +++ exited (status 1) +++
> 
> 
> The high level code seems to be looking for the correct device
> (0403:6010)...
> 
> strace:
> 
>     ...
>     open("/dev/bus/usb/002/001", O_RDWR)    = 3
>     ioctl(3, USBDEVFS_IOCTL, 0xbfdc79d4)    = 3
>     close(3)                                = 0
>     open("/dev/bus/usb/001",
>     O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>     getdents(3, /* 3 entries */, 32768)     = 48
>     open("/dev/bus/usb/001/001", O_RDWR)    = 4
>     ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdc79d8) = 0
>     read(4, "\22\1\20\1\t\0\0@k\35\1\0\6\2\3\2\1\1"..., 18) = 18
>     read(4, "\t\2\31\0\1\1\0\340"..., 8)    = 8
>     read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377"..., 17) = 17
>     close(4)                                = 0
>     getdents(3, /* 0 entries */, 32768)     = 0
>     close(3)                                = 0
>     open("/dev/bus/usb/001/001", O_RDWR)    = 3
>     ioctl(3, USBDEVFS_IOCTL, 0xbfdc79d4)    = 3
>     close(3)                                = 0
>     open("/dev/bus/usb/004/002", O_RDWR)    = 3
>     ioctl(3, USBDEVFS_CONTROL, 0xbfdc78a0)  = 4
>     ioctl(3, USBDEVFS_CONTROL, 0xbfdc78a0)  = 20
>     close(3)                                = 0
>     write(2, "Could not open FTDI device (using"..., 61Could not open
>     FTDI device (using libftdi): device not found
>     ) = 61
>     write(2, "Unable to access FTDI device with"..., 59Unable to access
>     FTDI device with either libftdi or FTD2XX
>     ) = 59
>     exit_group(1)                           = ?
> 
> 
> It appears to be identifying the correct low level device:
> 
>     % lsusb
>     Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>     Bus 004 Device 002: ID 0403:6010 Future Technology Devices
>     International, Ltd FT2232C Dual USB-UART/FIFO IC
>     Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>     Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>     Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>     Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>     Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>     Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>     Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> 
> 
> But presumably what is coming back from one or other of the
> ioctl(USBDEVFS_CONTROL) is not satisfying libftdi.
> 
> Before I dig any further, does anyone have any suggestions?
> What versions of the libraries are known to work with current xc3sprog code?
> Are there any debug switches I can turn on that might clarify what is
> going on?
> 
> Many thanks,
> 
> Daniel Kirkham

Connect your FTDI device while monitoring syslog (or check dmesg after
connecting your FTDI device device) and verify that the USB device IDs
reported by the kernel match the vid & pid IDs that xc3sprog is using to
open the device (defined in cablelist.txt).
Cheers,
--  Matt

Re: [Xc3sprog-users] Trouble opening FT2232-based "cable" with xc3sprog

[Daniel K. <dk...@ki...>]

Uwe,

My problem is solved - I accidentally mailed directly back to Tim rather than to the list.

The problem was that although I had the correct VID and PID, the product descriptions in cablelist.txt didn't match the product description in my FT2232H module, so ftdi_usb_open_desc was rejecting the otherwise valid device. When I tried the ikda and bbv2 "cables" it worked, since in those cases the product description is ignored (in libftdi at least).

So once the device was being correctly identified and opened, it detected my JTAG chain, and I successfully programmed my XC9572XL CPLD, so thanks very much for the code!

To be helpful to others, you might want to put the following line into cablelist.txt:

dlp2232h      ftdi    1500000 0x0403:0x6010:DLP-2232H:1:0x00:0x10:0x00:0x0     

which is an almost direct copy of the bbv2 entry.

I chose to use the first channel on the ft2232h as part of my design. I'm not sure how to get at the second channel, perhaps that is buried in those extra parameters.

Regards,

Daniel
--
On 14/05/2012, at 8:38 PM, Uwe Bonnes wrote:

>>>>>> "Daniel" == Daniel Kirkham <dk...@ki...> writes:
> 
>    Daniel> Hello, I'm trying to get xc3sprog working to program an XC9572XL
>    Daniel> using an FT2232H-based module. I've managed to get it to
>    Daniel> compile, but it fails to open the device:
> 
>    Daniel> % ./xc3sprog -c ftdi XC3SPROG (c) 2004-2011 xc3sprog project
>    Daniel> $Rev: 655 $ OS: Linux Free software: If you contribute nothing,
>    Daniel> expect nothing!  Feedback on success/failure/enhancement
>    Daniel> requests:
> 	
>    Daniel> http://sourceforge.net/mail/?group_id=170565 Check Sourceforge
>    Daniel> for updates:
> 	
>    Daniel> http://sourceforge.net/projects/xc3sprog/develop
> 
>    Daniel> Could not open FTDI device (using libftdi): device not found
>    Daniel> Unable to access FTDI device with either libftdi or FTD2XX
> 
>    Daniel> The FT2232 works ok in UART mode, and starts up ftdi_sio and
>    Daniel> usbserial automatically, and other programs are opening the
>    Daniel> device ok (eg. my eeprom reprogramming code).
> 
>    Daniel> I have been building a variety of libusb and libftdi libraries
>    Daniel> (to program the FT2232H's EEPROM) so my linux setup now has a
>    Daniel> mix of libusb0.1, libusb1.0, libftdi1 and libftdi2, which may be
>    Daniel> complicating matters.
> 
>    Daniel> % ldd ./xc3sprog linux-gate.so.1 => (0xb76ef000) libftdi.so.1 =>
>    Daniel> /usr/lib/libftdi.so.1 (0xb76db000) libusb-0.1.so.4 =>
>    Daniel> /lib/libusb-0.1.so.4 (0xb76d3000) libstdc++.so.6 =>
>    Daniel> /usr/lib/libstdc++.so.6 (0xb75dd000) libm.so.6 =>
>    Daniel> /lib/i686/cmov/libm.so.6 (0xb75b7000) libgcc_s.so.1 =>
>    Daniel> /lib/libgcc_s.so.1 (0xb7599000) libc.so.6 =>
>    Daniel> /lib/i686/cmov/libc.so.6 (0xb7453000) /lib/ld-linux.so.2
>    Daniel> (0xb76f0000)
> 
>    Daniel> Here are some ltrace and strace outputs from near the end of the
>    Daniel> execution:
> 
>    Daniel> ltrace: ...  ftdi_new(0xbf8e0786, 0x9d32c36, 47, 0xb7791a16,
>    Daniel> 0xb74fe866) = 0x9d348e8 ftdi_set_interface(0x9d348e8, 0, 47,
>    Daniel> 0xb7791a16, 0xb74fe866) = 0 ftdi_usb_open_desc(0x9d348e8, 1027,
>    Daniel> 24592, 0xbf8e0786, 0) = -3 ftdi_get_error_string(0x9d348e8,
>    Daniel> 1027, 24592, 0xbf8e0786, 0) = 0xb777925b fprintf(0xb762e560,
>    Daniel> "Could not open FTDI device (usin"...Could not open FTDI device
>    Daniel> (using libftdi): device not found ) = 61 ftdi_free(0x9d348e8,
>    Daniel> 0x807ee00, 0xb777925b, 0xbf8e0786, 0) = 4641 fwrite("Unable to
>    Daniel> access FTDI device wit"..., 1, 59, 0xb762e560Unable to access
>    Daniel> FTDI device with either libftdi or FTD2XX ) = 59 exit(1
>    Daniel> <unfinished ...> +++ exited (status 1) +++
> 
>    Daniel> The high level code seems to be looking for the correct device
>    Daniel> (0403:6010)...
> 
>    Daniel> strace: ...  open("/dev/bus/usb/002/001", O_RDWR) = 3 ioctl(3,
>    Daniel> USBDEVFS_IOCTL, 0xbfdc79d4) = 3 close(3) = 0
>    Daniel> open("/dev/bus/usb/001",
>    Daniel> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>    Daniel> getdents(3, /* 3 entries */, 32768) = 48
>    Daniel> open("/dev/bus/usb/001/001", O_RDWR) = 4 ioctl(4,
>    Daniel> USBDEVFS_CONNECTINFO, 0xbfdc79d8) = 0 read(4,
>    Daniel> "\22\1\20\1\t\0\0@k\35\1\0\6\2\3\2\1\1"..., 18) = 18 read(4,
>    Daniel> "\t\2\31\0\1\1\0\340"..., 8) = 8 read(4,
>    Daniel> "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377"..., 17) = 17 close(4) =
>    Daniel> 0 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0
>    Daniel> open("/dev/bus/usb/001/001", O_RDWR) = 3 ioctl(3,
>    Daniel> USBDEVFS_IOCTL, 0xbfdc79d4) = 3 close(3) = 0
>    Daniel> open("/dev/bus/usb/004/002", O_RDWR) = 3 ioctl(3,
>    Daniel> USBDEVFS_CONTROL, 0xbfdc78a0) = 4 ioctl(3, USBDEVFS_CONTROL,
>    Daniel> 0xbfdc78a0) = 20 close(3) = 0 write(2, "Could not open FTDI
>    Daniel> device (using"..., 61Could not open FTDI device (using libftdi):
>    Daniel> device not found ) = 61 write(2, "Unable to access FTDI device
>    Daniel> with"..., 59Unable to access FTDI device with either libftdi or
>    Daniel> FTD2XX ) = 59 exit_group(1) = ?
> 
>    Daniel> It appears to be identifying the correct low level device:
> 
>    Daniel> % lsusb Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0
>    Daniel> root hub Bus 004 Device 002: ID 0403:6010 Future Technology
>    Daniel> Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Bus 004
>    Daniel> Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007
>    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006
>    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005
>    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003
>    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002
>    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001
>    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> 
>    Daniel> But presumably what is coming back from one or other of the
>    Daniel> ioctl(USBDEVFS_CONTROL) is not satisfying libftdi.
> 
>    Daniel> Before I dig any further, does anyone have any suggestions?
>    Daniel> What versions of the libraries are known to work with current
>    Daniel> xc3sprog code?  Are there any debug switches I can turn on that
>    Daniel> might clarify what is going on?
> 
> -v will make xc3sprog more verbose
> But probably this will not give more clues for tat case.
> 
> Do you have appropriate permissions on the device? Does VID:PID match.
> The error
> ftdi_usb_open_desc(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)        = -3
> ftdi_get_error_string(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)     = 0xb777925b
> 
> The eoror is "usb device not found" as found in libftdi:
> /**
>    Opens the index-th device with a given, vendor id, product id,
>    description and serial.
> 
>    \param ftdi pointer to ftdi_context
>    \param vendor Vendor ID
>    \param product Product ID
>    \param description Description to search for. Use NULL if not needed.
>    \param serial Serial to search for. Use NULL if not needed.
>    \param index Number of matching device to open if there are more than one, starts with 0.
> 
>    \retval  0: all fine
>    \retval -1: usb_find_busses() failed
>    \retval -2: usb_find_devices() failed
>    \retval -3: usb device not found
>    \retval -4: unable to open device
>    \retval -5: unable to claim device
>    \retval -6: reset failed
>    \retval -7: set baudrate failed
>    \retval -8: get product description failed
>    \retval -9: get serial number failed
>    \retval -10: unable to close device
>    \retval -11: ftdi context invalid
> */
> int ftdi_usb_open_desc_index(struct ftdi_context *ftdi, int vendor, int product,
> 
> Hope this helps
> 
> Bye
> -- 
> Uwe Bonnes                bo...@el...
> 
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Trouble opening FT2232-based "cable" with xc3sprog

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

>>>>> "Daniel" == Daniel Kirkham <dk...@ki...> writes:

    Daniel> Hello, I'm trying to get xc3sprog working to program an XC9572XL
    Daniel> using an FT2232H-based module. I've managed to get it to
    Daniel> compile, but it fails to open the device:

    Daniel> % ./xc3sprog -c ftdi XC3SPROG (c) 2004-2011 xc3sprog project
    Daniel> $Rev: 655 $ OS: Linux Free software: If you contribute nothing,
    Daniel> expect nothing!  Feedback on success/failure/enhancement
    Daniel> requests:
	
    Daniel> http://sourceforge.net/mail/?group_id=170565 Check Sourceforge
    Daniel> for updates:
	
    Daniel> http://sourceforge.net/projects/xc3sprog/develop

    Daniel> Could not open FTDI device (using libftdi): device not found
    Daniel> Unable to access FTDI device with either libftdi or FTD2XX

    Daniel> The FT2232 works ok in UART mode, and starts up ftdi_sio and
    Daniel> usbserial automatically, and other programs are opening the
    Daniel> device ok (eg. my eeprom reprogramming code).

    Daniel> I have been building a variety of libusb and libftdi libraries
    Daniel> (to program the FT2232H's EEPROM) so my linux setup now has a
    Daniel> mix of libusb0.1, libusb1.0, libftdi1 and libftdi2, which may be
    Daniel> complicating matters.

    Daniel> % ldd ./xc3sprog linux-gate.so.1 => (0xb76ef000) libftdi.so.1 =>
    Daniel> /usr/lib/libftdi.so.1 (0xb76db000) libusb-0.1.so.4 =>
    Daniel> /lib/libusb-0.1.so.4 (0xb76d3000) libstdc++.so.6 =>
    Daniel> /usr/lib/libstdc++.so.6 (0xb75dd000) libm.so.6 =>
    Daniel> /lib/i686/cmov/libm.so.6 (0xb75b7000) libgcc_s.so.1 =>
    Daniel> /lib/libgcc_s.so.1 (0xb7599000) libc.so.6 =>
    Daniel> /lib/i686/cmov/libc.so.6 (0xb7453000) /lib/ld-linux.so.2
    Daniel> (0xb76f0000)

    Daniel> Here are some ltrace and strace outputs from near the end of the
    Daniel> execution:

    Daniel> ltrace: ...  ftdi_new(0xbf8e0786, 0x9d32c36, 47, 0xb7791a16,
    Daniel> 0xb74fe866) = 0x9d348e8 ftdi_set_interface(0x9d348e8, 0, 47,
    Daniel> 0xb7791a16, 0xb74fe866) = 0 ftdi_usb_open_desc(0x9d348e8, 1027,
    Daniel> 24592, 0xbf8e0786, 0) = -3 ftdi_get_error_string(0x9d348e8,
    Daniel> 1027, 24592, 0xbf8e0786, 0) = 0xb777925b fprintf(0xb762e560,
    Daniel> "Could not open FTDI device (usin"...Could not open FTDI device
    Daniel> (using libftdi): device not found ) = 61 ftdi_free(0x9d348e8,
    Daniel> 0x807ee00, 0xb777925b, 0xbf8e0786, 0) = 4641 fwrite("Unable to
    Daniel> access FTDI device wit"..., 1, 59, 0xb762e560Unable to access
    Daniel> FTDI device with either libftdi or FTD2XX ) = 59 exit(1
    Daniel> <unfinished ...> +++ exited (status 1) +++

    Daniel> The high level code seems to be looking for the correct device
    Daniel> (0403:6010)...

    Daniel> strace: ...  open("/dev/bus/usb/002/001", O_RDWR) = 3 ioctl(3,
    Daniel> USBDEVFS_IOCTL, 0xbfdc79d4) = 3 close(3) = 0
    Daniel> open("/dev/bus/usb/001",
    Daniel> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
    Daniel> getdents(3, /* 3 entries */, 32768) = 48
    Daniel> open("/dev/bus/usb/001/001", O_RDWR) = 4 ioctl(4,
    Daniel> USBDEVFS_CONNECTINFO, 0xbfdc79d8) = 0 read(4,
    Daniel> "\22\1\20\1\t\0\0@k\35\1\0\6\2\3\2\1\1"..., 18) = 18 read(4,
    Daniel> "\t\2\31\0\1\1\0\340"..., 8) = 8 read(4,
    Daniel> "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377"..., 17) = 17 close(4) =
    Daniel> 0 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0
    Daniel> open("/dev/bus/usb/001/001", O_RDWR) = 3 ioctl(3,
    Daniel> USBDEVFS_IOCTL, 0xbfdc79d4) = 3 close(3) = 0
    Daniel> open("/dev/bus/usb/004/002", O_RDWR) = 3 ioctl(3,
    Daniel> USBDEVFS_CONTROL, 0xbfdc78a0) = 4 ioctl(3, USBDEVFS_CONTROL,
    Daniel> 0xbfdc78a0) = 20 close(3) = 0 write(2, "Could not open FTDI
    Daniel> device (using"..., 61Could not open FTDI device (using libftdi):
    Daniel> device not found ) = 61 write(2, "Unable to access FTDI device
    Daniel> with"..., 59Unable to access FTDI device with either libftdi or
    Daniel> FTD2XX ) = 59 exit_group(1) = ?

    Daniel> It appears to be identifying the correct low level device:

    Daniel> % lsusb Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0
    Daniel> root hub Bus 004 Device 002: ID 0403:6010 Future Technology
    Daniel> Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Bus 004
    Daniel> Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007
    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006
    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005
    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003
    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002
    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001
    Daniel> Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

    Daniel> But presumably what is coming back from one or other of the
    Daniel> ioctl(USBDEVFS_CONTROL) is not satisfying libftdi.

    Daniel> Before I dig any further, does anyone have any suggestions?
    Daniel> What versions of the libraries are known to work with current
    Daniel> xc3sprog code?  Are there any debug switches I can turn on that
    Daniel> might clarify what is going on?

-v will make xc3sprog more verbose
But probably this will not give more clues for tat case.

Do you have appropriate permissions on the device? Does VID:PID match.
The error
ftdi_usb_open_desc(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)        = -3
ftdi_get_error_string(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)     = 0xb777925b

The eoror is "usb device not found" as found in libftdi:
/**
    Opens the index-th device with a given, vendor id, product id,
    description and serial.

    \param ftdi pointer to ftdi_context
    \param vendor Vendor ID
    \param product Product ID
    \param description Description to search for. Use NULL if not needed.
    \param serial Serial to search for. Use NULL if not needed.
    \param index Number of matching device to open if there are more than one, starts with 0.

    \retval  0: all fine
    \retval -1: usb_find_busses() failed
    \retval -2: usb_find_devices() failed
    \retval -3: usb device not found
    \retval -4: unable to open device
    \retval -5: unable to claim device
    \retval -6: reset failed
    \retval -7: set baudrate failed
    \retval -8: get product description failed
    \retval -9: get serial number failed
    \retval -10: unable to close device
    \retval -11: ftdi context invalid
*/
int ftdi_usb_open_desc_index(struct ftdi_context *ftdi, int vendor, int product,

Hope this helps

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

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

Re: [Xc3sprog-users] Trouble opening FT2232-based "cable" with xc3sprog

[Tim E. <ti...@op...>]

Hello Daniel,

> I'm trying to get xc3sprog working to program an XC9572XL using an
> FT2232H-based module. I've managed to get it to compile, but it fails to
> open the device:
>
>     % ./xc3sprog -c ftdi
>     XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 655 $ OS: Linux
>     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
>
>     Could not open FTDI device (using libftdi): device not found
>     Unable to access FTDI device with either libftdi or FTD2XX
>
>
> The FT2232 works ok in UART mode, and starts up ftdi_sio and usbserial
> automatically, and other programs are opening the device ok (eg. my eeprom
> reprogramming code).


You didn't specifically say so, but I assume that you removed the ftdi_sio
module before running xc3sprog?  Because that's one obvious way to prevent
it from working.  The low-level calls will fail if the serial device driver
has control of the device.

If that is not the issue, then let me know;  I have some other suggestions
concerning the description string in the cablelist.txt file.  I have not
tried accessing the default FT2232 (with its original internal description
string) using the "-c ftdi", but if the above comments aren't the solution
to your problem, I can check how this works on one of my boards.

						---Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: ti...@op...    |
| Open Circuit Design, Inc.      | web:   http://opencircuitdesign.com |
| 22815 Timber Creek Lane        | phone: (301) 528-5030               |
| Clarksburg, MD 20871-4001      | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+

[Xc3sprog-users] Trouble opening FT2232-based "cable" with xc3sprog

[Daniel K. <dk...@ki...>]

Hello,

I'm trying to get xc3sprog working to program an XC9572XL using an FT2232H-based module. I've managed to get it to compile, but it fails to open the device:

% ./xc3sprog -c ftdi
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 655 $ OS: Linux
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

Could not open FTDI device (using libftdi): device not found
Unable to access FTDI device with either libftdi or FTD2XX

The FT2232 works ok in UART mode, and starts up ftdi_sio and usbserial automatically, and other programs are opening the device ok (eg. my eeprom reprogramming code).

I have been building a variety of libusb and libftdi libraries (to program the FT2232H's EEPROM) so my linux setup now has a mix of libusb0.1, libusb1.0, libftdi1 and libftdi2, which may be complicating matters.

% ldd ./xc3sprog 
	linux-gate.so.1 =>  (0xb76ef000)
	libftdi.so.1 => /usr/lib/libftdi.so.1 (0xb76db000)
	libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb76d3000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75dd000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb75b7000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7599000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7453000)
	/lib/ld-linux.so.2 (0xb76f0000)

Here are some ltrace and strace outputs from near the end of the execution:

ltrace:
...
ftdi_new(0xbf8e0786, 0x9d32c36, 47, 0xb7791a16, 0xb74fe866)                                           = 0x9d348e8
ftdi_set_interface(0x9d348e8, 0, 47, 0xb7791a16, 0xb74fe866)                                          = 0
ftdi_usb_open_desc(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)                                             = -3
ftdi_get_error_string(0x9d348e8, 1027, 24592, 0xbf8e0786, 0)                                          = 0xb777925b
fprintf(0xb762e560, "Could not open FTDI device (usin"...Could not open FTDI device (using libftdi): device not found
)                                            = 61
ftdi_free(0x9d348e8, 0x807ee00, 0xb777925b, 0xbf8e0786, 0)                                            = 4641
fwrite("Unable to access FTDI device wit"..., 1, 59, 0xb762e560Unable to access FTDI device with either libftdi or FTD2XX
)                                      = 59
exit(1 <unfinished ...>
+++ exited (status 1) +++

The high level code seems to be looking for the correct device (0403:6010)...

strace:
...
open("/dev/bus/usb/002/001", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdc79d4)    = 3
close(3)                                = 0
open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 3 entries */, 32768)     = 48
open("/dev/bus/usb/001/001", O_RDWR)    = 4
ioctl(4, USBDEVFS_CONNECTINFO, 0xbfdc79d8) = 0
read(4, "\22\1\20\1\t\0\0@k\35\1\0\6\2\3\2\1\1"..., 18) = 18
read(4, "\t\2\31\0\1\1\0\340"..., 8)    = 8
read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377"..., 17) = 17
close(4)                                = 0
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
open("/dev/bus/usb/001/001", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL, 0xbfdc79d4)    = 3
close(3)                                = 0
open("/dev/bus/usb/004/002", O_RDWR)    = 3
ioctl(3, USBDEVFS_CONTROL, 0xbfdc78a0)  = 4
ioctl(3, USBDEVFS_CONTROL, 0xbfdc78a0)  = 20
close(3)                                = 0
write(2, "Could not open FTDI device (using"..., 61Could not open FTDI device (using libftdi): device not found
) = 61
write(2, "Unable to access FTDI device with"..., 59Unable to access FTDI device with either libftdi or FTD2XX
) = 59
exit_group(1)                           = ?

It appears to be identifying the correct low level device:

% lsusb
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

But presumably what is coming back from one or other of the ioctl(USBDEVFS_CONTROL) is not satisfying libftdi.

Before I dig any further, does anyone have any suggestions?
What versions of the libraries are known to work with current xc3sprog code?
Are there any debug switches I can turn on that might clarify what is going on?

Many thanks,

Daniel Kirkham

Re: [Xc3sprog-users] Spartan 6 and UM232H

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

>>>>> "JB" == JB  <jbw...@gm...> writes:

    JB> Hello, It is still working, and the entire system was unplugged for
    JB> the whole night. It might be that there was some problem with the
    JB> cables or I may have used another USB port, and I have unknowingly
    JB> corrected the problem while trying to get it working. Thanks for the
    JB> help!

If the problems pop up again, please let me know.

    JB> By the way, you could add the UM232H entry to the official cable
    JB> list, as it is working with those settings.

I did enter it as 
ft232h        ftdi    1500000 0x0403:0x6014:

UM232H is too specific i.m.h.o. 

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

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

Re: [Xc3sprog-users] Spartan 6 and UM232H

[JB <jbw...@gm...>]

Hello,

It is still working, and the entire system was unplugged for the whole
night. It might be that there was some problem with the cables or I
may have used another USB port, and I have unknowingly corrected the
problem while trying to get it working. Thanks for the help!

By the way, you could add the UM232H entry to the official cable list,
as it is working with those settings.

Bálint

On Sun, Apr 29, 2012 at 8:54 PM, Uwe Bonnes
<bo...@el...> wrote:
>>>>>> "JB" == JB  <jbw...@gm...> writes:
>
>    JB> Hello, I tried it under Linux, and it worked perfectly! The uncanny
>    JB> thing is, I switched back to Windows to write this letter, and tried
>    JB> it once more under Windows, and it works! I have no idea what fixed
>    JB> it.
> Okay,
>
> so there is some missing initalization in the FTD2XX driver. Argh. It will
> work in Windows until you unplug the device or power down, if I guess
> right.
>
> If you are still not fed up, could you try to install libusb for windows to
> see if the initialisation right with libftdi/windows?
>
> Thanks
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Spartan 6 and UM232H

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

>>>>> "JB" == JB  <jbw...@gm...> writes:

    JB> Hello, I tried it under Linux, and it worked perfectly! The uncanny
    JB> thing is, I switched back to Windows to write this letter, and tried
    JB> it once more under Windows, and it works! I have no idea what fixed
    JB> it.
Okay,

so there is some missing initalization in the FTD2XX driver. Argh. It will
work in Windows until you unplug the device or power down, if I guess
right. 

If you are still not fed up, could you try to install libusb for windows to
see if the initialisation right with libftdi/windows?

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

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

Re: [Xc3sprog-users] Spartan 6 and UM232H

[JB <jbw...@gm...>]

Hello,

I tried it under Linux, and it worked perfectly! The uncanny thing is,
I switched back to Windows to write this letter, and tried it once
more under Windows, and it works! I have no idea what fixed it.

Bálint

On Sun, Apr 29, 2012 at 5:02 PM, JB <jbw...@gm...> wrote:
> On Sun, Apr 29, 2012 at 4:40 PM, Uwe Bonnes
> <bo...@el...> wrote:
>> Hello JB,
>>
>> plase CC to  xc3sprog-users so others can follow in the archive
>
> Sorry, will do.
>
>>>>>>> "JB" == JB  <jbw...@gm...> writes:
>>
>>    JB> == Could not open FTDI device (using libftdi): device not found ==
>>    JB> FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure == Using
>>    JB> FTD2XX, == IDCODE mismatch pos 0 Read 0xffffffff vs 0x24001093 ==
>>    JB> Running IR_TEST 10000 times == IR len = 6 == 0x binary 111111
>>    JB> ..........  == JTAG loc.: 0 IDCODE: 0x24001093 Desc: XC6SLX9 Rev: C
>>    JB> IR length: 6
>>
>> The output may indicate problems with the chain. But you are running FTD2XX
>> on Windows, while I run with FTDI on Linux, so this
>> may also be some programming fault.
>>
>> Try to run the test longer, e.g.by xc3sproc -c um232 -T0.
>>
>> Try again programming with the -v option, perhaps more verbosity will give a hint.
>>
>> At the moment I have no other idea.
>
> == Cable um232h type ftdi VID 0x0403 PID 0x6014 dbus data 00 enable 0b
> cbus data 00 data 00
> == FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure
> == Using FTD2XX, Using JTAG frequency 1500000 from undivided clock
> == Using built-in device list
> == JTAG chainpos: 0 Device IDCODE = 0x24001093     Desc: XC6SLX9
> == IDCODE mismatch pos 0 Read 0xffffffff vs 0x24001093
> == Running IR_TEST 2147483647  times
> == IR len = 6
> == 0x binary 111111
> ...............................................................
> ................................................................................
> ................................................................................
> ..
> == JTAG loc.: 0    IDCODE: 0x24001093      Desc:         XC6SLX9
> Rev: C  IR length: 6
> == USB transactions: Write 225950 read 225947 retries 0
>
> Running the test longer didn't turn up anything. I will try it under Linux.
>
> Bálint

Re: [Xc3sprog-users] Spartan 6 and UM232H

[JB <jbw...@gm...>]

On Sun, Apr 29, 2012 at 4:40 PM, Uwe Bonnes
<bo...@el...> wrote:
> Hello JB,
>
> plase CC to  xc3sprog-users so others can follow in the archive

Sorry, will do.

>>>>>> "JB" == JB  <jbw...@gm...> writes:
>
>    JB> == Could not open FTDI device (using libftdi): device not found ==
>    JB> FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure == Using
>    JB> FTD2XX, == IDCODE mismatch pos 0 Read 0xffffffff vs 0x24001093 ==
>    JB> Running IR_TEST 10000 times == IR len = 6 == 0x binary 111111
>    JB> ..........  == JTAG loc.: 0 IDCODE: 0x24001093 Desc: XC6SLX9 Rev: C
>    JB> IR length: 6
>
> The output may indicate problems with the chain. But you are running FTD2XX
> on Windows, while I run with FTDI on Linux, so this
> may also be some programming fault.
>
> Try to run the test longer, e.g.by xc3sproc -c um232 -T0.
>
> Try again programming with the -v option, perhaps more verbosity will give a hint.
>
> At the moment I have no other idea.

== Cable um232h type ftdi VID 0x0403 PID 0x6014 dbus data 00 enable 0b
cbus data 00 data 00
== FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure
== Using FTD2XX, Using JTAG frequency 1500000 from undivided clock
== Using built-in device list
== JTAG chainpos: 0 Device IDCODE = 0x24001093     Desc: XC6SLX9
== IDCODE mismatch pos 0 Read 0xffffffff vs 0x24001093
== Running IR_TEST 2147483647  times
== IR len = 6
== 0x binary 111111
...............................................................
................................................................................
................................................................................
..
== JTAG loc.: 0    IDCODE: 0x24001093      Desc:         XC6SLX9
Rev: C  IR length: 6
== USB transactions: Write 225950 read 225947 retries 0

Running the test longer didn't turn up anything. I will try it under Linux.

Bálint

Re: [Xc3sprog-users] Spartan 6 and UM232H

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

Hello JB,

plase CC to  xc3sprog-users so others can follow in the archive

>>>>> "JB" == JB  <jbw...@gm...> writes:

    JB> == Could not open FTDI device (using libftdi): device not found ==
    JB> FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure == Using
    JB> FTD2XX, == IDCODE mismatch pos 0 Read 0xffffffff vs 0x24001093 ==
    JB> Running IR_TEST 10000 times == IR len = 6 == 0x binary 111111
    JB> ..........  == JTAG loc.: 0 IDCODE: 0x24001093 Desc: XC6SLX9 Rev: C
    JB> IR length: 6

The output may indicate problems with the chain. But you are running FTD2XX
on Windows, while I run with FTDI on Linux, so this
may also be some programming fault.

Try to run the test longer, e.g.by xc3sproc -c um232 -T0.

Try again programming with the -v option, perhaps more verbosity will give a hint.

At the moment I have no other idea.

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

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

Re: [Xc3sprog-users] Spartan 6 and UM232H

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

Hello JB,


>>>>> "JB" == JB  <jbw...@gm...> writes:

    JB> Hello, I am trying to program an XC6SLX9 with an UM232H (an FT232H
    JB> based dev board). I have connected the JTAG signals, and I am now
    JB> trying to use xc3sprog to download my bitstream to the
    JB> board. xc3sprog does recognize the FPGA (it is the only component in
    JB> the JTAG chain), but it does not seem to be able to program it. At
    JB> first, the operation is successful, but the FPGA does nothing (it is
    JB> in "limbo", it does absolutely nothing, it is not running the old
    JB> program, nor is it running the new one). If I try it again, all
    JB> subsequent attempts fail (until the board power is turned off and
    JB> then on), with the following error message:

    JB> Device failed to configure, INSTRUCTION_CAPTURE is 0x3f

    JB> This might be a bug, but it is more likely I am missing something.
    JB> This is the command line I have been using:

    JB> xc3sprog -c um232h -L control.bit -v

    JB> I have also added a new entry for the UM232H board to the
    JB> cablelist.txt file - (I don't really know what the other FTDI
    JB> options mean: INTERFACE:DBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN):

If the JTAG needs some bits e.g. to enable the interface, you have to set
these bits. If you code this enabling by hand, you would set thses lines
with the MPSSE 0x80-0x83 commands "Set/Read DATA Bits High/Low with the
values DBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN. The values supplied are extended
with the values needed to enable the Pins used for JTAG and sent to the FTDI device

    JB> um232h ftdi 1500000 0x0403:0x6014::0:

So your coding would mean that no special line is needed. If you wired the
UM232H module direct, this would be fine.

    JB> Here is the full verbose transcript:

JB,

please test the integrity of your setup with running
xc3sprog -c um232h -T0

If there are problems, revisit your wiring. 

Let the list know about the outcome!

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

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

[Xc3sprog-users] Spartan 6 and UM232H

[JB <jbw...@gm...>]

Hello,

I am trying to program an XC6SLX9 with an UM232H (an FT232H based dev
board). I have connected the JTAG signals, and I am now trying to use
xc3sprog to download my bitstream to the board. xc3sprog does
recognize the FPGA (it is the only component in the JTAG chain), but
it does not seem to be able to program it. At first, the operation is
successful, but the FPGA does nothing (it is in "limbo", it does
absolutely nothing, it is not running the old program, nor is it
running the new one). If I try it again, all subsequent attempts fail
(until the board power is turned off and then on), with the following
error message:

Device failed to configure, INSTRUCTION_CAPTURE is 0x3f

This might be a bug, but it is more likely I am missing something.
This is the command line I have been using:

xc3sprog -c um232h -L control.bit -v

I have also added a new entry for the UM232H board to the
cablelist.txt file - (I don't really know what the other FTDI options
mean: INTERFACE:DBUS_DATA:DBUS_EN:CBUS_DAT:ACBUS_EN):

um232h        ftdi    1500000 0x0403:0x6014::0:

Here is the full verbose transcript:

>>  xc3sprog -c um232h -L control.bit -v
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 655 $ OS: Windows
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

Cable um232h type ftdi VID 0x0403 PID 0x6014 dbus data 00 enable 0b cbus data 00
 data 00
FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure
Using FTD2XX, Using JTAG frequency 1500000 from undivided clock
Using built-in device list
JTAG chainpos: 0 Device IDCODE = 0x24001093     Desc: XC6SLX9
Created from NCD file: control.ncd;UserID=0xFFFFFFFF
Target device: 6slx9tqg144
Created: 2012/04/28 16:48:57
Bitstream length: 2724832 bits
done. Programming time 1820.1 ms
USB transactions: Write 174 read 5 retries 0

>>  xc3sprog -c um232h -L control.bit -v
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 655 $ OS: Windows
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

Cable um232h type ftdi VID 0x0403 PID 0x6014 dbus data 00 enable 0b cbus data 00
 data 00
FTD2XX/WIN: Can't set VID/PID to 0403:6014. Expect failure
Using FTD2XX, Using JTAG frequency 1500000 from undivided clock
Using built-in device list
JTAG chainpos: 0 Device IDCODE = 0x24001093     Desc: XC6SLX9
Created from NCD file: control.ncd;UserID=0xFFFFFFFF
Target device: 6slx9tqg144
Created: 2012/04/28 16:48:57
Bitstream length: 2724832 bits
done. Programming time 1821.1 ms
Device failed to configure, INSTRUCTION_CAPTURE is 0x3f
USB transactions: Write 274 read 55 retries 0

Any help would be appreciated,
Bálint

[Xc3sprog-users] Add Virtex6 support - patch 1/1

[Matthew L. <li...@bu...>]

Hi all,

Attached is a patch that adds support of programming Xilinx Virtex6
devices to xc3sprog. Patch is based on r658 (current version I synced with
this morning). Changes were minimal (as expected) however with the device
I had (550T), I had to skip waiting for the reconfiguration step in
ProgAlgXC3S::array_program(), ie skip doing:

jtag->shiftIR(JPROGRAM, NULL);
do
   jtag->shiftIR(CFG_IN, buf);
while (! (buf[0] & 0x10)); /* wait until configuration cleared */

..otherwise I waited forever. Not sure why this is.

I think there's also a bug in function ProgAlgXC3S::flow_enable() too. A
byte array of data[1] is shifted through shiftIR() 5 times but as data[]
is only 1 byte in size and shiftIR() indexes into the pointer using i++,
this will read uninitialised memory. I've switched it to use data[5] and
memset it to zero before doing the shiftIR operation.

As a side note, I'm also able to reliably program the device using my FTDI
4232 running at full speed (30MHz). This is faster than the Xilinx tools.
Nice :-)

Cheers,
--  Matt

Re: [Xc3sprog-users] XCFP does not yet support bitfile subranges

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

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


    >> Are you going to add XCFP-specific command-line option for the CCB
    >> register?

    Joris> Probably not soon. I currently don't have an XCFP board
    Joris> available, and I don't want to mess around with code that I can't
    Joris> test properly.

As I neither have a board with XCFP, I neither want to touch the code and
and my spare time goes into other projects at this time.

How do programming times of xc3sprog on XCFP compare to Xilinx impact
programming times? How do xc3sprog XCFP programming times compare with dlc10
cable to a ftdix232h based cable?

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

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

Re: [Xc3sprog-users] XCFP does not yet support bitfile subranges

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

Hi Mirko,

On 2012-02-20, Mirko Ciecinski wrote:
> Programming with your patched xc3sprog consumes 10 times longer than
> with patched V0.5-version (327 sec <-> 31 sec).

Yes, programming time is a problem with this code. Especially
DLC10-type cables seem to be very slow when alternating between short
writes and status polling.

I'm following the programming flow from the Xilinx BSDL file. Your
special code uses a different trick to handle the timing of the
programming process. It may work only with certain types of cables or
certain bitrate configurations of the cable.

> As you mentioned,
> maybe CCB=0xffff is not the fastest setting.

I did not mention that. The setting of CCB has nothing to do with
programming speed.

> But I cannot figure out
> the differences in progalgxcfxxp.cpp. I find only CCB[2] ..., see
> below:

This is where XC3SPROG sets the CCB register. Currently the contents is
fixed at 0xffff, as you can see:

    data[0] = 0xff;
    data[1] = 0xff;
    jtag->shiftIR(XSC_DATA_CCB);
    jtag->shiftDR(data, 0, 16);

> Are you going to add XCFP-specific command-line option for the CCB
> register?

Probably not soon. I currently don't have an XCFP board available, and
I don't want to mess around with code that I can't test properly.

Joris.

Re: [Xc3sprog-users] Vertex 6

[Dmitry T. <di...@gm...>]

Matthew,

On Mon, Feb 20, 2012 at 9:17 AM, Matthew Lear <li...@bu...> wrote:
> This section is the same for both devices -> so same as Virtex5. I
> personally have no Xilinx eval board to test easily with an ftdi part, but
> our custom hw is due back in a week or so, so not too long to wait. I hope
> to have some good news for you then :-)

If it helps at all, I've been using xc3sprog to program Virtex 5 FPGAs
without any problems.

-- 
Dmitry Teytelman <di...@gm...>

Re: [Xc3sprog-users] Vertex 6

[Matthew L. <li...@bu...>]

>>>>>> "Matthew" == Matthew Lear <li...@bu...> writes:
>
>     >> You first shot should be to add the FAMILY_XCV6xxxx definitions in
>     >> progalgxc3s.h and then add FAMILY_XCV6xxxx to the Xc5V clause in
>     >> ProgAlgXC3S::ProgAlgXC3S. Perhaps than everything works already...
>
>     Matthew> Ok, thanks. I just wanted to check one thing. Looking at the
>     Matthew> current Virtex 5 settings in ProgAlgXC3S::ProgAlgXC3S,
>     Matthew> array_transfer_len is specified to be 32 but the Xilinx
> Virtex
>     Matthew> 5 FPGA Configuration User Guide (UG191) states to load 64
> bits
>     Matthew> of bitstream data followed by RTI (1 x TCK cycle) after
>     Matthew> ISC_PROGRAM. Does this mean that the value for
>     Matthew> array_transfer_len is incorrect or have I missed something?
> Compare the XC5V and XC6V 1532 algorithm encoded in files like
>
> Xilinx/13.4/ISE_DS/ISE/virtex5/data/xc5vlx20t_1532.bsd
>
> and
>
> Xilinx/13.4/ISE_DS/ISE/virtex6/data/xc6vcx75t_1532.bsd
>
> found where ISE is installed. I think there is no big difference, if there
> is a difference at all. If there is no difference, the XC5V settings
> should
> work or if they don't work with XC6V there is something fishy and that
> should be fixed. If there are differences,thy should be encoded...
>
> Hope this helps.

Thanks Uwe. Yes.

"       (ISC_PROGRAM    32:?    wait TCK 1 )," &

This section is the same for both devices -> so same as Virtex5. I
personally have no Xilinx eval board to test easily with an ftdi part, but
our custom hw is due back in a week or so, so not too long to wait. I hope
to have some good news for you then :-)
Cheers,
--  Matt

Re: [Xc3sprog-users] Vertex 6

[Matthew L. <li...@bu...>]

> You first shot should be to add the FAMILY_XCV6xxxx definitions in
> progalgxc3s.h and then add FAMILY_XCV6xxxx to the Xc5V clause in
> ProgAlgXC3S::ProgAlgXC3S. Perhaps than everything works already...

Ok, thanks. I just wanted to check one thing. Looking at the current
Virtex 5 settings in ProgAlgXC3S::ProgAlgXC3S, array_transfer_len is
specified to be 32 but the Xilinx Virtex 5 FPGA Configuration User Guide
(UG191) states to load 64 bits of bitstream data followed by RTI (1 x TCK
cycle) after ISC_PROGRAM. Does this mean that the value for
array_transfer_len is incorrect or have I missed something?
Cheers,
--  Matt

[Xc3sprog-users] Antwort: Re: XCFP does not yet support bitfile subranges

[Mirko C. <mir...@ki...>]

Hello Joris,

>>I realized, that we are using a special patched xc3sprog version
>>0.5 with a new file progalgxcfxxp.cpp, based on
>>progalgxcf.cpp.  
>Are you saying that this special version of
>XC3SPROG programs your board successfully, while the main
>version of XC3SPROG does not?  
Yes, that's right. It is the progalgxcfxxp.cpp I sent to you separatly.
The onliest problem: Sometimes it can't erase PROM successfully, especially if the first try was interupted due to power lost.
That's the reason because I started dealing with current xc3sprog.

>Just out of curiosity, where did
>you get the special version?
An internal programmer wrote it, based on your progalgxcf.cpp V0.5 (appr. 2004,2005 ?)
But this internal programmer is not available anymore.

>>If you won't include mode pin
>>set-up in xc3sprog, could you give me a 
>>hint, how to add it.
>It is not so much a matter of pin set-up.  XCFP devices can be
>used in a number of modes, including either serial or parallel,
>and either master or slave. The PROM contains a CCB register
>which determines the mode for which it is configured.  
>This register is documented in Xilinx ug161:  
>CCB<0>    1 = external clock, 0 = internal PROM clock  
>CCB<2:1>  11 = serial output, 00= parallel output  
>CCB<3>    1 = PROM slave (FPGA master), 0 =PROM master  
>CCB<5:4>  11 = 40 MHz clock, 01 = 20 MHz clock
Thanks, I got it now from the document you mentioned above.

>Currently, XC3SPROG programs XCFP devices in FPGA Master Serial
>mode (CCB=0xffff). XCFS devices don't have a CCB register; they
>always operate in FPGA Master Serial mode.   It would be a good
>idea to add support for different modes. This could be done by
>adding an XCFP-specific command-line option which then gets
>translated into the proper value for the CCB register.
At this point I'm out of my skills. I'm only a linux guy, trying to get it work.

What I see:
Programming with your patched xc3sprog consumes 10 times longer than with patched V0.5-version (327 sec <-> 31 sec).
As you mentioned, maybe CCB=0xffff is not the fastest setting. But I cannot figure out the differences in progalgxcfxxp.cpp.
I find only CCB[2] ..., see below:

#include "progalgxcfxxp.h"

// Info for interpreting the commands that are shifted in IR:
// Size of Instruction Register is 16 bit (IR Length=16).
// The data buffer is shifted with LSB bit first.
// That is why shifting 16 bit:      0b0000000011101010 = 0x00e8
// is equivalent to shifting 22 bit: 0b0000000011101010111111 = 0x3a3f

const byte ProgAlgXCFxxP::XSC_DATA_DONE[2]    ={0x09,0x00};
const byte ProgAlgXCFxxP::XSC_DATA_CCB[2]     ={0x0c,0x00};
const byte ProgAlgXCFxxP::XSC_DATA_SUCR[2]    ={0x0e,0x00};
const byte ProgAlgXCFxxP::XSC_BLANK_CHECK[2]  ={0x0d,0x00};
const byte ProgAlgXCFxxP::ISPEN[2]            ={0xe8,0x00};
const byte ProgAlgXCFxxP::ISC_PROGRAM[2]      ={0xea,0x00};   // 1110'1010
const byte ProgAlgXCFxxP::ISC_ADDRESS_SHIFT[2]={0xeb,0x00};   // 1110'1011
const byte ProgAlgXCFxxP::ISC_ERASE[2]        ={0xec,0x00};
const byte ProgAlgXCFxxP::ISC_DATA_SHIFT[2]   ={0xed,0x00};   // 1110'1101
const byte ProgAlgXCFxxP::CONFIG[2]           ={0xee,0x00};
const byte ProgAlgXCFxxP::NORMRST[2]          ={0xf0,0x00};   // conld
const byte ProgAlgXCFxxP::XSC_DATA_BTC[2]     ={0xf2,0x00};
const byte ProgAlgXCFxxP::XSC_CLEAR_STATUS[2] ={0xf4,0x00};
const byte ProgAlgXCFxxP::IDCODE[2]           ={0xfe,0x00};
const byte ProgAlgXCFxxP::XSC_UNLOCK[2]       ={0x55,0xaa};
const byte ProgAlgXCFxxP::BYPASS[2]           ={0xff,0xff};

But I do not understand the correct order of bit settings (comment lines above) ... shifting 16 bit?
Again, I can not fix it.

Are you going to add XCFP-specific command-line option for the CCB register?

Thanks for answer!
Best regards,
Mirko

Re: [Xc3sprog-users] Vertex 6

[Matthew L. <li...@bu...>]

>>>>>> "Matthew" == Matthew Lear <li...@bu...> writes:
>
>     Matthew> Hi everybody.  I'm new to the forum... Has anybody had any
>     Matthew> success in using xc3sprog with Xilinx Vertex 6 devices? I
>     Matthew> notice that Vertex 5 is on the list of supported hw...
> Cheers,
>     Matthew> -- Matt
>
>
> I neither have Virtex6 nor Vertex 5 to test. The algos are very similar,
> so
> with some look at the code and some enhancements to the code you should
> succeed.

Thanks Uwe. I've just started to look at this task seriously now. From
what I can tell, the algorithms are specified in the ProgAlgXC3S class and
the methods defined in progalgxc3s.cpp therein, eg flow_program_xxx(),
flow_enable() etc. Is this correct?

Once I have the Virtex 6 working I'd like to submit a patch back to the
list for integration into xc3sprog. Not sure when that will be exactly but
that's my plan anyway.. :-)

Cheers,
--  Matt

Re: [Xc3sprog-users] ioxpc.cpp buffer size and burst read details

[Raul F. <rfa...@gm...>]

The cable I was using:

Model DLC9G
Serial UHG - 38262

On Mon, Feb 13, 2012 at 10:15 AM, Uwe Bonnes <
bo...@el...> wrote:

> >>>>> "Joris" == Joris van Rantwijk <jor...@jo...> writes:
>
> ...
>    Joris> Indeed, our projects should keep in touch in order to benefit
>    Joris> from each others improvements. It may even be useful to have a
>    Joris> common library which handles the various types of programming
>    Joris> cables and offers basic JTAG operations as an API. If UrJTAG,
>    Joris> XC3SPROG, adv_jtag_bridge and others bundle forces, we could
>    Joris> share the burden of cable driver development.
>
> I considered. But the API seem so orthogonal that I refrained.
>
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

Re: [Xc3sprog-users] ioxpc.cpp buffer size and burst read details

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

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

...
    Joris> Indeed, our projects should keep in touch in order to benefit
    Joris> from each others improvements. It may even be useful to have a
    Joris> common library which handles the various types of programming
    Joris> cables and offers basic JTAG operations as an API. If UrJTAG,
    Joris> XC3SPROG, adv_jtag_bridge and others bundle forces, we could
    Joris> share the burden of cable driver development.

I considered. But the API seem so orthogonal that I refrained.

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

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