Menu
▾
▴
xc3sprog-users — Generic user and developer list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(1) |
| 2010 |
Jan
(5) |
Feb
(33) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(25) |
Sep
(8) |
Oct
(2) |
Nov
|
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(22) |
Mar
(1) |
Apr
(8) |
May
(8) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
|
Nov
(9) |
Dec
(5) |
| 2013 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
(5) |
May
(2) |
Jun
(18) |
Jul
|
Aug
(2) |
Sep
(21) |
Oct
|
Nov
|
Dec
(2) |
| 2014 |
Jan
(6) |
Feb
(6) |
Mar
|
Apr
(1) |
May
(11) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(6) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(5) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Uwe B. <bo...@el...> - 2012-12-03 09:58:58
|
>>>>> "Joris" == Joris van Rantwijk <jor...@jo...> writes:
Joris> Hi Uwe, On 2012-11-23, Uwe Bonnes wrote:
Sidney> Hello, I am currently considering buying a Digilent Atlys board
Sidney> (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS),
Sidney> and I am wondering if it is possible to program its Spartan-6
Sidney> using xc3sprog.
>> If you buy the card and test, please let me know the results.
Joris> I just got an Atlys board. I can confirm that xc3sprog programs
Joris> the Spartan-6 FPGA on the Atlys board without any issues if a
Joris> separate JTAG cable is used.
Joris> The Atlys board also has an on-board JTAG-USB programmer based on
Joris> a Cypress FX2, but it uses a proprietary USB protocol and
Joris> therefore does not work with xc3sprog.
Did you try the the xpc cable? Perhaps it Digilent uses that cable?
Joris> Programming the SPI flash chip on the Atlys board needed some
Joris> work. xc3sprog SVN r717 gives the following error message: Found
Joris> Numonyx Device, Device ID 0xba18 M25P: Unexpected RDID upper
Joris> Device ID 0xba
Joris> I added support for N25Q devices in progalgspiflash.cpp to fix
Joris> it. This is now committed in SVN r718 (shout if you disagree).
Thanks
Joris> Of course, a bscan_spi bitfile is needed to access the SPI
Joris> memory. The xc3sprog distribution already contains
Joris> xc6slx45-fg484.bit which appears to work with the Atlys
Joris> board. However, the Atlys FPGA is xc6slx45-csg324. Do you know
Joris> if it is safe to use bscan_spi files for a different package, or
Joris> should I build a separate bitfile for csg324?
Probably it is the same chip in the csg324 and fg484 package. If it works,
it should be safe.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Joris v. R. <jor...@jo...> - 2012-12-02 14:00:10
|
Hi Uwe, On 2012-11-23, Uwe Bonnes wrote: > Sidney> Hello, I am currently considering buying a Digilent Atlys > Sidney> board > Sidney> (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS), > Sidney> and I am wondering if it is possible to program its > Sidney> Spartan-6 using xc3sprog. > If you buy the card and test, please let me know the results. I just got an Atlys board. I can confirm that xc3sprog programs the Spartan-6 FPGA on the Atlys board without any issues if a separate JTAG cable is used. The Atlys board also has an on-board JTAG-USB programmer based on a Cypress FX2, but it uses a proprietary USB protocol and therefore does not work with xc3sprog. Programming the SPI flash chip on the Atlys board needed some work. xc3sprog SVN r717 gives the following error message: Found Numonyx Device, Device ID 0xba18 M25P: Unexpected RDID upper Device ID 0xba I added support for N25Q devices in progalgspiflash.cpp to fix it. This is now committed in SVN r718 (shout if you disagree). Of course, a bscan_spi bitfile is needed to access the SPI memory. The xc3sprog distribution already contains xc6slx45-fg484.bit which appears to work with the Atlys board. However, the Atlys FPGA is xc6slx45-csg324. Do you know if it is safe to use bscan_spi files for a different package, or should I build a separate bitfile for csg324? Kind regards, Joris. |
|
From: Uwe B. <bo...@el...> - 2012-11-23 10:35:07
|
>>>>> "Sidney" == Sidney Cadot <si...@ji...> writes:
Sidney> Hello, I am currently considering buying a Digilent Atlys board
Sidney> (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS),
Sidney> and I am wondering if it is possible to program its Spartan-6
Sidney> using xc3sprog.
Sidney> The Digilent product page suggests that I should use either the
Sidney> Digilent-provided Adept software, or Xilinx' impact software
Sidney> with some kind of Digilent driver. However, I would very much
Sidney> prefer using an open-source programming tool.
Digilent uses a FT2232H, so probably th jtaghs1 cable could work. The
cablelist.txt jtaghs1 however is contributed and I never tested it myself.
If you buy the card and test, please let me know the results.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Sidney C. <si...@ji...> - 2012-11-23 00:01:49
|
Hello, I am currently considering buying a Digilent Atlys board (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS), and I am wondering if it is possible to program its Spartan-6 using xc3sprog. The Digilent product page suggests that I should use either the Digilent-provided Adept software, or Xilinx' impact software with some kind of Digilent driver. However, I would very much prefer using an open-source programming tool. Kind regards, Sidney |
|
From: Uwe B. <bo...@el...> - 2012-11-16 10:03:39
|
>>>>> "valdez" == valdez valdez <val...@gm...> writes:
valdez> Now it works. I learned how to build it under IDE and I set
valdez> environment variables there. Thank you very much Mr Bonnes!
Good to know that you succeeded in compiling. If you find any problem or add
soemthing, please let us know.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: valdez v. <val...@gm...> - 2012-11-15 13:23:47
|
Now it works. I learned how to build it under IDE and I set environment variables there. Thank you very much Mr Bonnes! 2012/11/15 valdez valdez <val...@gm...>: > I'm doing something wrong. I set 'export > FTDI_DEBUG=ftdi_debug_output', but can't see anywhere output file when > I run 'xc3sprog -c ftdi'. How I could use it correctly? > > 2012/11/14 Uwe Bonnes <bo...@el...>: >>>>>>> "Uwe" == Uwe Bonnes <bo...@el...> writes: >> >>>>>>> "valdez" == valdez valdez <val...@gm...> writes: >> valdez> Hi, I wanted to understand how does it work, but it is not easy >> valdez> just looking at the code. I can't run it under some IDE and >> valdez> debug it. But I saw that there is 'fp_dbg' parameter which >> valdez> allows to see more things than -v. Could you provide *.exe file >> valdez> with this 'fp_dbg' set true? >> >> Uwe> fp_dbg is set via a environment variable. E.g. to look at the >> Uwe> libftdi output, set "FTDI_DEBUG" to some name and a run of xc3sprog >> Uwe> will produce a file with that name. >> >> All the environment variable are described in the manpage. >> -- >> Uwe Bonnes bo...@el... >> >> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt >> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
|
From: valdez v. <val...@gm...> - 2012-11-15 10:20:20
|
I'm doing something wrong. I set 'export FTDI_DEBUG=ftdi_debug_output', but can't see anywhere output file when I run 'xc3sprog -c ftdi'. How I could use it correctly? 2012/11/14 Uwe Bonnes <bo...@el...>: >>>>>> "Uwe" == Uwe Bonnes <bo...@el...> writes: > >>>>>> "valdez" == valdez valdez <val...@gm...> writes: > valdez> Hi, I wanted to understand how does it work, but it is not easy > valdez> just looking at the code. I can't run it under some IDE and > valdez> debug it. But I saw that there is 'fp_dbg' parameter which > valdez> allows to see more things than -v. Could you provide *.exe file > valdez> with this 'fp_dbg' set true? > > Uwe> fp_dbg is set via a environment variable. E.g. to look at the > Uwe> libftdi output, set "FTDI_DEBUG" to some name and a run of xc3sprog > Uwe> will produce a file with that name. > > All the environment variable are described in the manpage. > -- > Uwe Bonnes bo...@el... > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
|
From: Uwe B. <bo...@el...> - 2012-11-14 16:39:15
|
>>>>> "Uwe" == Uwe Bonnes <bo...@el...> writes:
>>>>> "valdez" == valdez valdez <val...@gm...> writes:
valdez> Hi, I wanted to understand how does it work, but it is not easy
valdez> just looking at the code. I can't run it under some IDE and
valdez> debug it. But I saw that there is 'fp_dbg' parameter which
valdez> allows to see more things than -v. Could you provide *.exe file
valdez> with this 'fp_dbg' set true?
Uwe> fp_dbg is set via a environment variable. E.g. to look at the
Uwe> libftdi output, set "FTDI_DEBUG" to some name and a run of xc3sprog
Uwe> will produce a file with that name.
All the environment variable are described in the manpage.
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Uwe B. <bo...@el...> - 2012-11-14 16:35:42
|
>>>>> "valdez" == valdez valdez <val...@gm...> writes:
valdez> Hi, I wanted to understand how does it work, but it is not easy
valdez> just looking at the code. I can't run it under some IDE and
valdez> debug it. But I saw that there is 'fp_dbg' parameter which
valdez> allows to see more things than -v. Could you provide *.exe file
valdez> with this 'fp_dbg' set true?
fp_dbg is set via a environment variable. E.g. to look at the libftdi
output, set "FTDI_DEBUG" to some name and a run of xc3sprog will produce a
file with that name.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: valdez v. <val...@gm...> - 2012-11-14 14:05:36
|
Hi, I wanted to understand how does it work, but it is not easy just looking at the code. I can't run it under some IDE and debug it. But I saw that there is 'fp_dbg' parameter which allows to see more things than -v. Could you provide *.exe file with this 'fp_dbg' set true? Kind regards, Valdez |
|
From: Go L. Go <go...@ya...> - 2012-11-06 15:44:15
|
http://www.batardsensible.com/wp-content/plugins/work.php?transportation287.php |
|
From: Uwe B. <bo...@el...> - 2012-09-30 12:36:21
|
Hello, if you have made private changes to devlist.txt for your devices, I am glad to merge these changes if you sedn me a diff with a short explanation. Thanks -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
|
From: Dan E. <eg...@of...> - 2012-09-07 16:02:36
|
http://segger.com/cms/admin/uploads/productDocs/RM08001_JLinkUSBProtocol.pdf EMU_CMD_HW_JTAG3 looks like the low level access we would want? The dongle also supports high level commands for ARM debugging but I'm hopeful those can just be ignored. Anyway if this seems plausible to you, I may take a whack at it some free weekend or other. On Sep 7, 2012 2:01 AM, "Uwe Bonnes" < bo...@el...> wrote: > >>>>> "Dan" == Dan Egnor <eg...@of...> writes: > > Dan> In particular, I'm thinking about porting the jlink driver, which > Dan> is supported by urjtag and openocd. > > Dan> Naively, it looks relatively simple, but I'm not sure if there are > Dan> hidden gotchas to know about before I start. I am familiar with > Dan> libusb and all that jazz so I know what I'm getting into there. > > It depends on the intrinsics the dongle supports. If you can match the > intriscics with the basic capabilities found in iobase.h all is fine. If > the > dongle is "intelligent" and only knows higher level intrinsics, porting > will > be hard. > > E.g. I looked at the versaloon dongle. The dongle is intelligent and after > some starring at the code and wondering how it can be done, I gave up for > now. > > I intend to extend the blackmagicdebug firmware > http://sourceforge.net/projects/blackmagicdebug/ > for the JTAG primitives some times, so I have a dongle usefull for ARM and > other Jtags purpose. But this is part of a much greater USB stack effort I > have in mind: Connect LUFA with Ethernut and extend LUFA for STM32. But > don't holed yout breath... > > Bye > -- > Uwe Bonnes bo...@el... > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > |
|
From: Uwe B. <bo...@el...> - 2012-09-07 09:01:40
|
>>>>> "Dan" == Dan Egnor <eg...@of...> writes:
Dan> In particular, I'm thinking about porting the jlink driver, which
Dan> is supported by urjtag and openocd.
Dan> Naively, it looks relatively simple, but I'm not sure if there are
Dan> hidden gotchas to know about before I start. I am familiar with
Dan> libusb and all that jazz so I know what I'm getting into there.
It depends on the intrinsics the dongle supports. If you can match the
intriscics with the basic capabilities found in iobase.h all is fine. If the
dongle is "intelligent" and only knows higher level intrinsics, porting will
be hard.
E.g. I looked at the versaloon dongle. The dongle is intelligent and after
some starring at the code and wondering how it can be done, I gave up for
now.
I intend to extend the blackmagicdebug firmware
http://sourceforge.net/projects/blackmagicdebug/
for the JTAG primitives some times, so I have a dongle usefull for ARM and
other Jtags purpose. But this is part of a much greater USB stack effort I
have in mind: Connect LUFA with Ethernut and extend LUFA for STM32. But
don't holed yout breath...
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Dan E. <eg...@of...> - 2012-09-06 23:01:18
|
In particular, I'm thinking about porting the jlink driver, which is supported by urjtag and openocd. Naively, it looks relatively simple, but I'm not sure if there are hidden gotchas to know about before I start. I am familiar with libusb and all that jazz so I know what I'm getting into there. -- egnor |
|
From: Dan E. <eg...@of...> - 2012-09-06 18:57:03
|
That patch works for me (once I fix a trivial compiler error). On Mon, Sep 3, 2012 at 5:19 AM, Raul Fajardo <rfa...@gm...> wrote: > Hey, > try out the attached patch. I never used xc3sprog and thus didn't test. > But I think this should work. > Regards, > Raul > > On Mon, Sep 3, 2012 at 12:33 PM, Uwe Bonnes < > bo...@el...> wrote: > >> >>>>> "Raul" == Raul Fajardo <rfa...@gm...> writes: >> >> Raul> Hello Uwe, it is related to two issues I reported back in the >> Raul> beginning of the year. >> Raul> <http://sourceforge.net/mailarchive/message.php?msg_id=28809703 >> > >> >> Raul> One is the size of the buffer, which we had just above. The >> other >> Raul> is: >> >> Raul> While porting the cable's implementation to another system, I >> Raul> noticed that the assumption of bursts of more than 32 bits to be >> Raul> aligned is false as long as the burst is not multiple of 32 (64 >> is >> Raul> ok but 63 has to be realigned). >> >> Raul> I assumed that it happens seldom, possibly because the >> application >> Raul> does not use bursts on non-32-multiple numbers. But there might >> be >> Raul> an exception. Take a look on the port where I commented it: >> Raul> http://sourceforge.net/mailarchive/message.php?msg_id=28809703 >> Raul> <http://sourceforge.net/mailarchive/message.php?msg_id=28809703 >> > >> Raul> Some followups: >> Raul> http://sourceforge.net/mailarchive/message.php?msg_id=28824266 >> >> May I shamelessly aske for a patch for xc3sprog? >> >> I am so out of the DLC9 working it probaly would take much of time to get >> again into it... >> >> Thanks >> >> -- >> Uwe Bonnes bo...@el... >> >> Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt >> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Xc3sprog-users mailing list > Xc3...@li... > https://lists.sourceforge.net/lists/listinfo/xc3sprog-users > > |
|
From: Uwe B. <bo...@el...> - 2012-09-05 14:25:23
|
Hello, I had access to a raspberry pi today. Compiling and running went quite smooth, with some corrections to the code. Make package even compiled a debian package I could install, however the naming of the package with xxx.x86.deb is still wrong. I put the resulting debian package on sourceforge, just to let you know. Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |
|
From: Raul F. <rfa...@gm...> - 2012-09-03 10:24:00
|
Hello Uwe, it is related to two issues I reported back in the beginning of the year. <http://sourceforge.net/mailarchive/message.php?msg_id=28809703> One is the size of the buffer, which we had just above. The other is: While porting the cable's implementation to another system, I noticed that the assumption of bursts of more than 32 bits to be aligned is false as long as the burst is not multiple of 32 (64 is ok but 63 has to be realigned). I assumed that it happens seldom, possibly because the application does not use bursts on non-32-multiple numbers. But there might be an exception. Take a look on the port where I commented it: http://sourceforge.net/mailarchive/message.php?msg_id=28809703 <http://sourceforge.net/mailarchive/message.php?msg_id=28809703> Some followups: http://sourceforge.net/mailarchive/message.php?msg_id=28824266 Best regards, Raul On Mon, Sep 3, 2012 at 10:47 AM, Uwe Bonnes < bo...@el...> wrote: > >>>>> "Raul" == Raul Fajardo <rfa...@gm...> writes: > > Raul> Hi Egnor, For some more speed, you can safely use 1<<11. > > Raul> The explanation of what is going on is somewhat complicated but > it > Raul> works and kind of makes sense from a cpld implementation point of > Raul> view. > > Raul, please give that explanation. It will be archived on the mailing list > or I will add a not in the code. > > Raul> <p>Hi Egnor,</p> <p>For some more speed, you can safely use > Please, no HTML and no full quote on mailing lists. I clutters the > archives... > > Dan, can you test Raul's proposal and report back? > > Bye > -- > Uwe Bonnes bo...@el... > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > |
|
From: Uwe B. <bo...@el...> - 2012-09-03 09:30:43
|
>>>>> "Raul" == Raul Fajardo <rfa...@gm...> writes:
Raul> Hi Egnor, For some more speed, you can safely use 1<<11.
Raul> The explanation of what is going on is somewhat complicated but it
Raul> works and kind of makes sense from a cpld implementation point of
Raul> view.
Raul, please give that explanation. It will be archived on the mailing list
or I will add a not in the code.
Raul> <p>Hi Egnor,</p> <p>For some more speed, you can safely use
Please, no HTML and no full quote on mailing lists. I clutters the
archives...
Dan, can you test Raul's proposal and report back?
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Raul F. <rfa...@gm...> - 2012-09-01 18:25:43
|
Hi Egnor, For some more speed, you can safely use 1<<11. The explanation of what is going on is somewhat complicated but it works and kind of makes sense from a cpld implementation point of view. Regards, Raul Am 01.09.2012 17:38 schrieb "Dan Egnor" <eg...@of...>: > (Re-adding xc3sprog-users, since this is getting interesting...) > > Changing > > #define XPC_A6_CHUNKSIZE (1<<13) > > to > > #define XPC_A6_CHUNKSIZE 4 > > makes my problem go away! > > (It also makes programming somewhat slower not surprisingly.) > > I think this adds a lot of support to your hypothesis. I read through the > threads you linked to and I come away with the notion that nobody seems to > quite know exactly what's going on? Are you pretty confident in your > understanding of the situation? Maybe basically the modifications you made > within opencores (?) should be ported to xs3prog? And I guess urjtag is > also broken but the CHUNKSIZE=4 means they never see the problem? > > Probably I should just use a different JTAG adapter? The XPC is annoying > in other ways too! (Silly "fxload" business to get it working...) > > -- egnor > > On Sat, Sep 1, 2012 at 4:19 AM, Raul Fajardo <rfa...@gm...> wrote: > >> This might be related to an issue with the xpc_usb cable implementation. >> But I have no guarantees for it. >> >> While porting the cable's implementation to another system, I noticed >> that the assumption of bursts of more than 32 bits to be aligned is false >> as long as the burst is not multiple of 32 (64 is ok but 63 has to be >> realigned). >> >> I assumed that it happens seldom, possibly because the application does >> not use bursts on non-32-multiple numbers. But there might be an exception. >> Take a look on the port where I commented it: >> http://sourceforge.net/mailarchive/message.php?msg_id=28809703 >> >> Some followups: >> http://sourceforge.net/mailarchive/message.php?msg_id=28824266 >> >> Maybe this helps some. >> Regards, >> Raul >> >> On Sat, Sep 1, 2012 at 2:34 AM, Dan Egnor <eg...@of...> wrote: >> >>> Hi, I have an XC2C384 ("CoolRunner-II"), which I'm trying to program >>> using xc3sprog. >>> >>> As the subject says, it almost works. Actually it does work but >>> verification fails. First of all, if I try to erase, it complains: >>> >>> % XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data >>> ./xc3sprog -c xpc -e >>> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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 >>> >>> Not erased in block 1 byte 232 value 0xf0 >>> >>> >>> I modified the code to not stop after the first blank check failure, and >>> that always fails in the same place: >>> >>> ... >>> Not erased in block 2 byte 232 value 0xf0 >>> Not erased in block 3 byte 232 value 0xf0 >>> Not erased in block 4 byte 232 value 0xf0 >>> Not erased in block 5 byte 232 value 0xf0 >>> Not erased in block 6 byte 232 value 0xf0 >>> ... and so on ... >>> >>> >>> If I try to actually program, I get verification failures: >>> >>> % XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data >>> ./xc3sprog -c xpc myfile.jed:w >>> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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 >>> >>> Verify: Row 1 >>> Verify mismatch row 1 byte 1860 cal file 1 device 0 >>> >>> >>> Again, with a hack to make it keep verifying after the first failure, >>> additional similar failures are found: >>> >>> >>> ... >>> Verify mismatch row 1 byte 1861 cal file 1 device 0 >>> Verify mismatch row 1 byte 1866 cal file 1 device 0 >>> Verify: Row 2 >>> Verify mismatch row 2 byte 1857 cal file 1 device 0 >>> Verify mismatch row 2 byte 1858 cal file 1 device 0 >>> Verify mismatch row 2 byte 1859 cal file 1 device 0 >>> Verify mismatch row 2 byte 1861 cal file 0 device 1 >>> Verify mismatch row 2 byte 1864 cal file 1 device 0 >>> Verify mismatch row 2 byte 1866 cal file 0 device 1 >>> Verify mismatch row 2 byte 1867 cal file 0 device 1 >>> Verify: Row 3 >>> ... and so on ... >>> >>> >>> Interestingly, after this "failed" programming run, if I go ahead and >>> tell iMPACT to verify against the same .JED file, verification succeeds! >>> Also the opposite: if I program with iMPACT, I get the same verification >>> errors with xc3sprog. So actually I think xc3sprog's programming is >>> working O.K.. My suspicion is that there's some "don't care" bits in the >>> bitfile, and xc3sprog doesn't know to ignore those when doing a >>> verification or blank check. Does this sound plausible? >>> >>> I'm using a Platform Cable USB II, but given that I'm getting this far, >>> I'm pretty sure the JTAG adapter is working just fine. The part gets >>> detected successfully, no issue there: >>> >>> % ./xc3sprog -c cpc >>> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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 >>> >>> JTAG loc.: 0 IDCODE: 0x16d5c093 Desc: XC2C384_TQ144 >>> Rev: A IR length: 8 >>> >>> >>> -- egnor >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Xc3sprog-users mailing list >>> Xc3...@li... >>> https://lists.sourceforge.net/lists/listinfo/xc3sprog-users >>> >>> >> > |
|
From: Dan E. <eg...@of...> - 2012-09-01 15:38:10
|
(Re-adding xc3sprog-users, since this is getting interesting...) Changing #define XPC_A6_CHUNKSIZE (1<<13) to #define XPC_A6_CHUNKSIZE 4 makes my problem go away! (It also makes programming somewhat slower not surprisingly.) I think this adds a lot of support to your hypothesis. I read through the threads you linked to and I come away with the notion that nobody seems to quite know exactly what's going on? Are you pretty confident in your understanding of the situation? Maybe basically the modifications you made within opencores (?) should be ported to xs3prog? And I guess urjtag is also broken but the CHUNKSIZE=4 means they never see the problem? Probably I should just use a different JTAG adapter? The XPC is annoying in other ways too! (Silly "fxload" business to get it working...) -- egnor On Sat, Sep 1, 2012 at 4:19 AM, Raul Fajardo <rfa...@gm...> wrote: > This might be related to an issue with the xpc_usb cable implementation. > But I have no guarantees for it. > > While porting the cable's implementation to another system, I noticed that > the assumption of bursts of more than 32 bits to be aligned is false as > long as the burst is not multiple of 32 (64 is ok but 63 has to be > realigned). > > I assumed that it happens seldom, possibly because the application does > not use bursts on non-32-multiple numbers. But there might be an exception. > Take a look on the port where I commented it: > http://sourceforge.net/mailarchive/message.php?msg_id=28809703 > > Some followups: > http://sourceforge.net/mailarchive/message.php?msg_id=28824266 > > Maybe this helps some. > Regards, > Raul > > On Sat, Sep 1, 2012 at 2:34 AM, Dan Egnor <eg...@of...> wrote: > >> Hi, I have an XC2C384 ("CoolRunner-II"), which I'm trying to program >> using xc3sprog. >> >> As the subject says, it almost works. Actually it does work but >> verification fails. First of all, if I try to erase, it complains: >> >> % XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data >> ./xc3sprog -c xpc -e >> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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 >> >> Not erased in block 1 byte 232 value 0xf0 >> >> >> I modified the code to not stop after the first blank check failure, and >> that always fails in the same place: >> >> ... >> Not erased in block 2 byte 232 value 0xf0 >> Not erased in block 3 byte 232 value 0xf0 >> Not erased in block 4 byte 232 value 0xf0 >> Not erased in block 5 byte 232 value 0xf0 >> Not erased in block 6 byte 232 value 0xf0 >> ... and so on ... >> >> >> If I try to actually program, I get verification failures: >> >> % XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data >> ./xc3sprog -c xpc myfile.jed:w >> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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 >> >> Verify: Row 1 >> Verify mismatch row 1 byte 1860 cal file 1 device 0 >> >> >> Again, with a hack to make it keep verifying after the first failure, >> additional similar failures are found: >> >> >> ... >> Verify mismatch row 1 byte 1861 cal file 1 device 0 >> Verify mismatch row 1 byte 1866 cal file 1 device 0 >> Verify: Row 2 >> Verify mismatch row 2 byte 1857 cal file 1 device 0 >> Verify mismatch row 2 byte 1858 cal file 1 device 0 >> Verify mismatch row 2 byte 1859 cal file 1 device 0 >> Verify mismatch row 2 byte 1861 cal file 0 device 1 >> Verify mismatch row 2 byte 1864 cal file 1 device 0 >> Verify mismatch row 2 byte 1866 cal file 0 device 1 >> Verify mismatch row 2 byte 1867 cal file 0 device 1 >> Verify: Row 3 >> ... and so on ... >> >> >> Interestingly, after this "failed" programming run, if I go ahead and >> tell iMPACT to verify against the same .JED file, verification succeeds! >> Also the opposite: if I program with iMPACT, I get the same verification >> errors with xc3sprog. So actually I think xc3sprog's programming is >> working O.K.. My suspicion is that there's some "don't care" bits in the >> bitfile, and xc3sprog doesn't know to ignore those when doing a >> verification or blank check. Does this sound plausible? >> >> I'm using a Platform Cable USB II, but given that I'm getting this far, >> I'm pretty sure the JTAG adapter is working just fine. The part gets >> detected successfully, no issue there: >> >> % ./xc3sprog -c cpc >> XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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 >> >> JTAG loc.: 0 IDCODE: 0x16d5c093 Desc: XC2C384_TQ144 >> Rev: A IR length: 8 >> >> >> -- egnor >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Xc3sprog-users mailing list >> Xc3...@li... >> https://lists.sourceforge.net/lists/listinfo/xc3sprog-users >> >> > |
|
From: Dan E. <eg...@of...> - 2012-09-01 00:34:16
|
Hi, I have an XC2C384 ("CoolRunner-II"), which I'm trying to program using
xc3sprog.
As the subject says, it almost works. Actually it does work but
verification fails. First of all, if I try to erase, it complains:
% XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data ./xc3sprog
-c xpc -e
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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
Not erased in block 1 byte 232 value 0xf0
I modified the code to not stop after the first blank check failure, and
that always fails in the same place:
...
Not erased in block 2 byte 232 value 0xf0
Not erased in block 3 byte 232 value 0xf0
Not erased in block 4 byte 232 value 0xf0
Not erased in block 5 byte 232 value 0xf0
Not erased in block 6 byte 232 value 0xf0
... and so on ...
If I try to actually program, I get verification failures:
% XC_MAPDIR=/auto/edatools/xilinx/m142i/14.2/ISE_DS/ISE/xbr/data ./xc3sprog
-c xpc myfile.jed:w
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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
Verify: Row 1
Verify mismatch row 1 byte 1860 cal file 1 device 0
Again, with a hack to make it keep verifying after the first failure,
additional similar failures are found:
...
Verify mismatch row 1 byte 1861 cal file 1 device 0
Verify mismatch row 1 byte 1866 cal file 1 device 0
Verify: Row 2
Verify mismatch row 2 byte 1857 cal file 1 device 0
Verify mismatch row 2 byte 1858 cal file 1 device 0
Verify mismatch row 2 byte 1859 cal file 1 device 0
Verify mismatch row 2 byte 1861 cal file 0 device 1
Verify mismatch row 2 byte 1864 cal file 1 device 0
Verify mismatch row 2 byte 1866 cal file 0 device 1
Verify mismatch row 2 byte 1867 cal file 0 device 1
Verify: Row 3
... and so on ...
Interestingly, after this "failed" programming run, if I go ahead and tell
iMPACT to verify against the same .JED file, verification succeeds! Also
the opposite: if I program with iMPACT, I get the same verification errors
with xc3sprog. So actually I think xc3sprog's programming is working O.K..
My suspicion is that there's some "don't care" bits in the bitfile, and
xc3sprog doesn't know to ignore those when doing a verification or blank
check. Does this sound plausible?
I'm using a Platform Cable USB II, but given that I'm getting this far, I'm
pretty sure the JTAG adapter is working just fine. The part gets detected
successfully, no issue there:
% ./xc3sprog -c cpc
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 683 $ 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
JTAG loc.: 0 IDCODE: 0x16d5c093 Desc: XC2C384_TQ144
Rev: A IR length: 8
-- egnor
|
|
From: Andy K. <and...@go...> - 2012-08-19 23:05:56
|
I have prepared SPI loaders for the GODIL boards with either Spartan 3E models XC3S500E or XC3S250E.
They are too big to mail to this group.
If you want them, just email me at and...@go....
Feel free to include them in the next distribution of xc3sprog.
xc3sprog is a great tool, and for me it is lucky it exists, as iMPACT crashes on my system.
Aside: FYI, posts to this group that get stuck in a moderation queue never seem to get moderated.
{{{ Andy
>> http://www.trenz-electronic.de/products/fpga-boards/oho-elektronik.html describes GODIL
>> http://www.baltissen.org/newhtm/rb6502.htm is Ruud Baltissens page describing using a GODIL to make a 6502
>> http://www.nyangau.org/rememorizer/rememorizer.htm describes my project trying to use a GODIL
|
|
From: Sebastian B. <seb...@ih...> - 2012-06-15 11:59:40
|
Hi, we are using a Xilinx Virtex-5 FPGA XC5VLX50 together with an AT45DB321 SPI Dataflash. Attached you find the bscan_spi VHDL code for indirect programming of the SPI flash adapted to the Virtex-5 FPGA, just in case it is useful for anyone else. Thanks for the great work! Best regards, Sebastian -- -------------------------------------------------- Dipl.-Ing. Sebastian Brückner Technische Universität Braunschweig Institut für Hochfrequenztechnik Schleinitzstr. 22 38106 Braunschweig Germany Tel.: +49-531-3912010 Email: seb...@ih... WWW: http://www.tu-braunschweig.de/ihf -------------------------------------------------- |
|
From: Arne Z. <ar...@ne...> - 2012-05-31 14:54:10
|
Hello guys, I'm currently working with a board with a FT4232H chip on it. This chip is very similar to the FT2232H chip which is already supported from xc3sprog. I'm no expert in xc3sprog, but it seems like you already support this chip if you would just add the lines into the cablelist.txt file. Since the chip has another DeviceID than the 2232H (0x6011 instead of 0x6010), I tried just replacing the DeviceIDs and it works just fine with -c ftdi, but not with -c ftdijtag, i don't know if that is a problem or not. Another thing is: it seem like the svn trunk version doesn't support the CABLEDB environment variable, or at least I dind't got it to use it. Hope you find this useful and great project btw. Bye, Arne |
4 messages has been excluded from this view by a project administrator.
