the nexys is a spartan3 based fpga board including an ez-usb (cypress fx2 high-speed usb2) chip onboard. digilent offers an api for doing jtag and data transfers via usb called dpcutil, which unfortunately is not available for linux and (at least the fx2 firmware) is digilent proprietary.
on linux a software based on libusb would be nice to do high-speed data transfer with the nexys device. downloading the configuration to the fpga via usb would be nice too.
therefor the firmware which initializes and runs the fx2 chip is of great interest. basically it's all about the firmware here. for the nexys device the firmware is stored on the i2c eeprom loacted next to the fx2 chip. it's loaded into the 8051 ram during bootup.
in the very end, we want to have a
therefor we need to
i will put everything into the brainstorming chapter by now. depending on the authors initial skill adaption training process ;) contents will be presented in a more clean and structured way later on ...
unzip the upgrader executable to extract the iic (probably i2c) files, the content of the eeprom, which basically is the firmware.
digilent has 3 different types of usb (and firmwares).
00000000 c2 47 05 31 21 00 00 04 00 04 00 00 02 32 81 32
00003450 d6 00 02 10 d6 00 02 10 d6 00 80 01 e6 00 00
use the following small tool to convert iic files storing the eeprom content to intel hex files. it is called ee2ihex.c. instructions for building and usage included in the source file.
since we are now able to download the digilent firmware (to provide original functionality) into fx2 ram (possibly even restore eeprom content) using fxload, we may now start playing around with the eeprom with a clear conscience.
you have to use the tool and convert it to intel hex yourself. i am probably not allowed to offer the intel hex file due to copyrights.
good news, we do not need to intercept i2c communication or even destroy the eeprom content :).fortunately two drills of a removed 2-pin jumper on the sda bus exist (the bus is shorted onboard). you can carefully scratch the wire on the board and after that solder in a 2-pin jumper.
now, if the jumper is
it's time to hack the replacment firmware now. the current development code is located at
and will be called fx2.c (source) / fx2.ihx (intel hex).
let's start simple. one possibility for the nexys board to get power is the usb bus powered configuration.
according to the schematics a mosfet (nts2101) is switching on/off the power to the ltc devices. the gate of a transistor (connected to the gate of the nts) is connected to port d / pin 7 of the fx2. lets configure this pin as output and pull it high.
this is now working. my brother got it running. he used a fx2regs.h file from another project which properly defined the registers for data direction and the port. (see http://www.hackdaworld.org/cgi-bin/gitweb.cgi?p=my-code/fpga.git;a=commitdiff;h=3b3815fdc9a4919917fa98b90416ac368aed69ca)
there is a cypress fx2 xilprg patch available in the cvs repository now. apply the patch to have bitbanging support for the nexys board to do jtag via usb.
firmware in progress ... coffee first ...
to be continued ...
(un)supported faetures of the current firmware:
strange problem when trying to download firmware using fxload:
staubsauger:/home/hackbard/projects/fpga/fx2# fxload -vvv -t fx2 -I ./fx2.ihx -D /proc/bus/usb/002/005 microcontroller type: fx2 single stage: load on-chip memory open RAM hexfile image ./fx2.ihx stop CPU ** LINE: :03000000020003F8 record too short? unable to download ./fx2.ihx
on debian unstable dpkg -l fxload tells you the following:
ii fxload 0.0.20020411-1 Firmware download to EZ-USB devices
a change which fixes this issue was committed to sourceforge cvs in january 2005. you need to build fxload from cvs.
now it's possible to fxload intel hex files on the fx2. as a test try to fxload the bulkloop.hex file from the cypress development kit examples. proper bulk tranfers may be verified with the usb_bulk_test.c code also located at:
hackbard@staubsauger:~/projects/fpga/fx2$ sudo ./usb_bulk_test /proc/bus/usb/002/018 0 0 0x02 0x86 poke random data into buffer ... done summary: device /proc/bus/usb/002/018 interface 0 alternate setting 0 bulk ep (out) 22 bulk ep (in) 862 setting interface 0, alternate setting 0 transmit done (256) - receive  done (256) <--- equal! transmit done (256) - receive  done (256) <--- equal! transmit done (256) - receive  done (256) <--- equal! ...bulkloop seems to work. but how about the digielnt donbusb firmware, converted to an intel hex file by the tool mentioned earlier?
here we go:
hackbard@staubsauger:~/projects/fpga/fx2$ sudo fxload -t fx2 -D /proc/bus/usb/002/019 -I donbusb.ihx can't write 1023 bytes external memory at 0x1c5c unable to download donbusb.ihx
this sucks! is there external memory (check with a3load!)? is fxload troubling for no reason (reread memory related pages of the docs!)? is the ee2ihex conversion tool crappy (too simple!)?
hackbard@staubsauger:~/projects/fpga/fx2$ sudo fxload -t fx2 -D /proc/bus/usb/002/021 -I donbusb.ihx -s a3load.hex hackbard@staubsauger:~/projects/fpga/fx2$ lsusb Bus 002 Device 022: ID 1443:0005 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000
digilent vendor and product ids can be seen, renumeration succeeded. and the usb bus powered configuration makes the fpga do it's job! now we know for sure that it's possible to get the digilent firmware into ram! quite good so far. using vend_ax instead of a3load and specifying a control byte might even write the firmware back to the eeprom (once we fucked it up).
now that the basics are done (except understanding the memory layout) => GO FOR THE FIRMWARE ...
to be continued ...