xc3sprog-users — Generic user and developer list

[Xc3sprog-users] Can you program the Dragon PCI FPGA with this software?

[Jovan T. <jov...@gm...>]

Hi everyone,

Has anybody tried programming this board:
http://www.knjn.com/FPGA-PCI.html with
xc3sprog? What would I need to do to get it to work?

Thanks,
Jovan

Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

> The problem with using twice the same word as magic (59a659a6)
> is that have_header is already '1' when the first word of magic is read,
> so that word can be combined with the last word of data.

Another (more backward compatible) fix would be making the bscan code
reset the read header each time it sets "have_header<='0'".

I modified my bscan_s3_spi_isf.vhdl as described below (with the old
59a659a6 magic); and now I can upload files with 59a6 in them (and any
other data I tried).

Here's my bscan_s3_spi_isf.vhdl:
http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl

Changes to reset
  --In 'rising edge' reset part:
      reset_header<='1';  --reset header at next rising clock
[...]
    elsif rising_edge(DRCK1) then
[...]
      --header <= header(46 downto 0) & TDI;
      --now becomes:
      reset_header<='0';  --make reset_header 0 the next clock
      if reset_header='0' then
        header <= header(46 downto 0) & TDI;
      else
        header <= (0=> TDI, others=>'0');
      end if;


On 6 June 2013 19:26, joosteto <joo...@gm...> wrote:

>     joosteto> So my question is: * am I right in thinking that the magic
>     joosteto> should be two different words, not twice the same
>
> > I only think that this will shift the problem to some other sequence.
>
> Actually, no, it will not.
>
> I just verified  by using the magic x"59a659a3", and by inserting that
> magic in my 59a6.bit file at 4 different offsets (mod 4).
>
> The reason is that bscan only compares the top 48 bits of its header signal
> with 59a659a3 when have_header is 0, thus after
>   CAPTURE || RESET || UPDATE || !SEL1
> becomes true. This only happens when the SPI sender is ready sending
> its data (I presume, as mentioned earlier, I cannot find where the .cpp
> code
> does this).
>
> The problem with using twice the same word as magic (59a659a6)
> is that have_header is already '1' when the first word of magic is read,
> so that word can be combined with the last word of data.
>
> When using something like 59a659a3 (two different words of magic),
> this condition is not reached.
>
>
> On 6 June 2013 17:51, Uwe Bonnes <bo...@el...>wrote:
>
>> >>>>> "joosteto" == joosteto  <joo...@gm...> writes:
>>
>>
>>     joosteto> So my question is: * am I right in thinking that the magic
>>     joosteto> should be two different words, not twice the same
>>
>> I only think that this will shift the problem to some other sequence.
>>
>> Benedikt Heinz, thr original author of of bscan_spi admits the problem and
>> proposed a better high-level SPI-Over-Jtag protocoll. Neither he nor me
>> have
>> time to do so at the moment.
>>
>> Bye
>>
>> --
>> Uwe Bonnes                bo...@el...
>>
>> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
>> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>>
>
>

Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

    joosteto> So my question is: * am I right in thinking that the magic
    joosteto> should be two different words, not twice the same

> I only think that this will shift the problem to some other sequence.

Actually, no, it will not.

I just verified  by using the magic x"59a659a3", and by inserting that
magic in my 59a6.bit file at 4 different offsets (mod 4).

The reason is that bscan only compares the top 48 bits of its header signal
with 59a659a3 when have_header is 0, thus after
  CAPTURE || RESET || UPDATE || !SEL1
becomes true. This only happens when the SPI sender is ready sending
its data (I presume, as mentioned earlier, I cannot find where the .cpp code
does this).

The problem with using twice the same word as magic (59a659a6)
is that have_header is already '1' when the first word of magic is read,
so that word can be combined with the last word of data.

When using something like 59a659a3 (two different words of magic),
this condition is not reached.


On 6 June 2013 17:51, Uwe Bonnes <bo...@el...>wrote:

> >>>>> "joosteto" == joosteto  <joo...@gm...> writes:
>
>
>     joosteto> So my question is: * am I right in thinking that the magic
>     joosteto> should be two different words, not twice the same
>
> I only think that this will shift the problem to some other sequence.
>
> Benedikt Heinz, thr original author of of bscan_spi admits the problem and
> proposed a better high-level SPI-Over-Jtag protocoll. Neither he nor me
> have
> time to do so at the moment.
>
> Bye
>
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

Re: [Xc3sprog-users] bscan 59a6 bug

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

>>>>> "joosteto" == joosteto  <joo...@gm...> writes:


    joosteto> So my question is: * am I right in thinking that the magic
    joosteto> should be two different words, not twice the same 

I only think that this will shift the problem to some other sequence.

Benedikt Heinz, thr original author of of bscan_spi admits the problem and
proposed a better high-level SPI-Over-Jtag protocoll. Neither he nor me have
time to do so at the moment.

Bye

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

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

Re: [Xc3sprog-users] bscan 59a6 bug

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

>>>>> "joosteto" == joosteto  <joo...@gm...> writes:

    joosteto> When writing to my papilio flash memory, certain bitfiles fail
    joosteto> the verify stage.

I am far away from Flash programnming at the moment, so few help from my
side, and no time to dig deeper.

I short test with a 59a6.bit shows problems on XC3S50AN too.

    joosteto> When investigating, this is what I found: * the failing
    joosteto> bifiles have 0x59a6 in them * the 2 bytes after the 0x59a6
    joosteto> fail to be written to the flash * the 'magic' code each SPI
    joosteto> command to bscan to write data to flash is 0x59a659a6 * the
    joosteto> program_sst method uses a spi_xfer_user1 command for every 2
    joosteto> bytes of data to be sent.

    joosteto> I cannot completely follow how the data is sent first to
    joosteto> bscan, and then the flash, but here is how I think the problem
    joosteto> arises: * if program_sst tries to send 0x59a6, it generates a
    joosteto> spi_xfer_user1 command that encapsulates the data, but the
    joosteto> package will end in 0x59a6.  * the next data to be send will
    joosteto> also be encapsulated, among others the magic 0x59a659a6 will
    joosteto> be prepended.

    joosteto> So, combining the last 2 bytes of the previous command, and
    joosteto> the initial magic of the last, there is a sequence:

    joosteto>   59 a6 59 a6 59 a6

    joosteto> What I think happens is that now the last 2 bytes of the last
    joosteto> command are interpreted as the beginning of the magic of the
    joosteto> next command.

    joosteto> Furthermore, when I modify the magic in spi_xfer_user1() to
    joosteto> not be twice the same word (and generate a matching bscan.bit
    joosteto> file), sending goes without problem (as does verifying).

    joosteto> The problem probably is more pronounced for the SST memory, as
    joosteto> it writes only 2 bytes a time; for flash modules with larger
    joosteto> pgsize the chance of encountering this problem will be
    joosteto> smaller.

    joosteto> Below or attached are: * The spi_xfer_user1 'patch' I applied,
    joosteto> * bscan.vhdl (one my Xilinx ISE accepts for xc3s500e, with
    joosteto> changed magic) * python file that will ruthlessly insert
    joosteto> 0x59a6 code into a bitfile, so that the bug should be apparent
    joosteto> for any flash with flash size <= 1024 bytes.

    joosteto> So my question is: * am I right in thinking that the magic
    joosteto> should be two different words, not twice the same 
    joosteto> * does anyone know how have_header (in bscan*.vhdl) becomes '0' at
    joosteto> the beginning of a SPI command? (what line is asserted
    joosteto> low/high, and where in ioftdi.cpp(?) is that done?)

In the Verilog code, have_header is reset to NULL with 
   wire        rst = CAPTURE || RESET || UPDATE || !SEL1;

Bye

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

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

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

[joosteto <joo...@gm...>]

> thanks for the patches, I just applied them. I'd be gratefull, if you
recheck.

Thanks!
I just checked out a new tree from trunk, and I now can use it to program
my papilio!

In more detail: I checked both these commands:

sudo ./xc3sprog -c papilio  ~/VHDL/ClkTrig/design_top.bit  -v

sudo ./xc3sprog -c papilio  ~/VHDL/LED2/LEDtest.bit
-I./bscan_spi/xc3s500e_godil.bit -R -v

There are bitfiles that don't work, but that's a separate issue I'll
describe later.


On 3 June 2013 11:37, Uwe Bonnes <bo...@el...>wrote:

> >>>>> "joosteto" == joosteto  <joo...@gm...> writes:
>
>     joosteto> I just backported the papilio SST patches to stock xc3sprog,
>     joosteto> diff attached.  (Also sneaked in a "papilio" definition in
>     joosteto> cablelist.txt).
>
>     joosteto> If this could be applied to trunk, I would be grateful.
>
> Hallo,
>
> thanks for the patches, I just applied them. I'd be gratefull, if you
> recheck.
>
> Thanks
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

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

>>>>> "joosteto" == joosteto  <joo...@gm...> writes:

    joosteto> I just backported the papilio SST patches to stock xc3sprog,
    joosteto> diff attached.  (Also sneaked in a "papilio" definition in
    joosteto> cablelist.txt).

    joosteto> If this could be applied to trunk, I would be grateful.

Hallo,

thanks for the patches, I just applied them. I'd be gratefull, if you
recheck.

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

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

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

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

>>>>> "joosteto" == joosteto  <joo...@gm...> writes:

    joosteto> I just saw the listserver made my post unreadable, so here
    joosteto> it's again.  I just backported the papilio SST patches to
    joosteto> stock xc3sprog, diff attached.

The patch in the first mail applied fine.


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

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

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

[joosteto <joo...@gm...>]

I just saw the listserver made my post unreadable, so here it's again.

I just backported the papilio SST patches to stock xc3sprog, diff attached.

(Also sneaked in a "papilio" definition in cablelist.txt).

If this could be applied to trunk, I would be grateful.

Now I program the flash of my papilio:

$ sudo ./xc3sprog -c papilio -I./bscan_spi/xc3s500e_godil.
bit ~/VHDL/LED2/LEDtest.bit  -v


and instead of attaching the diff, I'll paste it here as text, maybe that
works better?

Index: cablelist.txt
===================================================================
--- cablelist.txt       (revision 742)
+++ cablelist.txt       (working copy)
@@ -6,7 +6,8 @@
 # Max_Freq == 0 mean use maximum speed of device
 # Use 1500000 for all cable connected cables and max for all on board
cables

-ftdi          ftdi    1500000
0x0403:0x6010:
+ftdi          ftdi    1500000
0x0403:0x6010:
+papilio       ftdi    6000000 0x0403:0x6010:
 minila        ftdi     800000 0x0403:0x6010:
 ft232h        ftdi    1500000
0x0403:0x6014:
 ft4232h       ftdi    1500000 0x0403:0x6011:
Index: progalgspiflash.cpp
===================================================================
--- progalgspiflash.cpp (revision 742)
+++ progalgspiflash.cpp (working copy)
@@ -313,6 +313,39 @@
   return 1;
 }

+int ProgAlgSPIFlash::spi_flashinfo_sst(unsigned char *buf)
+{
+       fprintf(stderr, "Found SST device, Device ID 0x%02x%02x\n",
+                       buf[1], buf[2]);
+
+       if (buf[1]!=0x25) {
+               fprintf(stderr,"Does not look like this is a SST SPI flash
device\n");
+               return false;
+       }
+
+       pgsize = 256;
+       sector_size = 4096;
+
+       switch(buf[2])
+       {
+       case 0x8d: /* SST25VF040B */
+               pages = 2048;
+               break;
+       case 0x8e: /* SST25VF080B */
+               pages = 4096;
+               break;
+       case 0x41: /* SST25VF016B */
+               pages = 8192;
+               break;
+       default:
+               printf("Unknown SST Flash Size (0x%.2x)\n", buf[2]);
+               return false;
+       }
+       return true;
+}
+
+
+
 int ProgAlgSPIFlash::spi_flashinfo_m25p(unsigned char *buf)

 {
@@ -450,6 +483,9 @@
     case 0xef:
       res = spi_flashinfo_w25(fbuf);
       break;
+    case 0xbf:
+      res = spi_flashinfo_sst(fbuf);
+      break;
     default:
       fprintf(stderr, "unknown JEDEC manufacturer: %02x\n",fbuf[0]);
       return -1;
@@ -782,6 +818,39 @@
     return (j<limit)?0:1;
 }

+
+int ProgAlgSPIFlash::wait(byte command, byte mask, byte value, int report,
int limit, double *delta)
+{
+    int j = 0;
+    int done = 0;
+    byte fbuf[4];
+    byte rbuf[1];
+    struct timeval tv[2];
+
+    fbuf[0] = command;
+    spi_xfer_user1(NULL,0,0,fbuf, 1, 1);
+    gettimeofday(tv, NULL);
+    /* wait for command complete */
+    do
+    {
+        jtag->Usleep(1000);
+        spi_xfer_user1(rbuf,1,1,fbuf, 1, 1);
+        j++;
+        if ((jtag->getVerbose()) &&((j%report) == (report -1)))
+        {
+            /* one tick every report mS wait time */
+            fprintf(stderr,".");
+            fflush(stderr);
+                }
+        done = (rbuf[0] & mask)==mask;
+    }
+    while (!done && (j < limit));
+    gettimeofday(tv+1, NULL);
+    *delta = deltaT(tv, tv + 1);
+    return (j<limit)?0:1;
+}
+
+
 int ProgAlgSPIFlash::sectorerase_and_program(BitFile &pfile)
 {
   unsigned int i, offset, data_end, data_page = 0;
@@ -891,6 +960,165 @@
   return 0;
 }

+
+void ProgAlgSPIFlash::sst_disable_write_protect()
+{
+    byte fbuf[2];
+    const byte tCE=10;
+    fbuf[0] = 0x50; // EWSR
+    spi_xfer_user1(NULL,0,0,fbuf,0,1);
+    jtag->Usleep(tCE);
+    fbuf[0] = 0x01;
+    fbuf[1] = 0x00; // WRSR
+    spi_xfer_user1(NULL,0,0,fbuf,0,2);
+    jtag->Usleep(tCE);
+}
+
+int ProgAlgSPIFlash::program_sst(BitFile &pfile)
+{
+    byte fbuf[4];
+    byte AAIP_Cmd[6]={0xad,0x00,0x00,0x00,0xaa,0xaa};
+    double delta;
+    const unsigned long tCE=50;
+    const unsigned long tBP=10;
+    bool inAAImode;
+
+    unsigned int i, offset, data_end= 0;
+
+    offset = (pfile.getOffset()/pgsize)*pgsize;
+    if (offset > pages *pgsize)
+    {
+        fprintf(stderr,"Program start outside PROM area, aborting\n");
+        return -1;
+    }
+
+    if (pfile.getRLength() != 0)
+    {
+        data_end = offset + pfile.getRLength();
+    }
+    else
+    {
+        data_end = offset + pfile.getLength()/8;
+    }
+
+    if( data_end > pages * pgsize)
+    {
+        fprintf(stderr,"Program outside PROM areas requested, clipping\n");
+        data_end = pages * pgsize;
+    }
+
+
+
+    fbuf[0] = 0x06; // WREN
+    spi_xfer_user1(NULL,0,0,fbuf,0,1);
+    jtag->Usleep(tCE);
+
+    fbuf[0] = 0x80; // DBSY
+    spi_xfer_user1(NULL,0,0,fbuf,0,1);
+    jtag->Usleep(tCE);
+
+    sst_disable_write_protect();
+
+    fbuf[0] = 0x06; // WREN
+    spi_xfer_user1(NULL,0,0,fbuf,0,1);
+    jtag->Usleep(tCE);
+
+    if (wait( READ_STATUS_REGISTER, 0x40, 0x40, tCE>>2, tCE, &delta)!=0) {
+        fprintf(stderr,"Error waiting for flash\n");
+        return -1;
+    }
+
+    // TODO: Check enough bytes and /2 alignment
+
+
+    /*    if (wait(READ_STATUS_REGISTER, 0x1f, 0x2, tCE>>2, tCE,
&delta)<0) {
+     fprintf(stderr, "Timeout\n");
+     return -1;
+     }
+     */
+
+    unsigned int sector_nr = 0;
+    int j;
+    /* Sector erasing */
+    for(i = offset ; i < data_end; i+= sector_size) {
+
+        if (sector_nr   <= i/sector_size)
+        {
+            sector_nr = i/sector_size +1;
+            /* Enable Write */
+            fbuf[0] = WRITE_ENABLE;
+            spi_xfer_user1(NULL,0,0,fbuf, 0, 1);
+            /* Erase selected page */
+            fbuf[0] = sector_erase_cmd;
+            page2padd(fbuf, i/pgsize, pgsize);
+            spi_xfer_user1(NULL,0,0,fbuf, 0, 4);
+            if(jtag->getVerbose())
+                fprintf(stderr,"\rErasing sector %2d/%2d",
+                        sector_nr,
+                        (data_end + sector_size + 1)/sector_size);
+            j = wait(READ_STATUS_REGISTER, 100, 3000, &delta);
+            if(j != 0)
+            {
+                fprintf(stderr,"\nErase failed for sector %2d\n",
sector_nr);
+                return -1;
+            }
+            else
+            {
+              //  if (delta > max_sector_erase)
+              //      max_sector_erase= delta;
+            }
+        }
+    }
+    fprintf(stderr,"\n");
+
+    inAAImode = false;
+
+    fbuf[0] = 0x06; // WREN
+    spi_xfer_user1(NULL,0,0,fbuf,0,1);
+    jtag->Usleep(tCE);
+
+    if (wait( READ_STATUS_REGISTER, 0x40, 0x40, tCE>>2, tCE, &delta)!=0) {
+        fprintf(stderr,"Error waiting for flash\n");
+        return -1;
+    }
+
+    for(i = offset ; i < data_end; i+= 2)
+    {
+
+        if (inAAImode) {
+            AAIP_Cmd[1] = bitRevTable[ pfile.getData()[i-offset] ];
+            AAIP_Cmd[2] = bitRevTable[ pfile.getData()[i-offset+1] ];
+        } else {
+            AAIP_Cmd[1] = (offset>>16)&0xff;
+            AAIP_Cmd[2] = (offset>>8)&0xff;
+            AAIP_Cmd[3] = (offset)&0xff;
+
+            AAIP_Cmd[4] = bitRevTable[ pfile.getData()[i-offset] ];
+            AAIP_Cmd[5] = bitRevTable[ pfile.getData()[i-offset+1] ];
+        }
+        spi_xfer_user1(NULL,0,0,&AAIP_Cmd[0], 0, inAAImode ? 3 : 6);
+        inAAImode=true;
+    }
+    printf("Programming done\n");
+
+    fbuf[0] = 0x04; // WRDI
+    spi_xfer_user1(NULL,0,0,fbuf, 0, 1);
+
+    if (wait(READ_STATUS_REGISTER, 0x01, 0x0, tBP>>2, tBP, &delta)<0) {
+        fprintf(stderr,"Timeout\n");
+        return -1;
+    }
+
+    return 0;
+}
+int ProgAlgSPIFlash::erase_sst()
+{
+    sst_disable_write_protect();
+    return erase_bulk();
+}
+
+
+
 int ProgAlgSPIFlash::program(BitFile &pfile)
 {
   unsigned int len = pfile.getLength()/8;
@@ -908,6 +1136,8 @@
   case 0xef: /* Winbond */
   case 0x89: /* Intel S33 */
     return sectorerase_and_program(pfile);
+  case 0xbf:
+    return program_sst(pfile);
   default:
     fprintf(stderr,"Programming not yet implemented\n");
   }
@@ -1096,6 +1326,8 @@
   case 0x89: /* Intel */
   case 0xef: /* Winbond */
     return erase_bulk();
+  case 0xbf: /* SST */
+      return erase_sst();
   default:
     fprintf(stderr,"Programming not yet implemented\n");
   }
Index: progalgspiflash.h
===================================================================
--- progalgspiflash.h   (revision 742)
+++ progalgspiflash.h   (working copy)
@@ -66,11 +66,18 @@
   int spi_flashinfo_w25 (unsigned char * fbuf);
   int spi_flashinfo_at45(unsigned char * fbuf);
   int spi_flashinfo_m25p(unsigned char * fbuf);
+  int spi_flashinfo_sst(unsigned char * fbuf);
   int wait(byte command, int report, int limit, double *delta);
+  int wait(byte command, byte mask, byte value, int report, int limit,
double *delta);
   int program_at45(BitFile &file);
+  int program_sst(BitFile &pfile);
+  void sst_disable_write_protect();
   int sectorerase_and_program(BitFile &file);
   int erase_at45();
   int erase_bulk();
+  int erase_sst();
+  int sst_has_completed();
+
  public:
   ProgAlgSPIFlash(Jtag &j);
   ~ProgAlgSPIFlash(void);

Re: [Xc3sprog-users] IDCODE for XC2C32A_QF32

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

>>>>> "Fabien" == Fabien Marteau <fab...@ar...> writes:

    Fabien> Hi all, I use your xc3sprog to program the CPLD XC2C32A_QF32 but
    Fabien> the ID returned by my chip is : 06e19093 Instead of 06c1b093 As
    Fabien> I can see in your file devlist.txt.  I don't know if it's a bug
    Fabien> from my part, in doubt you can find a patch in attachment.

Thanks for the hint. I corrected in Sourceforge and added some remarks.

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

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

[Xc3sprog-users] IDCODE for XC2C32A_QF32

[Fabien M. <fab...@ar...>]

Hi all,

I use your xc3sprog to program the CPLD XC2C32A_QF32 but the ID returned
by my chip is :
 06e19093
Instead of 
06c1b093
As I can see in your file devlist.txt.
I don't know if it's a bug from my part, in doubt you can find a patch
in attachment.

Regards,

-- 
Fabien Marteau
Hardware Engineer
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
ARMadeus Systems - A new vision of the embedded world
http://www.armadeus.com

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

[Shanjit S. <sha...@gm...>]

Oh i haven't really found a solution to using xc3sprog or papilio prog for
programming my SST25VF040B-80-4I-SAE SPI Flash.

*I am planning to generate a svf file using impact tool and then burn it
using the Digilent JTAG-USB (adept 2) on my board. This will hopefull get
me around using the ft2232 chip. *
*
*

--
Shanjit Singh Jajmann
Final Year Undergraduate Student,
Netaji Subhas Institute of Technology,
University of Delhi, India
+91-9013523548
http://www.shanjitsingh.in


On Mon, Apr 1, 2013 at 4:12 PM, Uwe Bonnes <
bo...@el...> wrote:

> >>>>> "Álvaro" == Álvaro Lopes <alv...@al...> writes:
>
>     Álvaro> Hi Uwe, I have not written those patches myself, but if I
> recall
>     Álvaro> the main reason they were not sent to the community is because
>     Álvaro> the implementation is for a very old version of xc3sprog.
>
>     Álvaro> Let me see if I can contact the authors so we can rebase the
>     Álvaro> code for the latest version. AFAIK this was done by someone not
>     Álvaro> very used to programming, so will surely need proper
>     Álvaro> cleanup. Also I think it was not managed by any VCS so might be
>     Álvaro> hard to track the changes....
>
> But first, have a look if xc3sprog doesn't support the chips already. My
> first mail was sprackeled with "if"s, as I remember I did some work for SST
> chips. But Shanjit didn't tell the exact chip, so I couldn't up. Perhaps he
> did already.
>
> Bye
>
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

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

>>>>> "Álvaro" == Álvaro Lopes <alv...@al...> writes:

    Álvaro> Hi Uwe, I have not written those patches myself, but if I recall
    Álvaro> the main reason they were not sent to the community is because
    Álvaro> the implementation is for a very old version of xc3sprog.

    Álvaro> Let me see if I can contact the authors so we can rebase the
    Álvaro> code for the latest version. AFAIK this was done by someone not
    Álvaro> very used to programming, so will surely need proper
    Álvaro> cleanup. Also I think it was not managed by any VCS so might be
    Álvaro> hard to track the changes....

But first, have a look if xc3sprog doesn't support the chips already. My
first mail was sprackeled with "if"s, as I remember I did some work for SST
chips. But Shanjit didn't tell the exact chip, so I couldn't up. Perhaps he
did already.

Bye 

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

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

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

[Álvaro L. <alv...@al...>]

On 31/03/13 13:15, Uwe Bonnes wrote:
>>>>>> "Alvie" == Alvie  <alv...@gm...> writes:
> 
>     Alvie> On 31/03/13 12:24, Uwe Bonnes wrote:
>     >>>>>>> "Shanjit" == Shanjit Singh <sha...@gm...> writes:
>     >>
>     Shanjit> I am more than happy to get my hands dirty! Any pointers ?  --
>     >>  The sources are available at
>     >> https://sourceforge.net/projects/xc3sprog/
> 
>     Alvie> Papilio Prog supports SST, perhaps you want to take a look at it
>     Alvie> too:
> 
>     Alvie> https://github.com/GadgetFactory/Papilio-Loader/tree/master/papilio-prog
> 
> Why don't the Papilio People contribute back?
> 

Hi Uwe, I have not written those patches myself, but if I recall the main reason they were not sent to the community is because the implementation is for a very
old version of xc3sprog.

Let me see if I can contact the authors so we can rebase the code for the latest version. AFAIK this was done by someone not very used to programming, so will
surely need proper cleanup. Also I think it was not managed by any VCS so might be hard to track the changes....

Alvie

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

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

>>>>> "Alvie" == Alvie  <alv...@gm...> writes:

    Alvie> On 31/03/13 12:24, Uwe Bonnes wrote:
    >>>>>>> "Shanjit" == Shanjit Singh <sha...@gm...> writes:
    >>
    Shanjit> I am more than happy to get my hands dirty! Any pointers ?  --
    >>  The sources are available at
    >> https://sourceforge.net/projects/xc3sprog/

    Alvie> Papilio Prog supports SST, perhaps you want to take a look at it
    Alvie> too:

    Alvie> https://github.com/GadgetFactory/Papilio-Loader/tree/master/papilio-prog

Why don't the Papilio People contribute back?

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

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

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

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

>>>>> "Shanjit" == Shanjit Singh <sha...@gm...> writes:

    Shanjit> I am more than happy to get my hands dirty! Any pointers ?  --

The sources are available at
https://sourceforge.net/projects/xc3sprog/
-- 
Uwe Bonnes                bo...@el...

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

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

[Shanjit S. <sha...@gm...>]

I am more than happy to get my hands dirty! Any pointers ?

--
Shanjit Singh Jajmann
Final Year Undergraduate Student,
Netaji Subhas Institute of Technology,
University of Delhi, India
+91-9013523548
http://www.shanjitsingh.in


On Sat, Mar 30, 2013 at 11:24 PM, Uwe Bonnes <
bo...@el...> wrote:

> >>>>> "Shanjit" == Shanjit Singh <sha...@gm...> writes:
>
>     Shanjit> Hello, I am trying to make my own custom XC3S250E based
>     Shanjit> board. Can i use XC3Sprog for programming my SST based Serial
>     Shanjit> Flash which is connected to my FPGA using a Digilent Adept
>     Shanjit> based programmer ?
>
> To reply like radio eriwan:
>
> "In principle yes"
>
> But I have no access to that special combination and so have not tested
> it. There might miss small pieces, e.g. the FLASH ID or perhaps even the
> Flash has a slightly changed algorithm. But even then it should be doable
> to
> worked it out with some effort.
>
> Bye
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

Re: [Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

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

>>>>> "Shanjit" == Shanjit Singh <sha...@gm...> writes:

    Shanjit> Hello, I am trying to make my own custom XC3S250E based
    Shanjit> board. Can i use XC3Sprog for programming my SST based Serial
    Shanjit> Flash which is connected to my FPGA using a Digilent Adept
    Shanjit> based programmer ?

To reply like radio eriwan:

"In principle yes"

But I have no access to that special combination and so have not tested
it. There might miss small pieces, e.g. the FLASH ID or perhaps even the
Flash has a slightly changed algorithm. But even then it should be doable to
worked it out with some effort.

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

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

[Xc3sprog-users] Use SST Serial SPI Flash with Spartan 3E board ?

[Shanjit S. <sha...@gm...>]

Hello,

I am trying to make my own custom XC3S250E based board. Can i use XC3Sprog
for programming my SST based Serial Flash which is connected to my FPGA
using a Digilent Adept based programmer ?

Thank You!
--
Shanjit Singh Jajmann
Final Year Undergraduate Student,
Netaji Subhas Institute of Technology,
University of Delhi, India
+91-9013523548
http://www.shanjitsingh.in

[Xc3sprog-users] Recent changes

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

Hallo,

a recent SVN xc3sprog version
- has speed improvements (about factor 3 for XCFP)
- works with big mcs files on windows
- gives some more hint on IHEX usage for mcs files
- provides a stripped win32 binary for xc3sprog

As always, the use of self compiled executables is preferred.

Please let us know when there are problems.

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

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

Re: [Xc3sprog-users] Feedback wanted: IHEX versus MCS

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

Hi Uwe,

On 2013-02-11, Uwe Bonnes wrote:
> it seems we have IHEX and MCS reversed. For a pair of *.bit and *.mcs
> files, bitparse only reports the same checksum with the MCS file
> interpreted as IHEX:

> Should we fix this mess with the risk of breaking existing setups?

My preference is to make it work right, even if we have been doing it
wrong for several years.

But are you sure that reversing this will make it right?
I guess you compared MCS and BIT files both generated by Xilinx
tools, so we can be sure that our understanding of MCS will be
compatible with that of Xilinx.

What about IHEX. How do you know that IHEX also needs to be reversed?

Joris.

[Xc3sprog-users] Feedback wanted: IHEX versus MCS

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

Hello,

it seems we have IHEX and MCS reversed. For a pair of *.bit and *.mcs files,
bitparse only reports the same checksum with the MCS file interpreted as
IHEX:

> bitparse -i MCS count.mcs
64-bit sum: 29796389
> bitparse -i IHEX count.mcs
64-bit sum: 31015201
> bitparse -i BIT count.bit
64-bit sum: 3101520

Should we fix this mess with the risk of breaking existing setups?

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

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

Re: [Xc3sprog-users] Added JTAG-HS2 cable

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

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

    Joris> Hi Uwe, I added support for the Digilent JTAG-HS2 cable to
    Joris> cablelist.txt.  It is an FTDI-based cable similar to the HS1, but
    Joris> with a different FTDI chip and requiring different "magic bytes"
    Joris> on the GPIO pins.

    Joris> I also made a small change to FT232H support in ioftdi.cpp.  To
    Joris> allow compilation of xc3sprog on older versions of libftdi, there
    Joris> was an "#ifdef TYPE_232H" statement in ioftdi.cpp. However,
    Joris> because TYPE_232H is defined in an enum, the #ifdef is always
    Joris> skipped.

    Joris> I changed "#ifdef TYPE_232H" into "#ifdef DRIVE_OPEN_COLLECTOR",
    Joris> which was added to ftdi.h in the same commit as TYPE_232H. This
    Joris> is not the most elegant way, but it works for now.

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

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

[Xc3sprog-users] Added JTAG-HS2 cable

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

Hi Uwe,

I added support for the Digilent JTAG-HS2 cable to cablelist.txt.
It is an FTDI-based cable similar to the HS1, but with a different FTDI
chip and requiring different "magic bytes" on the GPIO pins.

I also made a small change to FT232H support in ioftdi.cpp.
To allow compilation of xc3sprog on older versions of libftdi, there
was an "#ifdef TYPE_232H" statement in ioftdi.cpp. However, because
TYPE_232H is defined in an enum, the #ifdef is always skipped.

I changed "#ifdef TYPE_232H" into "#ifdef DRIVE_OPEN_COLLECTOR", which
was added to ftdi.h in the same commit as TYPE_232H. This is not the
most elegant way, but it works for now.

Greetings, Joris.

Re: [Xc3sprog-users] xc3sprog and Digilent "atlys" board?

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

On 2012-12-03, Uwe Bonnes wrote:
>     Joris> The Atlys board also has an on-board JTAG-USB programmer
>     Joris> based on a Cypress FX2, but it uses a proprietary USB
>     Joris> protocol and therefore does not work with xc3sprog.
> 
> Did you try the the xpc cable? Perhaps it Digilent uses that cable?

Yes, I tried xpc and fx2 but they don't work.
I think their FX2 firmware is a Digilent-specific design.

It may be possible to adapt the XGUFF firmware to run on the FX2
chip on the Atlys board, but it is low on my list.

> Probably it is the same chip in the  csg324 and  fg484 package. If it
> works, it should be safe.

Ok, that makes sense.

Thanks, Joris.