Pt V2 FT2232H asynchronous FIFO mode

Has anyone been able to use the asynchronous FIFO mode for data transfer on the Pt V2 board? There are a few tutorials on the web that require modifying the EEPROM (link provided below), but still no luck. Linux OS also seems to ignore the EEPROM setting, which is also frustrating because it would be good to use with embedded systems. Thanks in advance for any info.

I think the issue lies in being able to program the EEPROM on for the FT2232H to enable 245 FIFO mode with the D2XX Driver on port B. Using the FT_Prog utility to do this seems to mess with the ability to have the board detected by Vivado.

As long as you don’t change anything but port B settings, Vivado should still be able to detect and program the board.

Thanks for your response. I think I have found the issue…

  1. Changing the board setting with FT_Prog utility to use async fifo d2xx driver wipes out the Xilinx special data to have it be accessed by hardware manager.
  2. Using Xilinx program_ftdi to enable access from Vivado sets port B into rs232 vcp driver.

The solution was to modify the Vivado program_ftdi script to configure the board with Port B in aync fifo mode using d2xx driver. All works now, even in Linux.

Is possible find somewhere original backup of the EEPROM in case it was damaged, please?

AFAIK all Au and Pt v2 boards are simply programmed using the xilinx’s program_ftdi so you just need to run it again if you mess up the EEPROM.

You just need to have the Product descriptor set to “Alchitry Au V2” or Alchitry Pt V2” for Labs to find it.

But if you want a backup, you can make one using FT Prog :

  1. Open FT Prog
  2. Plug you board
  3. Press F5 to detect it
  4. Press CTRL+S to save the current EEPROM as a template

To restore :

  1. Do 1 to 3 from above
  2. Press CTRL+O and select your backup
  3. Press CTRL+P to flash

If you press F5 before you change any settings, the current EEPROM data is retrived from the board so the Xilinx magic numbers should not be wiped.

The boards aren’t directly programmed with program_ftdi but the initial seed one was and then the config was read back so our custom flash/testing program could write it itself. Using program_ftdi is a good solution for restoring the original config.

Is someone actually needs the original config I’m happy to dig it up and post it.