# FT2232H in Sync FIFO Mode - TXE# stuck high

Status
Not open for further replies.

#### AlexisB

##### Junior Member level 1
Hi,

I have a problem with the FT2232H programming trying to use the FIFO Mode.

I have a Morph-IC-II and I'm using D2XX drivers to speak with the FT2232H on board.

I manage to have the 60Mhz clock input (which is my main fpga clock) and I can transfer data from the PC to my FPGA with FT_Write(). The RXF# signal works fine (SignalTap used to check signals).

My main problem is : I can't find how to put the TXE# pin low and therefore be able to send data from my fpga to the pc.
I have no idea what I did wrong or what i forgot to make the ft2232h ready to receive data.

Alexis

#### KlausST

##### Super Moderator
Staff member
Hi,

I can't find how to put the TXE# pin low
TXE# is an output. You must not pull it low.

When TXE# is high, then it indicates that data is written to the PC but the PC did not fetch it. So all the buffers are full and no further data can be transmitted.
(on PC side you may read the receiver status.. how many bytes are in the FIFO... and so on)

--> read the data on the PC side to empty the buffers.
***

I assume your WE# line is continously low. Check it with a scope. Is this true? If so: don´t do this.

Are you sure you want "synchronous" mode, where the FTDI geneerates the timing?

Klaus

AlexisB

### AlexisB

Points: 2

#### AlexisB

##### Junior Member level 1
TXE# is an output. You must not pull it low.
Not sure from which side you are seeing this.
For me, TXE# is a ft2232h output, therefore an input for my fpga (to inform about the state of FIFO buffers).
That's why i think I'm somehow supposed to "prepare" things with my GUI/soft part (connected to the ft2232h).
Am I wrong ?

--> read the data on the PC side to empty the buffers.
I have nothing in my buffer, i can see that by calling FT_GetStatus or FT_GetQueueStatus.
That is why I don't understand the TXE# high and not low.
***

I have no WE# line?
***

I've taken this initial project to begin with:
https://www.ftdichip.com/Support/Do...5_FIFO_Communications_using_a_Morph-IC-II.pdf
https://www.ftdichip.com/Support/Do...2232H_Used_In_FT245 Synchronous FIFO Mode.pdf (for the SOFT part)
And removed the UM232H part and made some internal ram to access in my fpga.
My first goal being to establish a high speed communication between my pc and my fpga via usb (read/write in a ram).

Many thanks for you help, I'm kind of new to this whole thing.

Alexis

Last edited:

#### KlausST

##### Super Moderator
Staff member
Hi,

Not sure from which side you are seeing this.

****
Only channelA can be set ot the "245 sync mode" (Channelb cannot be configured to be a "245 sync interface". Did you properly program your FTDI chip?
(Maybe the Channel A is not configured, or wrong configured)

****
With the FT2232H you have 2 interfaces. Are you sure you acces the correct interface (to empty it and to read it´s satus)

****
I have no WE# line?
My fault. I meant "WR#" line

****
We used the FT2232H similar than you. FPGA (Spartan6) to PC high speed data communcation. But with async 245 interface, so the FPGA controls the timing. (we achieved about 20MBytes/s if I remember right)
The other channel we used for low speed communication with a uC.

Klaus

### MalathiT

Points: 2

#### AlexisB

##### Junior Member level 1
Hi,

If we see it as an ouput, i have to pull it low somehow right ?

Only channelA can be set ot the "245 sync mode" (Channelb cannot be configured to be a "245 sync interface". Did you properly program your FTDI chip?
(Maybe the Channel A is not configured, or wrong configured)

****
With the FT2232H you have 2 interfaces. Are you sure you acces the correct interface (to empty it and to read it´s satus)
I've followed the datasheet to program my ft2232h EEPROM with FIFO mode etc and I'm sure I'm on channel A to use this 245 sync mode.

My channel A might be wrongly configured but I can't see what I've missed...
Here are my actions:
-> Open device
-> Reset device
-> Purge buffers
-> SetBitMode 0x00 (reset mode)
-> SetBitMode 0x40 (sync fifo mode)
-> SetLatency at 2ms
-> SetUSBParameters : buffers at 64Bytes (initial test)
-> SetFlowControl with FT_FLOW_RTS_CTS (added after seeing some post on the internet seeing not to do it could lead to some errors...)
-> SetTimeOuts

My fault. I meant "WR#" line
WR# is actually waiting for TXE# to be low...
I've tried to force the fpga to write to the PC, putting WR# low and sending data, but it doesn't work this way.

We used the FT2232H similar than you. FPGA (Spartan6) to PC high speed data communcation. But with async 245 interface, so the FPGA controls the timing. (we achieved about 20MBytes/s if I remember right)

Alexis

#### KlausST

##### Super Moderator
Staff member
Hi,

If we see it as an ouput, i have to pull it low somehow right ?
Completely wrong!
As I said before:
TXE# is an output. You must not pull it low.

--> The only way to get it low is to create the situation that the FTDI chip itself pulls it low.
1) correct FTDI chip configuration
2) empty buffers
3) don´t know what else...

****************
I've followed the datasheet to program my ft2232h EEPROM with FIFO mode etc and I'm sure I'm on channel A to use this 245 sync mode.
I hope you used one of the software tools provided on the ftdichip.com internet sites.
-> then do a verify /readout of the contents and see how it is (really) configured.

***************
SetFlowControl with FT_FLOW_RTS_CTS (added after seeing some post on the internet seeing not to do it could lead to some errors...)
!! This has nothing to do with 245 sync mode !!
Flow control is for serial communication only.

Klaus

#### AlexisB

##### Junior Member level 1
Hi,

Completely wrong!
As I said before:

--> The only way to get it low is to create the situation that the FTDI chip itself pulls it low.
1) correct FTDI chip configuration
2) empty buffers
3) don´t know what else...
That's what I meant by pulling low "somehow", to make things right/ready for the device to pull it low (itself) when ft2232h is ready to receive data.
Sorry if I was inaccurate in my terms.

I haven't put anything yet in my receiving buffer.

I hope you used one of the software tools provided on the ftdichip.com internet sites.
-> then do a verify /readout of the contents and see how it is (really) configured.
I'm using FT_Prog and i'm doing exactly things described in AN_130 for MProg (which is an older version of FT_Prog if i understand well).

Alexis

- - - Updated - - -

Hi,

Here is my EEPROM configuration.
Attached is the same as below (txt format because I couldn't upload xml), for indentation.
Code:
<?xml version="1.0" encoding="utf-16"?>
<FT_EEPROM>
<Chip_Details>
<Type>[COLOR="#0000CD"]FT2232H[/COLOR]</Type>
</Chip_Details>
<USB_Device_Descriptor>
<VID_PID>[COLOR="#0000CD"]0[/COLOR]</VID_PID>
<idVendor>[COLOR="#0000CD"]0403[/COLOR]</idVendor>
<idProduct>[COLOR="#0000CD"]6010[/COLOR]</idProduct>
<bcdUSB>[COLOR="#0000CD"]USB 2.0[/COLOR]</bcdUSB>
</USB_Device_Descriptor>
<USB_Config_Descriptor>
<bmAttributes>
<RemoteWakeupEnabled>[COLOR="#0000CD"]false[/COLOR]</RemoteWakeupEnabled>
<SelfPowered>[COLOR="#0000CD"]false[/COLOR]</SelfPowered>
<BusPowered>[COLOR="#0000CD"]true[/COLOR]</BusPowered>
</bmAttributes>
<IOpullDown>[COLOR="#0000CD"]false[/COLOR]</IOpullDown>
<MaxPower>[COLOR="#0000CD"]90[/COLOR]</MaxPower>
</USB_Config_Descriptor>
<USB_String_Descriptors>
<Manufacturer>[COLOR="#0000CD"]FTDI[/COLOR]</Manufacturer>
<Product_Description>[COLOR="#0000CD"]USB <-> Serial Converter[/COLOR]</Product_Description>
<SerialNumber_Enabled>[COLOR="#0000CD"]true[/COLOR]</SerialNumber_Enabled>
<SerialNumber />
<SerialNumberPrefix>[COLOR="#0000CD"]FT[/COLOR]</SerialNumberPrefix>
<SerialNumber_AutoGenerate>[COLOR="#0000CD"]true[/COLOR]</SerialNumber_AutoGenerate>
</USB_String_Descriptors>
<Hardware_Specific>
<Suspend_DBUS7>[COLOR="#0000CD"]false[/COLOR]</Suspend_DBUS7>
<TPRDRV>[COLOR="#0000CD"]0[/COLOR]</TPRDRV>
<Port_A>
<Hardware>
<UART>[COLOR="#0000CD"]false[/COLOR]</UART>
<_245FIFO>[COLOR="#0000CD"]true[/COLOR]</_245FIFO>
<CPUFIFO>[COLOR="#0000CD"]false[/COLOR]</CPUFIFO>
<OPTO>[COLOR="#0000CD"]false[/COLOR]</OPTO>
</Hardware>
<Driver>
<VCP>[COLOR="#0000CD"]false[/COLOR]</VCP>
<D2XX>[COLOR="#0000CD"]true[/COLOR]</D2XX>
</Driver>
</Port_A>
<Port_B>
<Hardware>
<UART>[COLOR="#0000CD"]false[/COLOR]</UART>
<_245FIFO>[COLOR="#0000CD"]true[/COLOR]</_245FIFO>
<CPUFIFO>[COLOR="#0000CD"]false[/COLOR]</CPUFIFO>
<OPTO>[COLOR="#0000CD"]false[/COLOR]</OPTO>
</Hardware>
<Driver>
<VCP>[COLOR="#0000CD"]false[/COLOR]</VCP>
<D2XX>[COLOR="#0000CD"]true[/COLOR]</D2XX>
</Driver>
</Port_B>
<IO_Pins>
<Group_AL>
<SlowSlew>[COLOR="#0000CD"]false[/COLOR]</SlowSlew>
<Schmitt>[COLOR="#0000CD"]false[/COLOR]</Schmitt>
<Drive>[COLOR="#0000CD"]16mA[/COLOR]</Drive>
</Group_AL>
<Group_AH>
<SlowSlew>[COLOR="#0000CD"]false[/COLOR]</SlowSlew>
<Schmitt>[COLOR="#0000CD"]false[/COLOR]</Schmitt>
<Drive>[COLOR="#0000CD"]16mA[/COLOR]</Drive>
</Group_AH>
<Group_BL>
<SlowSlew>[COLOR="#0000CD"]false[/COLOR]</SlowSlew>
<Schmitt>[COLOR="#0000CD"]false[/COLOR]</Schmitt>
<Drive>[COLOR="#0000CD"]16mA[/COLOR]</Drive>
</Group_BL>
<Group_BH>
<SlowSlew>[COLOR="#0000CD"]false[/COLOR]</SlowSlew>
<Schmitt>[COLOR="#0000CD"]false[/COLOR]</Schmitt>
<Drive>[COLOR="#0000CD"]16mA[/COLOR]</Drive>
</Group_BH>
</IO_Pins>
</Hardware_Specific>
</FT_EEPROM>

#### Attachments

• fifo_FT2232H.txt
4.3 KB · Views: 5
Last edited by a moderator:

#### KlausST

##### Super Moderator
Staff member
Hi,

AN130 says:
When the FT2232H has been set to FT245 Synchronous FIFO mode, the CLKOUT pin will output 60MHz a clock. Observing this with an oscilloscope is a good check to make sure the interface has entered FT245 Synchronous FIFO mode. If the waveform edges do not appear sharp enough, then the drive strength of the IO can be increased by altering the EEPROM values using MPROG or FT_PROG.

Did you verify the 60MHz clock?

KLaus

#### AlexisB

##### Junior Member level 1
Hi,

Did you verify the 60MHz clock?
I just tested it and I do have my 60MHz clock.

I've made a little GUI with LabWindows, here is my FT2232H init code (without any GUI part):

####################

Code:
FT_STATUS ftStatus;
DWORD numDevs;
FT_HANDLE curentDeviceHandle;
UCHAR Mode;
UCHAR LatencyTimer = 2;
DWORD inTransferSize = 64;
DWORD outTransferSize = 64;

ftStatus =[COLOR="#0000CD"] FT_CreateDeviceInfoLis[/COLOR]t(&numDevs);
if (ftStatus == FT_OK) {
printf("Number of devices is %d\n",numDevs);
} else {
printf("FT_CreateDeviceInfoList failed !\n");
}

devInfo = (FT_DEVICE_LIST_INFO_NODE*)malloc(sizeof(FT_DEVICE_LIST_INFO_NODE)*numDevs);
ftStatus =[COLOR="#0000CD"] FT_GetDeviceInfoList[/COLOR](devInfo,&numDevs);
if (ftStatus == FT_OK) {
[COLOR="#A9A9A9"]////////
// some printf / check description and if channel A is open)
// channel A is my device number 0
////////[/COLOR]
} else {
printf("FT_GetDeviceInfoList failed !\n");
}

ftStatus = [COLOR="#0000CD"]FT_OpenEx[/COLOR](devInfo[0].Description,FT_OPEN_BY_DESCRIPTION,&currentDeviceHandle);
[COLOR="#A9A9A9"]// I do not hard code that 0 in my code, i chose it from my GUI to correspond with the channel A.[/COLOR]
if (ftStatus == FT_OK) {
printf("Device number %d with description %s is now open\n",iUSB,devInfo[iUSB].Description);

//ftStatus =[COLOR="#0000CD"] FT_ResetDevice[/COLOR](currentDeviceHandle);
if (ftStatus == FT_OK) {
printf("FT_ResetDevice done !\n");
} else {
printf("FT_ResetDevicel failed !\n");
}

ftStatus =[COLOR="#0000CD"] FT_Purge[/COLOR](currentDeviceHandle,FT_PURGE_RX | FT_PURGE_TX);
if (ftStatus == FT_OK) {
printf("FT_Purge done !\n");
} else {
printf("FT_Purge failed !\n");
}

Mode=0x00; //reset mode
if (ftStatus == FT_OK) {
printf("Device set to Reset Mode\n");
} else {
printf("FT_Set_BitMode Reset Failed !\n");
}
Sleep(10);
Mode=0x40; //Sync FIFO Mode
if (ftStatus == FT_OK) {
printf("Device set to Sync FIFO Mode\n");
} else {
printf("FT_Set_BitMode Sync FIFO Mode Failed !\n");
}

ftStatus = [COLOR="#0000CD"]FT_SetLatencyTimer[/COLOR](currentDeviceHandle, LatencyTimer);
if (ftStatus == FT_OK) {
printf("FT_SetLatencyTimer done !\n");
} else {
printf("FT_SetLatencyTimer failed !\n");
}

ftStatus = [COLOR="#0000CD"]FT_SetUSBParameters[/COLOR](currentDeviceHandle,inTransferSize,outTransferSize);
if (ftStatus == FT_OK) {
printf("FT_SetUSBParameters done !\n");
} else {
printf("FT_SetUSBParameters failed !\n");
}

ftStatus = [COLOR="#0000CD"]FT_SetTimeouts[/COLOR](currentDeviceHandle, 100,100);
if (ftStatus == FT_OK) {
printf("FT_SetTimeouts done !\n");
} else {
printf("FT_SetTimeouts failed\n");
}
####################

Alexis

Last edited by a moderator:

#### KlausST

##### Super Moderator
Staff member
Hi,

all seems to be correct.

even the 60Mhz clock is Ok.

What can it be?
* (still thinking about full buffers)
* bad solder joint at FTDI (supply, TXE-line...)
* bad solder joint at FPGA (supply, TXE-line...)
* short circuit somewhere on the PCB at the TXE-line
* wrong FPGA pin number, wrong FPGA pin setup, wrong FPGA programming

*****
I little hardware test of the TXE-line on the PCB:
* measure VCC_IO of the FTDI --> tell us the value
* measure TXE# line voltage (near the FPGA) --> tell us the value
* use an 1k resistor to GND and pull down the TXE# line. Measure the TXE voltage --> tell us the value.

Usually the TXE line voltage should be close to VCCIO.
With a loaded (1k pulldown) output the voltage should be a little less, but well above 2V.
If it still is very close to VCCIO, then I guess a short circuit to VCCIO. With a too low value I guess a bad solder joint or defective FTDI output..

Lets see what happens.

Klaus

AlexisB

### AlexisB

Points: 2

#### AlexisB

##### Junior Member level 1
Hi,

* (still thinking about full buffers)
* bad solder joint at FTDI (supply, TXE-line...)
* bad solder joint at FPGA (supply, TXE-line...)
* short circuit somewhere on the PCB at the TXE-line
* wrong FPGA pin number, wrong FPGA pin setup, wrong FPGA programming
* Without putting anything in buffers, TXE# is still high.
*** Am I that unlucky...
* I don't really see how this could come from the fpga programming, and i've done my pin set up with this datasheet for the ft2232h-fpga connection:
https://www.ftdichip.com/Support/Do...5_FIFO_Communications_using_a_Morph-IC-II.pdf

I little hardware test of the TXE-line on the PCB:
* measure VCC_IO of the FTDI --> tell us the value
3V3.

* measure TXE# line voltage (near the FPGA) --> tell us the value
* use an 1k resistor to GND and pull down the TXE# line. Measure the TXE voltage --> tell us the value.
How can I know where to test this ? I'm using the morph-IC-II and I'm not sure I can test anything between FT2232H and the fpga.

I've tested a few more things, and TXE# is low before setting the ft2232h to Sync FIFO Mode and goes high once it's set.

Alexis

- - - Updated - - -

How can I know where to test this ? I'm using the morph-IC-II and I'm not sure I can test anything between FT2232H and the fpga.
Can I know where it really is with the figure 14 - "A schematic of the USB interface" from Appendix C of Morph-IC-II datasheet?
https://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_Morph-IC-II.pdf

Alexis

#### KlausST

##### Super Moderator
Staff member
Hi,

How can I know where to test this ? I'm using the morph-IC-II and I'm not sure I can test anything between FT2232H and the fpga.

then use "J1-7".

Klaus

#### AlexisB

##### Junior Member level 1
Hi,

* measure TXE# line voltage (near the FPGA) --> tell us the value
* use an 1k resistor to GND and pull down the TXE# line. Measure the TXE voltage --> tell us the value.

Usually the TXE line voltage should be close to VCCIO.
With a loaded (1k pulldown) output the voltage should be a little less, but well above 2V.
If it still is very close to VCCIO, then I guess a short circuit to VCCIO. With a too low value I guess a bad solder joint or defective FTDI output..
I still have 3V3 with a 1k5 (don't have any 1K at the moment) resistor pull down, short circuit it is ?

Alexis

#### AlexisB

##### Junior Member level 1
Hi,

Not sure about what I did and I don't really understand the meaning of your conclusion about the manipulation with the pull-down resistor.
If it's from VCC it will stay to 3v3 put if it's a normal output pin, it should've been attenuated ?

I have tried on an other Morph-IC-II and I have exactly the same problem.
I guess we can conclude it's not a short circuit not a bad solder then...

The EEPROM seems right, the software too...
And the problem is before the fpga, I'm completely lost again.

If anybody has an idea or something to test?

Tank you again for your help.

Alexis

#### KlausST

##### Super Moderator
Staff member
Hi,

When a signal is accidentally shorted to VCC..
* and you measure without pulldown 3.30V
* then you will measure 3.30 V also with pulldown

But if it's a true logic output signal drven high, then
* you will see voltages 3.2 V ... 3.3V without pulldown
* and 2.7 ... 3.2 (it depends on drive strength of the IC) with pulldown
For a more precise estimation of the level one needs to check the datasheet.

Klaus

AlexisB

### AlexisB

Points: 2

#### AlexisB

##### Junior Member level 1
Hi,

Thanks for the explanation.

Given that I have the same problem on 2 Morph-IC-II, the problem can't come from a bad solder or a short circuit.
That's why I'm working again on the Software part and I have a few questions:

- At which point does the TXE# signal should go low, at which step of the configuration ?
Because mine goes high when Sync FIFO mode is set up and then never goes low.

- Am I right in thinking the TXE# signal should go low once the ft2232h configured, not matter what is on the fpga part?

- Is it useful to purge buffers before using them ? Is it just a security in case something would have been in the buffer before using it.
NB: doing it or not doesn't change anything regarding the TXE# signal.

- This also has probably nothing to do with my problem because this changes nothing, but you said this about FT_SetFlowControl in a previous post:
!! This has nothing to do with 245 sync mode !!
Flow control is for serial communication only.
I'm not sure to fully understand, this function being used in AN_130 : "FT_SetFlowControl(ftHandle, FT_FLOW_RTS_CTS, 0x0, 0x0);" in the "4.2 Getting The Best Performance" saying this configures the device driver to avoid data loss.

Alexis.

Last edited:

#### KlausST

##### Super Moderator
Staff member
Hi,

* FT_SetFlowControl:
Flow control is for serial communication only. But - yes - I´ve seen that they used it in AN_130.
"This is configures the device driver to avoid data loss."...whatever that means in the FIFO mode...

- Am I right in thinking the TXE# signal should go low once the ft2232h configured, not matter what is on the fpga part?
yes, at least until buffers are full.

*****
purge buffers...
Maybe worth a try. Additionally on channel B, maybe it makes a difference.

****
Channel B:
what´s connected to it? Cand there be a problem? Does it need to pullup/pulldown the pins before entering the sync fifo mode?

*****
To be honest.. it´s strange. Idon´t know what else to try...

Klaus

#### AlexisB

##### Junior Member level 1
Hi,

I used channel B to load a binary into my fpga, it used fifo mode (EEPROM set on 245 fifo in channal A and channel B).
After this, channel B is seen as closed.
If I open it, I can see there is nothing in buffers by using FT_GetStatus.
Purging those buffers doesn't change anything too.

***
I have something strange that I just discovered with this FT_GetStatus.
Here is what I tested : TxBuffer of 128 bytes of data that I write in the transmit buffer.
I can receive all of them in my fpga. This is ok.
But if I force the master to stop receiving data after 64 bytes, there should be 64 bytes still unread in the transmit buffer but I can't see those last 64 bytes when calling FT_GetStatus (TyBytes=0).

Not sure how to interpret this.

Alexis.

#### KlausST

##### Super Moderator
Staff member
Hi,

Mystic..

Do you use the latset drivers on your PC? Can you try other drivers or other operating system?
Is it a genuine FTDI chip?

Klaus

#### AlexisB

##### Junior Member level 1
Hi,

SOLVED :
I'm not using the "USB Remote WAkeUp" mode, and the master I had taken from the FTDI project of AN_165 was completely ignoring the pin SIWU.
At first sight, it seems quite ok and I didn't question it.
BUT, when unused, the SIWU pin has to receive '1'...

I'd like to THANK YOU KlausST for everything you've done to help me and for giving me a better understanding of my project.

Alexis.

Status
Not open for further replies.