Xc3sprog

Links

• Original xc3sprog code: svn checkout svn://svn.code.sf.net/p/xc3sprog/code/trunk xc3sprog-code
• Papilio-patched xc3sprog: git clone git://github.com/GadgetFactory/Papilio-Loader.git, in sub-dir Papilio-Loader/xc3sprog/trunk
• backport of papilio SST flash changes for xc3sprog

xc3sprog bscan 59a6 bug

Programming the flash happens by first programming the FPGA with the bscan utility. This utility then receives the to-be-programmed flash data, and forwards it to the flash memory. For SST this happens 2 bytes at a time. Each time a header is prepended to the data, consisting of 32 magic bits (59a659a6), and some more.

The bscan FPGA progam waits for the 32 magic bits, and then decodes the rest of the header and data, like this:

Computer indicates start of package (DRCK1, CAPTURE, RESET, UPDATE, SEL1, cannot tell)
  -> FPGA-bscan sets have_header<='0'
Computer sends package: 59 a6 59 a6  00 03  ad 12 34
  -> FPGA-bscan sees magic, reads next two bytes (length), and  reads the data (ad-code, 12+34, data for flash).

The problem arises when the last two bytes of the data (in the SST case, the only two bytes) are 59 a6. Then the following happens:

Computer sends package: 59 a6 59 a6  00 03  ad 59 a6
  -> FPGA-bscan sees magic, reads next two bytes (length), and  reads the data (ad-code, 59-a6, data for flash), all OK.
Computer indicates start of package (DRCK1, CAPTURE, RESET, UPDATE, SEL1, cannot tell)
  -> FPGA-bscan sets have_header<='0'
     Now the 'header' signal in bscan contains "a6  00 03  ad 59" (last 6 bytes)
Computer sends first 4 bytes of next package (header): 59 a6 59 a6
  -> FPGA-bscan continuously shifts the read data into its 'header' signal, and thus at some point will have:
   59 a6 59 a6 59 a6  (first two bytes are last two bytes of last package, rest is magic header)
  -> FPGA-bscan now interprets the first two databytes + first to magic bytes as the magic header, and the length becomes "59 a6".
-> Error.

As this problem happens because the magic 32 bits consist of twice the same 16-bit 59a6 value, the fix is simple: Just make the second 16-bit word different. This is done with the following xc3sprog patch, and the matching bscan.vdhl (needs to be patched too).

--- /tmp/progalgspiflash.cpp    2013-05-30 00:11:14.242804341 +0200
+++ ./progalgspiflash.cpp       2013-05-30 00:11:20.370804622 +0200
@@ -535,13 +535,13 @@
     if(mosi_len + preamble + 4 + 2 > maxlen)
       maxlen = mosi_len + preamble + 4 + 2;
     // SPI magic
     mosi_buf[0]=0x59;
     mosi_buf[1]=0xa6;
     mosi_buf[2]=0x59;
-    mosi_buf[3]=0xa6;
+    mosi_buf[3]=0xa3;
     
     // SPI len (bits)
     mosi_buf[4]=((mosi_len + preamble)*8)>>8;
     mosi_buf[5]=((mosi_len + preamble)*8)&0xff;
     
     // bit-reverse header

Bscan_s3_spi_isf.vhdl, works for XC3S500E (papilio), with 59 a6 59 a3 magic. This is built using the standard xc3s500e_godil.ucf user constraings file:

NET "MISO"  LOC = "P44" | IOSTANDARD = LVCMOS33 ; 
NET "MOSI"  LOC = "P27" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 6 ;
NET "CSB"   LOC = "P24" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 6 ;
NET "DRCK1" LOC = "P50" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE = 6 ;

and results in the following Xc3s500e_godil-59a3.bit

xc3sprog & papilio

The original xc3sprog doesn't support the SST flash on the Papilio. So instead use the papilio xc3sprog fork. Another option is to apply this patch (backport of papilio SST flash changes). After applying that patch, the Papilio flash can be programmed as follows:

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