Apr 2010: fxload updated to flash VID:PID (version ww3)

My patched version of fxload now supports an option (-d) to write aribtrary VID:PID combinations into the EEPROM.

Dez 2009: Extended to cover pitfalls

Extended to cover pitfalls; extended the "bricked device" section.

Aug 2009: First publication

Finally, I decided to put this online for the benefit of everybody.

Fxload is a small and useful tool to program an EEPROM attached to the FX2. It's written by several people and the newest version can be downloaded from the linux hotplug project page.
Note: If you are merely interested in downloading firmware onto the FX2's RAM (for testing/debugging/software development or for configuration after the FX2 has been plugged into the USB), then have a look at CycFX2Prog. Fxload is only needed if you want to permanently program an extra EEPROM storage attached to the FX2.

Unfortunately, fxload from the link above does not include a good second-stage boot loader for all vendor specific commands 0xAx and hence cannot directly be used to program EEPROM storage. However, such a bootloader is available separately if you dig around on the Cypress page. (Note: This "second stage bootloader" is sometimes also called "third stage".)

In order to make your live easier, here is a download package which contains the Cypress second stage bootloader called Vend_Ax.hex and the fxload source from 2008-10-13 (newest version at time of writing). The version below has a patch by me which allows to "erase" the EEPROM again and which sets the default vendor and product IDs in the EEPROM when flashing.

Source:		fxload-full-2008_10_13-ww3.tar.gz   [28kb gzipped source tarball]
Version:		2008_10_13-ww3 (patched my me Apr 2010)   (2010-04-05)
Author:		linux hotplug project page, Wolfgang Wieser   (report bugs here)
License:		GPL, other

Building the program should be fairly easy: Unpack the archive and run make in the fxload source dir.

Important note: The firmware flashed onto the FX2 must set vendor and product ID and connect to the USB. This is somewhat different to simple firmware which you download to an unconfigured FX2 via CycFX2Prog:

When the FX2 loads its firmware from the EEPROM, it will come up with the RENUM bit set to 1. This means that the firmware has to handle USB requests because the built-in EZ-USB logic is inactive. If the firmware does not handle USB requests, the FX2 will not enumerate at all and hence you bricked your board (see below).

There are 2 ways around this: Either handle the USB requests in firmware like the convert_serial examples or force the FX2's internal logic to handle those requests. For the latter, the easiest way is to insert the following code snippet at the beginning of your code (right as the first line in main()):

#define FX2_RENUM   (1U<<1)
#define FX2_DISCON  (1U<<3)

if(USBCS & FX2_RENUM)
{
    // RENUM bit is set indicating that the uC should handle USB requests.
    // This happens if the program is loaded from EEPROM.
    // Disconnect, switch off RENUM and reconnect again to force the FX2
    // logic to handle USB requests.
    USBCS |=  FX2_DISCON;  SYNCDELAY;
    USBCS &= ~FX2_RENUM;   SYNCDELAY;
    USBCS &= ~FX2_DISCON;  SYNCDELAY;
}

A program starting with this code will work equally well when loaded from EEPROM and when downloaded via CycFX2Prog (without use of an EEPROM).

Note that this requires that you supply vendor and product ID in the config EEPROM as well! My patched version of fxload (available above) will automatically load the default ("unconfigured") FX2/FX2LP IDs into the EEPROM when flashing a firmware to make your life easier.

Okay, so here is how you download firmware. Assume that we just compiled the convert_serial2 firmware in the advanced examples page. This firmware will re-numerate as Sierra wireless modem, so it can easily be seen whether the flashing succeeded.

First, plug in the (probably unconfigured) FX2. Call lsusb to list the attached USB devices and find out the bus and device number, e.g:

Bus 008 Device 049: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit
Bus 008 Device 044: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 008 Device 001: ID 1d6b:0002
Bus 007 Device 001: ID 1d6b:0002
Bus 005 Device 001: ID 1d6b:0001
...

The attached unconfigured FX2 has the numbers 008 and 049. Hence, we can flash the firmware called convert_serial2.ihx using the following command:

fxload -D /proc/bus/usb/008/049 -I convert_serial2.ihx -c 0x01 -s Vend_Ax.hex -t fx2

The 0x01 argument sets the configuration byte in the EEPROM. Its content is:

0 DISCON 0 0 0 0 0 400KHZ

DISCON: When 1, come up disconnected from USB at startp (be careful, see USBCS.3).
400KHZ: When 1, run I2C at 400kHz, otherwise 100kHz.

I recommend using 0x01, i.e. 400kHz and not disconnected. When coming up disconnected, the firmware must connect the USB by setting DISCON (bit 3 in USBCS) to zero. If the firmware is defective, you bricked the board. If you are using the reconnect code snipped from above (to force the FX2 logic to handle the USB requests), you may set DISCON to 1 here.

If you have an FX2-LP (like me), you can also use -t fx2lp since this will not make a difference here (except for the default PID).

Since version ww3, you can also program arbitrary VID:PID combinations into the EEPROM. These will be used if the firmware instructs the FX2 hardware to answer USB requests: Option -d 04B4:1234 will flash a vendor ID of 04B4 (Cypress) and a product ID of 1234 into the EEPROM.

Now, unplug the device and re-plug it. In the syslog, you should now see that the newly connected FX2 enumerates as Sierra wireless modem:

usb 8-5: reset high speed USB device using ehci_hcd and address 44
usb 8-5.2: new high speed USB device using ehci_hcd and address 52
usb 8-5.2: New USB device found, idVendor=1199, idProduct=0017
usb 8-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 8-5.2: Product: FX2 case converter
usb 8-5.2: Manufacturer: WieserLabs & freesoft.org
usb 8-5.2: configuration #1 chosen from 1 choice
sierra 8-5.2:1.0: Sierra USB modem converter detected
usb 8-5.2: Sierra USB modem converter now attached to ttyUSB0

Basically, that's it. Now, if you want to update the firmware, you have to go the same way. The only difference: In the lsusb output, look for the Sierra wireless device and not for an unconfigured FX2.

Sometimes, you might want to erase the EEPROM so that the FX2 comes up as virgin unconfigured FX2 again.

Unfortunately, fxload cannot do this out of the box but my patched version (download link above) can erase the EEPROM and thereby also mark it as un-bootable. The current version will simply overwrite the first 8kb of data with 0xff in the EEPROM. This erases a complete 24LC64 type EEPROM chip. See ezusb_erase_eeprom in ezusb.c in the fxload source code.

This is how you do it: The patched version of fxload has the additional option -E to erase the EEPROM:

fxload -D /proc/bus/usb/008/049 -E -s Vend_Ax.hex -t fx2lp -v

(Of course, you need lsusb to find out the correct address instead of /proc/bus/usb/008/049 as explained above.) After that, re-connect the FX2 board and it should come up as unconfigured FX2 again.

Basically, a bricked FX2 board is one which does no longer connect to the USB when attached. In the syslog this can be seen in either no response at all or just a "connect" message without the idVendor and idProduct being listed. Anyway, it's called "bricked" because the board behaves like a worthless brick and you can no longer communicate with it. The three main reasons are:

• The firmware is not handling USB (config) requests and hence does not enumerate at the host computer because -either- RENUM is set to 0 and the VID,PID codes in the EEPROM are invalid -or- RENUM is set to 1 and the firmware does not handle USB requests.
• The DISCON bit is set in the EEPROM config byte and the firmware is defective and/or not enabling the USB.
• The firmware is disabling the USB (DISCON=1) and not enabling it again.

Technical side note: If syslog stays quiet, then the FX2 is DISCONnected. If the syslog reports "connect" but no VID,PID, the FX2 is connected but not handling USB requests.

Since the USB is not connected, you need to have access to the hardware to get the device going again. Of course, replacing the EEPROM will do the trick. Here's how to do it without replacing the EEPROM.

The basic idea is to make the FX2 not read the EEPROM when powering up. I tried connecting SDA or SCL to GND or positive supply without success. Disconnecting pin 5 of the EEPROM (SDA line) will make the FX2 come up as unconfigured device. This can be done rather easily even with an EEPROM in an SO-8 SMD package.

So, my procedure to un-brick an USB-FX2 board is as follows:

1. Unplug the FX2 from the USB.
2. Disconnect the pin 5 (SDA) from the EEPROM, e.g. by lifting the pin somewhat (with soldering iron).
3. Plug in the FX2. It should register as unconfigured FX2 as usual.
4. When plugged in, connect the SDA pin again. The syslog should stay quiet.
5. Use erase_eeprom from the advanced software examples page to erase the EEPROM. This will overwrite the whole EEPROM with 0xff:

   cycfx2prog prg:erase_eeprom.ihx run

   NOTE: This takes about 30 seconds to complete! (First, unload the usbtest module, of course!) You can check activity on the SDA line with an oscilloscope if you like.
6. Re-plug the FX2. It should now register as unconfigured FX2 with EEPROM attached. Device successfully un-bricked.

According to my experiments, using fxload -E (my patched version) instead of erase_eeprom to erase the EEPROM does not work. My theory is that the Cypress-supplied Vend_Ax.hex second stage bootloader interpretes the register bits I2CS.ID1,0 which reflect the presence of an EEPROM at power up (when SDA it is not yet connected according to the procedure above).

Do you know a better method to un-brick the FX2 board? If so, then let me know!

Here are some troubleshooting tips. Also check out the main troubleshooting page.

• Make sure that the usbtest kernel module is not loaded.
• If, after programming, the new firmware does not seem to work, re-plug the device again (and allow enough time for a power-off reset of the FX2).
• If you get the error record too short? from fxload, you are probably using an outdated version of fxload. I had this when using fxload from the Debian repository. Use the version available here or a newer one. Use an explicit path (ala ./fxload) to call the program.
• Always check the kernel messages (syslog).
• If you have bricked the device (no more response when plugging in the USB), see the un-brick chapter above.