Menu
▾
▴
xc3sprog-users
|
From: Mirko C. <mir...@ki...> - 2012-02-07 09:01:38
|
<font face="Vorgabe Sans Serif,Verdana,Arial,Helvetica,Sans-Serif" size="2">Hi Joris,<br><br>thanks for your quick reply. I applied your patch.<br>Now xcs3prog starts programming, but after 2 min it aborts.<br>======================================<br><pre style="font-family: Vorgabe feste Breite,Courier New,Courier,Feste Breite;">./xc3sprog.patch1 -v -j -c ftdi
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
<a class="moz-txt-link-freetext" href="http://sourceforge.net/mail/?group_id=170565">http://sourceforge.net/mail/?group_id=170565</a>
Check Sourceforge for updates:
<a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/xc3sprog/develop">http://sourceforge.net/projects/xc3sprog/develop</a>
Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093 Desc: XCF16P
JTAG loc.: 0 IDCODE: 0xe5058093 Desc: XCF16P Rev: O IR length: 16
JTAG loc.: 1 IDCODE: 0x01450093 Desc: XC3S5000 Rev: A IR length: 6
USB transactions: Write 6 read 4 retries 8
# ./xc3sprog.patch1 -v -c ftdi OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
<a class="moz-txt-link-freetext" href="http://sourceforge.net/mail/?group_id=170565">http://sourceforge.net/mail/?group_id=170565</a>
Check Sourceforge for updates:
<a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/xc3sprog/develop">http://sourceforge.net/projects/xc3sprog/develop</a>
Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093 Desc: XCF16P
Erasing...................................done
Erase time 17.799 s
Programming frames 0x1000000 to 0x100001f
<span style="font-weight: bold;">Programming failed! Aborting</span>
Programming time 163.790 s
USB transactions: Write 65753 read 32904 retries 65815</pre><br>======================================<br>FYI: It's a customer device I received in non-operating condition --> FPGA could not load program from EEPROM.<br>Maybe EEPROM is defect?<br>Is there anything I can do to provide more information to you?<br><br>Here are information about BIT-file<br>./bitinfo < OCA_0x0000006F_HwBoardRev01.bit<br><br>Bit file created on 2010/10/27 at 10:48:04.<br>Created from file top.ncd for Xilinx part 3s5000fg900.<br>Bitstream length is 1658992 bytes.<br><br><br>Thanks!<br>Mirko<br><span><br></span><br><div></div></font>
|
|
From: Joris v. R. <jor...@jo...> - 2012-02-07 10:36:40
Attachments:
fix_xcfp_blen.diff
|
On 2012-02-07, Mirko Ciecinski wrote: > thanks for your quick reply. I applied your patch. > Now xcs3prog starts programming, but after 2 min it aborts. > Programming frames 0x1000000 to 0x100001f > Programming failed! Aborting Ok, one problem solved and now you hit the next issue. There is a mistake in the XCFP code which only affects devices larger than XCF08P. Apparently you are the first one to program a big XCFP device since then. Could you try the attached patch? And thanks for reporting these issues. We really depend on good bug reports to keep xc3sprog working accross a wide range of hardware. Regards, Joris. |
|
From: Mirko C. <mir...@ki...> - 2012-02-07 12:27:12
|
Hi Joris,
>There is a mistake in the XCFP
>code which only affects devices larger than XCF08P. Apparently
>you are the first one to program a big XCFP device since then.
>Could you try the attached patch?
I applied your 2nd patch and now it seems to work.:-)
=====================================
# ./xc3sprog.patch2 -v -c ftdi OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ 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
Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 0 Device IDCODE = 0xe5058093 Desc: XCF16P
Erasing...............................done
Erase time 15.765 s
Programming frames 0x1fffe0 to 0x1fffff
Programming BTC , CCB , SUCR , DONE finished
Programming time 327.427 s
Verifying frames 0x195060 to 0x19506f
Verifying BTC = 0xffffffe4
Verifying CCB = 0xffff
Verifying SUCR = 0xfffc
Verifying DONE = 0xcc
Success!
Verify time 258.978 s
USB transactions: Write 235070 read 117611 retries 235257
=====================================
But after rebooting ePC, FPGA does not load its program from EEPROM. :-(
Programming FPGA directly with command line parameter "-p 1" is working fine, but of course after shutdown my system does not work again.
=====================================
./xc3sprog.patch2 -v -c ftdi -p 1 OCA_0x0000006F_HwBoardRev01.bit
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 646 $ 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
Cable ftdi type ftdi VID 0x0403 PID 6010 dbus data 00 enable 0b cbus data 00 data 00
Using Libftdi, Using JTAG frequency 1200000
Using devlist.txt
JTAG chainpos: 1 Device IDCODE = 0x01450093Desc: XC3S5000
Created from NCD file: top.ncd
Target device: 3s5000fg900
Created: 2010/10/27 10:48:04
Bitstream length: 13271936 bits
done. Programming time 11745.1 ms
USB transactions: Write 821 read 8 retries 1508/10/2007-Alviso-6A79GTZ0C-16Phoenix - AwardBIOS v6.00PG ...
=====================================
Anyway, if you are sure, that XC3SPROG message "Success!" is correct, I think there is another problem (hardware). And you can commit your patches to xc3sprog-project.
Tomorrow I'll have a meeting with a hardware specialist, trying to use XILINX USB adapter and iMPACT to flash it again.
I'll keep you informed about the results.
Thanks again for your valuable support!
Best regards,
Mirko
|
|
From: Joris v. R. <jor...@jo...> - 2012-02-07 13:01:20
|
On 2012-02-07, Mirko Ciecinski wrote: > I applied your 2nd patch and now it seems to work.:-) Great, thanks for testing. > But after rebooting ePC, FPGA does not load its program from > EEPROM. :-( Programming FPGA directly with command line parameter "-p > 1" is working fine, but of course after shutdown my system does not > work again. xc3sprog sets up the PROM in slave serial mode. This means that the FPGA must boot in master serial mode to make it work. I.e. one data wire from PROM to FPGA, FPGA generates configuration clock for PROM. If your board is wired differently, for example with multiple data wires between PROM and FPGA, the PROM would need to be set up differently. xc3sprog currently can not do this (although it would not be very hard to implement it). You can deduce the boot method of your board by looking at the level of the mode pins M0,M1,M2 of the FPGA. > Anyway, if you are sure, that XC3SPROG message "Success!" is correct, > I think there is another problem (hardware). And you can commit your > patches to xc3sprog-project. xc3sprog performs (most of) the status checks that are prescribed by the XCFP programming algorithm, and Success means that all of these passed. You could try reading back the contents of the PROM with xc3sprog -v -c ftdi dump.bit:r The read-back BIT file should be equivalent to the original, although the header may be different and 0xFF padding may be truncated from the end. But you should be able to directly configure the FPGA with the read-back BIT file, for example. Joris. |
|
From: Mirko C. <mir...@ki...> - 2012-02-12 15:21:40
|
Hi Joris, Sorry for late response (I was out of town). >You could try reading >back the contents of the PROM with xc3sprog -v -c ftdi >dump.bit:r The read-back BIT file should be equivalent to the >original, although the header may be different and 0xFF padding >may be truncated from the end. >From section "e" the contents are 100% identically. It works perfect. >for example with multiple data wires >between PROM and FPGA, the PROM would need to be set up >differently. xc3sprog currently can not do this (although it >would not be very hard to implement it). You can deduce the boot >method of your board by looking at the level of the mode pins >M0,M1,M2 of the FPGA. As far as I know today, that's exactly what we are doing. But I don't have more information about levels of mode pins M0, M1 and M2. I realized, that we are using a special patched xc3sprog version 0.5 with a new file progalgxcfxxp.cpp, based on progalgxcf.cpp. I'll send it to you separatly. I think, if it is also useful for other users to set-up mode pin, it would be a great idea to include this option in xc3sprog. (especially for non-experienced user like me) If you won't include mode pin set-up in xc3sprog, could you give me a hint, how to add it. Thanks in advance! Mirko |
|
From: Joris v. R. <jor...@jo...> - 2012-02-12 18:01:00
|
Hello Mirko, On 2012-02-12, Mirko Ciecinski wrote: > 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? Just out of curiosity, where did you get the special version? > 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 CBC<5:4> 11 = 40 MHz clock, 01 = 20 MHz clock 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. Regards, Joris. |
|
From: Mirko C. <mir...@ki...> - 2012-02-20 10:57:53
|
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
|
|
From: Joris v. R. <jor...@jo...> - 2012-02-20 21:06:49
|
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.
|
|
From: Uwe B. <bo...@el...> - 2012-02-21 10:06:19
|
>>>>> "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 ----------
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X