HS1 also not working, all cable have FTDI stock VID/PID, and they do use proper devlist.txt setting, i verified with cablelist.txt where I changed the clock for the cable selected, XC3SPROG did honor the freq setting from the proper line from cablelist.txt
So it really seems the GPIO_Lx settings are not used properly, output drivers are not enabled, same with HS1 and HS2
We are using pretty recent sources from SF, we had to recompile them as we needed winbond support what was not available from SF source code tree.
B:\sw\code\xc3sprog\BSCAN_X7_SPI_ISF\exe_a7>xc3sprog -L -v -c jtaghs2 -Itop.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ 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
Using devlist.txt
Using cablelist.txt
libFTDI support not compiled in!
Using FTD2XX, Using JTAG frequency 6.000 MHz from undivided clock
No JTAG Chain found
USB transactions: Write 5 read 2 retries 0
As soon as we use HS1 onboard then XC3SPROG will work...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have very long history of JTAG and USB troubleshooting ;)
We have sure 1 cable and 1 FTDI device connected to the PC.
We are licensed to use Digilent USB JTAG in our products, so we have integrated into many different end user products. If we use XC3SPROG on any of those devices, then it all works. As soon as we test XC3SPROG with original HS1/HS2 then it fails.
The hardware differences:
HS1/HS2 DISABLE buffer by default, if D7 (HS1) or D7..D5(HS2) are not 1, then output drivers are not enabled. XC3SPROG does not enable, them hence it fails to connect, that what it looks.
our on-board circuitry has no such buffers, and is ENABLED by default hence it works.
We can not test under linux, neither we are need it working under linux :(
Sorry but the world is not yet linux-only...!
We have struggled a lot to get XC3SPROG to compile, under windows we did finally give up, so we use linux in VM box for the linux-cross build.
We may be can test on linux some day later, but that is too late for us.
And yes, as you said the SETTINGS for HS1/HS2 are really correct, but they are not activated as it seems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Antti> I have very long history of JTAG and USB troubleshooting ;) We
Antti> have sure 1 cable and 1 FTDI device connected to the PC.
Antti> We are licensed to use Digilent USB JTAG in our products, so we
Antti> have integrated into many different end user products. If we use
Antti> XC3SPROG on any of those devices, then it all works. As soon as
Antti> we test XC3SPROG with original HS1/HS2 then it fails.
Antti> The hardware differences: HS1/HS2 DISABLE buffer by default, if
Antti> D7 (HS1) or D7..D5(HS2) are not 1, then output drivers are not
Antti> enabled. XC3SPROG does not enable, them hence it fails to
Antti> connect, that what it looks.
Please measure teh state of the enable pins!
The cablelist.txt line
jtaghs2 ftdi 6000000 0x0403:0x6014:Digilent USB Device:0:0xe8:0xeb:0x00:0x60
data ena data ena
dbus cbus
is supposed to enable D7..D5(HS2) and set the to 1. So probaly there is more
enable magic involved for the original adapters. The FTD2XX call to
enable/set dbus is tested, as the in-house ftdijtag needs D4 set to NULL.
However I wonder what D3 on HS2 is supposed to do. D3 is active set to
0. The same for CBUS D5..4 set to NULL.
libusb on win is really PITA, i need to deinstall FTDI to test, right ?
that is real real pita.. I need this PC to be working all the time...
ah, I have some trash PCs also. But our XC3SPROG is compiled with no libftdi support.
HS1:
ADBUS_7 must be SET 1: this is ENABLE for all 4 JTAG signals
ADBUS_4 MUST be FLOATING: it is shorted to TCK ! Do not ask me why ;)
HS2:
ADBUS_7 must be SET 1: this is ENABLE for ?
ADBUS_6,5 must SET 1 also more enables
ADBUS_4 MUST be FLOATING: same as HS1 assumed, part tested also
I had LEDs on JTAG pins, they did never get any light no matter XC3SPROG was executed, maybe it failed so quickly that it was not visible
Something WEIRD, I will troubleshoot here.
1) if IMPACT is open it does poll, so TCK pulses are visible, even if nobody is talking to FTDI, closed impact killed jtag server, still xc3sprog also dead.
but it seems it is not even trying to talk to the FTDI chip.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Antti> Hi Using USB Analyzer I see:
Antti> when XC3SPROG tries HS2 cable it sends 80 00 0B later 80 FF 00
Antti> this is last OUT transaction in LOG
Antti> if my software connects I see in usb log
Antti> 80 E0 EB this is also what I write as init
Antti> So: XS3SPROG is talking to the right usb device, but just is not
Antti> sending the init data as needed :(
Antti> I can send the screenshots of usb analyzer, but the most I
Antti> described
Run xc3sprog with the environment variable FTDI_DEBUG set to some
<name>. This will create a log file <name>. Connecting our ftdijtag adapter
and changing PID from 0x6014 to 0x6010 and removing the name string from the
jtaghs2 definition line in cablelist.txt with no device connected on linux
x86-64 and gives:
mpsse_add_cmd len 9: 80 e8 eb 86 00 00 82 00 60
mpsse_send 9
mpsse_add_cmd len 4: 8a 86 04 00
mpsse_send 4
mpsse_add_cmd len 3: 4b 04 9f
mpsse_send 3
mpsse_add_cmd len 3: 4b 03 82
mpsse_add_cmd len 3: 3d 03 00
mpsse_add_cmd len 4: 00 00 00 00
mpsse_add_cmd len 1: 87
mpsse_send 11
readusb len 4: ff ff ff ff
mpsse_add_cmd len 16: 80 ff 00 82 ff 00 84 3d 04 00 aa 55 00 ff aa 85
mpsse_add_cmd len 1: 87
mpsse_send 17
readusb len 5: aa 55 00 ff aa
for the command env "FTDI_DEBUG=test ./xc3sprog -c jtaghs2".
The first line is the MPSSE command to set DBUS and CBUS and the values look
okay as they are as defined in cablelist.txt.
Can you send the output when run on your system and compare to the USB
analyser?
Antti> Alias Type Frequency OptString
Antti> jtaghs2 ftdi 6000000 0x0403:0x6010::0:0xeb:0xeb:0x00:0x00
Where does this line come from? It is different from the line distributed
with cablelist.txt
jtaghs2 ftdi 6000000 0x0403:0x6014:Digilent USB Device:0:0xe8:0xeb:0x00:0x60
VID is different (0x6014 vs 0x6010) and the device string "Digilent USB
Device" missing.
Antti> SET FTDI_DEBUG=test xc3sprog -L -v -c jtaghs2 -Itop.bit
Antti> mpsse_add_cmd len 9: 80 00 0b 86 03 00 82 00 00 mpsse_send 9
Antti> mpsse_add_cmd len 4: 8a 86 04 00 mpsse_send 4 mpsse_add_cmd len
Antti> 3: 4b 04 9f mpsse_send 3 mpsse_add_cmd len 3: 4b 03 82
Antti> mpsse_add_cmd len 3: 3d 03 00 mpsse_add_cmd len 4: 00 00 00 00
Antti> mpsse_add_cmd len 1: 87 mpsse_send 11 readusb len 4: ff ff ff ff
Antti> mpsse_add_cmd len 16: 80 ff 00 82 ff 00 84 3d 04 00 aa 55 00 ff
Antti> aa 85 mpsse_add_cmd len 1: 87 mpsse_send 17 readusb len 5: aa 55
Antti> 00 ff aa
Antti> as you can see wrong DBUS init bits are sent :(
This output indicates, that xc3sprog picks up a wrong configuration
line. And your jtaghs2 indicates that you manipulated cablelist.txt. Are you
sure you don't have another jtaghs2 definition line dangling around?
Dump the actual cablelist.txt with the -D option and look it the definition
gets picked up right there.
Otherwise , run xc3sprog in the debugger and look what goes wrong.
Bye
Antti> ------------------------------------------------------------------------------
Antti> [bugs:#16] Digilent HS2 not working
Antti> Status: open Created: Thu Jan 02, 2014 03:43 PM UTC by Antti
Antti> Lukats Last Updated: Thu Jan 02, 2014 07:40 PM UTC Owner: Uwe
Antti> Bonnes
Antti> Digilent HS1/HS2 are listed as supported, but XC3SPROG is not
Antti> working with original HS2. Windows, D2XX drivers.
Antti> ------------------------------------------------------------------------------
Antti> Sent from sourceforge.net because you indicated interest in
Antti> https:// sourceforge.net/p/xc3sprog/bugs/16/
Antti> To unsubscribe from further messages, please visit
Antti> https://sourceforge.net/ auth/subscriptions/
1) using built in not modified cablelist
2) using -D generated not modified
3) using modified cablelist
no matter what combination, the init is always 80 00 0B
if I change frequency in cablelist then the modified frequency is used, so I assume the cablelist ist read and the line is used. But the init values from the same (and only line!) in cablelist are not honored.
setup example:
jtagHS2 connected to PC, win7-64 bit, D2XX driver
cablelist has 1 line
jtaghs2 ftdi 3000000 0x0403:0x6014:Digilent USB Device:0:0xe8:0xeb:0x00:0x60
XC3SPROG it us using 3mhz TCK
but sends 80 00 0B as init!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Antti> 1) using built in not modified cablelist 2) using -D generated
Antti> not modified 3) using modified cablelist
Antti> no matter what combination, the init is always 80 00 0B if I
Antti> change frequency in cablelist then the modified frequency is
Antti> used, so I assume the cablelist ist read and the line is
Antti> used. But the init values from the same (and only line!) in
Antti> cablelist are not honored.
Antti> setup example: jtagHS2 connected to PC, win7-64 bit, D2XX driver
Antti> cablelist has 1 line jtaghs2 ftdi 3000000 0x0403:0x6014:Digilent
Antti> USB Device:0:0xe8:0xeb:0x00:0x60
Antti> XC3SPROG it us using 3mhz TCK but sends 80 00 0B as init!
Very strange. From what I understand so long, you use a self compiled
executable. What compiler? Any changes to the makefile? Any compilation
warnings that indicate some problem?
Uwe, we tried VERY hard to get it to compile under windows. It never worked.
So we cross-compile in linux virtual machine for Windows. We need this as we need the support for winbond W25Q256 :(
I do not think it is possible to debug on windows cross compiled code?
Besides I do not have access to the PC where it was recompiled until 7th January.
It would enorm if there would be windows EXE file with W25Q256 support in SF download area, then I could use non modified EXE to test.
UPS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
It seems the SF version of the EXE behaves differently :(
But really weird, why.. we did not modify the sources..
Last edit: Antti Lukats 2014-01-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And yes, as you said the SETTINGS for HS1/HS2 are really correct, but they
are not activated as it seems.
That is possible of course, only I don't understand why it happens. The bits are set with an MPSSE call, and the code is very similar for libftdi vs FTD2XX.
I will try to install D2XX drivers and test my HS1 cable under Linux. If the problem is D2XX-specific I should have a chance to debug it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Antti> Uwe please close the ticket. Very embarrassing. It is our
Antti> recompiled code that works otherwise but does not read the init
Antti> from the cablelist
Are there any warnings during compile? Otherwise this is very embarrassing.
Antti> We will need to fix this ourself as we need the 2 fixes for
Antti> winbond 1) the 32mbyte support
What do you mean with that? Does the device need to be added or do you need
4-Byte address mode? Or does xc3sprog implemented algos choke on such big
images?
W25Q256 we implemented a quick fix by adding ID code, we do not even care about the 32mbyte, even if 16mbyte is write-able would be ok, Ah I think i tested it wraps around over 16mbyte writes
1 it would suffice for us if device is added even if 16mbyte only accessible
2 we have Kintex board that can only boot in Quad Enable mode, so this bit must be set, but XC3SPROG seems not to work when QE bit is set in nonvolatile SR2 register.
our soft guru is back in office on 7th January, so we will look all over again and see where we are and what patches we may have to submit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It used to work fine under Linux with libftdi.
I don't know why it would not work with D2XX.
Can you provide xc3sprog version number, exact error message and USB vendor ID, product ID of your cable?
HS1 also not working, all cable have FTDI stock VID/PID, and they do use proper devlist.txt setting, i verified with cablelist.txt where I changed the clock for the cable selected, XC3SPROG did honor the freq setting from the proper line from cablelist.txt
So it really seems the GPIO_Lx settings are not used properly, output drivers are not enabled, same with HS1 and HS2
We are using pretty recent sources from SF, we had to recompile them as we needed winbond support what was not available from SF source code tree.
B:\sw\code\xc3sprog\BSCAN_X7_SPI_ISF\exe_a7>xc3sprog -L -v -c jtaghs2 -Itop.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 747 $ 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
Using devlist.txt
Using cablelist.txt
libFTDI support not compiled in!
Using FTD2XX, Using JTAG frequency 6.000 MHz from undivided clock
No JTAG Chain found
USB transactions: Write 5 read 2 retries 0
As soon as we use HS1 onboard then XC3SPROG will work...
The settings work for my HS1/HS2 cables, and the settings are identical to what closed-source Adept software is doing.
So either there are multiple different devices floating around under the same product names HS1/HS2, or the problem is something else.
Is it easy for you to test under Linux with libftdi?
That would help to figure out if this is a software problem or hardware problem.
What do you mean by "HS1 onboard". Are you talking about a different HS1 cable that does work?
I have very long history of JTAG and USB troubleshooting ;)
We have sure 1 cable and 1 FTDI device connected to the PC.
We are licensed to use Digilent USB JTAG in our products, so we have integrated into many different end user products. If we use XC3SPROG on any of those devices, then it all works. As soon as we test XC3SPROG with original HS1/HS2 then it fails.
The hardware differences:
HS1/HS2 DISABLE buffer by default, if D7 (HS1) or D7..D5(HS2) are not 1, then output drivers are not enabled. XC3SPROG does not enable, them hence it fails to connect, that what it looks.
our on-board circuitry has no such buffers, and is ENABLED by default hence it works.
We can not test under linux, neither we are need it working under linux :(
Sorry but the world is not yet linux-only...!
We have struggled a lot to get XC3SPROG to compile, under windows we did finally give up, so we use linux in VM box for the linux-cross build.
We may be can test on linux some day later, but that is too late for us.
And yes, as you said the SETTINGS for HS1/HS2 are really correct, but they are not activated as it seems.
Please measure teh state of the enable pins!
The cablelist.txt line
jtaghs2 ftdi 6000000 0x0403:0x6014:Digilent USB Device:0:0xe8:0xeb:0x00:0x60
data ena data ena
dbus cbus
is supposed to enable D7..D5(HS2) and set the to 1. So probaly there is more
enable magic involved for the original adapters. The FTD2XX call to
enable/set dbus is tested, as the in-house ftdijtag needs D4 set to NULL.
However I wonder what D3 on HS2 is supposed to do. D3 is active set to
0. The same for CBUS D5..4 set to NULL.
Can you try with libusb on windows?
Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
libusb on win is really PITA, i need to deinstall FTDI to test, right ?
that is real real pita.. I need this PC to be working all the time...
ah, I have some trash PCs also. But our XC3SPROG is compiled with no libftdi support.
HS1:
ADBUS_7 must be SET 1: this is ENABLE for all 4 JTAG signals
ADBUS_4 MUST be FLOATING: it is shorted to TCK ! Do not ask me why ;)
HS2:
ADBUS_7 must be SET 1: this is ENABLE for ?
ADBUS_6,5 must SET 1 also more enables
ADBUS_4 MUST be FLOATING: same as HS1 assumed, part tested also
I had LEDs on JTAG pins, they did never get any light no matter XC3SPROG was executed, maybe it failed so quickly that it was not visible
Something WEIRD, I will troubleshoot here.
1) if IMPACT is open it does poll, so TCK pulses are visible, even if nobody is talking to FTDI, closed impact killed jtag server, still xc3sprog also dead.
but it seems it is not even trying to talk to the FTDI chip.
Hi
Using USB Analyzer I see:
when XC3SPROG tries HS2 cable it sends
80 00 0B
later
80 FF 00 this is last OUT transaction in LOG
if my software connects I see in usb log
80 E0 EB
this is also what I write as init
So: XS3SPROG is talking to the right usb device, but just is not sending the init data as needed :(
I can send the screenshots of usb analyzer, but the most I described
Run xc3sprog with the environment variable FTDI_DEBUG set to some
<name>. This will create a log file <name>. Connecting our ftdijtag adapter
and changing PID from 0x6014 to 0x6010 and removing the name string from the
jtaghs2 definition line in cablelist.txt with no device connected on linux
x86-64 and gives:
mpsse_add_cmd len 9: 80 e8 eb 86 00 00 82 00 60
mpsse_send 9
mpsse_add_cmd len 4: 8a 86 04 00
mpsse_send 4
mpsse_add_cmd len 3: 4b 04 9f
mpsse_send 3
mpsse_add_cmd len 3: 4b 03 82
mpsse_add_cmd len 3: 3d 03 00
mpsse_add_cmd len 4: 00 00 00 00
mpsse_add_cmd len 1: 87
mpsse_send 11
readusb len 4: ff ff ff ff
mpsse_add_cmd len 16: 80 ff 00 82 ff 00 84 3d 04 00 aa 55 00 ff aa 85
mpsse_add_cmd len 1: 87
mpsse_send 17
readusb len 5: aa 55 00 ff aa
for the command env "FTDI_DEBUG=test ./xc3sprog -c jtaghs2".
The first line is the MPSSE command to set DBUS and CBUS and the values look
okay as they are as defined in cablelist.txt.
Can you send the output when run on your system and compare to the USB
analyser?
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
. #Alias Type Frequency OptString
jtaghs2 ftdi 6000000 0x0403:0x6010::0:0xeb:0xeb:0x00:0x00
SET FTDI_DEBUG=test
xc3sprog -L -v -c jtaghs2 -Itop.bit
mpsse_add_cmd len 9: 80 00 0b 86 03 00 82 00 00
mpsse_send 9
mpsse_add_cmd len 4: 8a 86 04 00
mpsse_send 4
mpsse_add_cmd len 3: 4b 04 9f
mpsse_send 3
mpsse_add_cmd len 3: 4b 03 82
mpsse_add_cmd len 3: 3d 03 00
mpsse_add_cmd len 4: 00 00 00 00
mpsse_add_cmd len 1: 87
mpsse_send 11
readusb len 4: ff ff ff ff
mpsse_add_cmd len 16: 80 ff 00 82 ff 00 84 3d 04 00 aa 55 00 ff aa 85
mpsse_add_cmd len 1: 87
mpsse_send 17
readusb len 5: aa 55 00 ff aa
as you can see wrong DBUS init bits are sent :(
I tried both 6010 6014 and Hs1 and Hs2 connected
the init sent is always 80 00 0b
Last edit: Antti Lukats 2014-01-03
Where does this line come from? It is different from the line distributed
with cablelist.txt
jtaghs2 ftdi 6000000 0x0403:0x6014:Digilent USB Device:0:0xe8:0xeb:0x00:0x60
VID is different (0x6014 vs 0x6010) and the device string "Digilent USB
Device" missing.
This output indicates, that xc3sprog picks up a wrong configuration
line. And your jtaghs2 indicates that you manipulated cablelist.txt. Are you
sure you don't have another jtaghs2 definition line dangling around?
Dump the actual cablelist.txt with the -D option and look it the definition
gets picked up right there.
Otherwise , run xc3sprog in the debugger and look what goes wrong.
Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
1) using built in not modified cablelist
2) using -D generated not modified
3) using modified cablelist
no matter what combination, the init is always 80 00 0B
if I change frequency in cablelist then the modified frequency is used, so I assume the cablelist ist read and the line is used. But the init values from the same (and only line!) in cablelist are not honored.
setup example:
jtagHS2 connected to PC, win7-64 bit, D2XX driver
cablelist has 1 line
jtaghs2 ftdi 3000000 0x0403:0x6014:Digilent USB Device:0:0xe8:0xeb:0x00:0x60
XC3SPROG it us using 3mhz TCK
but sends 80 00 0B as init!
Very strange. From what I understand so long, you use a self compiled
executable. What compiler? Any changes to the makefile? Any compilation
warnings that indicate some problem?
Is running with the debugger an option for you?
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe, we tried VERY hard to get it to compile under windows. It never worked.
So we cross-compile in linux virtual machine for Windows. We need this as we need the support for winbond W25Q256 :(
I do not think it is possible to debug on windows cross compiled code?
Besides I do not have access to the PC where it was recompiled until 7th January.
It would enorm if there would be windows EXE file with W25Q256 support in SF download area, then I could use non modified EXE to test.
UPS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
It seems the SF version of the EXE behaves differently :(
But really weird, why.. we did not modify the sources..
Last edit: Antti Lukats 2014-01-03
That is possible of course, only I don't understand why it happens. The bits are set with an MPSSE call, and the code is very similar for libftdi vs FTD2XX.
I will try to install D2XX drivers and test my HS1 cable under Linux. If the problem is D2XX-specific I should have a chance to debug it.
Uwe please close the ticket.
Very embarrassing. It is our recompiled code that works otherwise but does not read the init from the cablelist
We will need to fix this ourself as we need the 2 fixes for winbond
1) the 32mbyte support
2) QE enable support
Antti
Are there any warnings during compile? Otherwise this is very embarrassing.
What do you mean with that? Does the device need to be added or do you need
4-Byte address mode? Or does xc3sprog implemented algos choke on such big
images?
Lets discuss on the normal xc3sprog mailing list.
Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
hm mailing list? Ok i try to find the way there..
W25Q256 we implemented a quick fix by adding ID code, we do not even care about the 32mbyte, even if 16mbyte is write-able would be ok, Ah I think i tested it wraps around over 16mbyte writes
1 it would suffice for us if device is added even if 16mbyte only accessible
2 we have Kintex board that can only boot in Quad Enable mode, so this bit must be set, but XC3SPROG seems not to work when QE bit is set in nonvolatile SR2 register.
our soft guru is back in office on 7th January, so we will look all over again and see where we are and what patches we may have to submit