TXE# is an output. You must not pull it low.I can't find how to put the TXE# pin low
Not sure from which side you are seeing this.TXE# is an output. You must not pull it low.
I have nothing in my buffer, i can see that by calling FT_GetStatus or FT_GetQueueStatus.--> read the data on the PC side to empty the buffers.
Your headline talks about FTDI and I don´t know nothing about your FPGA, therefore I can only talk for the FTDI.Not sure from which side you are seeing this.
My fault. I meant "WR#" lineI have no WE# line?
Sure, my bad.Your headline talks about FTDI and I don´t know nothing about your FPGA, therefore I can only talk for the FTDI.
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.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)
WR# is actually waiting for TXE# to be low...My fault. I meant "WR#" line
Do you have some documents to learn more about the way you proceeded ?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)
Completely wrong!If we see it as an ouput, i have to pull it low somehow right ?
TXE# is an output. You must not pull it low.
I hope you used one of the software tools provided on the ftdichip.com internet sites.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.
!! This has nothing to do with 245 sync mode !!SetFlowControl with FT_FLOW_RTS_CTS (added after seeing some post on the internet seeing not to do it could lead to some errors...)
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.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...
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).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.
<?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>
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.
I just tested it and I do have my 60MHz clock.Did you verify the 60MHz clock?
Please show us your FT2232H init code.
FT_STATUS ftStatus;
DWORD numDevs;
FT_HANDLE curentDeviceHandle;
UCHAR Mask = 0xff;
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,¤tDeviceHandle);
[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
ftStatus =[COLOR="#0000CD"] FT_SetBitMode[/COLOR](currentDeviceHandle, Mask, 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
ftStatus = [COLOR="#0000CD"]FT_SetBitMode[/COLOR](currentDeviceHandle, Mask, 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");
}
* Without putting anything in buffers, TXE# is still high.* (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
3V3.I little hardware test of the TXE-line on the PCB:
* measure VCC_IO of the FTDI --> 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.* 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.
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?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.
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 still have 3V3 with a 1k5 (don't have any 1K at the moment) resistor pull down, short circuit it is ?* 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'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.!! This has nothing to do with 245 sync mode !!
Flow control is for serial communication only.
yes, at least until buffers are full.- Am I right in thinking the TXE# signal should go low once the ft2232h configured, not matter what is on the fpga part?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?