Hi,
  I got the issue that the FT_ReadGPIO read all bit values as high(255) after setting up the initial value as low(0) for all bits.
 
  first, I set up the GPIO initial value as low and direction as input by FT_WriteGPIO(handle, 0, 0);
  then, I use the FT_ReadGPIO(&read_value), I always get 255 when the GPIOH has no connection.
  If I connect one of the GPIOH to the GND pin, the reading will change to low, it comes back high when removing the connection.

  Is it the expected behavior of the GPIO within LibMPSSE?

  My environment:
  LibMPSSE version: 1.0.5
  Device:232H
  OS: Windows
  Pin usage: SPI for GPIOL[0:3], GPIO for GPIOH[4]

Best Regards,
Tony

Hello,

Please confirm which version of the D2xx driver and LibFT4222 that you are using?

Are you using custom FT4222H hardware? Do you see the same issue with our UMFT4222EV-D?

Could the I2C slave be at fault rather than the FT4222H I2C master?

When this happens maybe you can perform a software reset rather than having to force quit or restart?
See FT4222_ChipReset API. You can also try these D2xx based APIs:

FT_Purge
FT_ResetDevice
FT_ResetPort
FT_Rescan
FT_Reload
FT_CyclePort

Best Regards,
FTDI Community

We have systems communication over I2C with a Windows machine acting as master. The system will chug along doing millions of messages over weeks or months just fine, or it may run for a few hours then get an FTDI error. When this happens, the program is usually locked up (spinny blue donut) and we have to force quit or restart Windows.

When that happens, I do not expect there is anything we can do about it.

But other times, we'll sometimes get back the error 1011 (failed to read device) error and not lock up, but all further I2C writes will be failing with errors.

Do we have any hope of finding a way to prevent this from happening?

Hello,

Unfortunately the LibFT4222 source code can't be shared as it's exposes secrets of our vendor class devices.

Please contact us via email on support1@ftdichip.com and we'll contact our R&D team to see if we can provide a 64 Bit (aarch64) build.

Best Regards,
FTDI Community

It is becoming more and more common to install a 64 Bit OS on a Raspberry. Libft4222 is available for ARMv8 32 Bit architecture, but not for 64 Bit (aarch64). When will you publish it or when will you publish the source code of LibFT4222 so that we can compile it on any architecture?

Thanks.

I have a custom made board and it has FTDI 2232H chip for serial data transfer. So to start with very basic steps, I assigned the usb data pins to LEDS to vies the output that I send over the serial communication port.

 

following is my very basic verilog code to check the working of USB,

The board has differential clock each working at 25MHZ. So the board is made to work at 50MHZ frequency as implemented in the following code,

module transfer(
input [7:0] usb_d,
input usb_rxfn, input usb_txen,
output usb_rdn, output usb_wr,
input CLK_IN_P,  input CLK_IN_N,  output reg [7:0] led);
   
wire CLK_IN;
 
IBUFDS IBUFDS_CLKIN (.I(CLK_IN_P), .IB(CLK_IN_N), .O(CLK_IN));
 wire clkin;
  assign clkin = CLK_IN;
 
 
reg [7:0]a;
 
always@(posedge clkin)
 
begin
 a[0]=usb_d[0] &1;
 a[1]=usb_d[1] &1;
 a[2]=usb_d[2] &1;
 a[3]=usb_d[3] &1;
 a[4]=usb_d[4] ^1;
 a[5]=usb_d[5] ^1;
 a[6]=usb_d[6] ^1;
 a[7]=usb_d[7] ^1;
 
 
 led[0]=a[0];
 led[1]=a[1];
 led[2]=a[2];
 led[3]=a[3];
 led[4]=a[4];
 led[5]=a[5];
 led[6]=a[6];
 led[7]=a[7];
 end
 
endmodule
Also, the thing I observed is, when the bit file is programmed, the leds[4] to leds[7] start blinking, which denotes that before even the values arrive from usb_d[4] to usb_d[7] the default values it assumes is '0'.

Following is the constraint file used

set_property IOSTANDARD LVCMOS33 [get_ports usb_rdn]
set_property IOSTANDARD LVDS_25 [get_ports CLK_IN_P]
set_property IOSTANDARD LVDS_25 [get_ports CLK_IN_N]
set_property IOSTANDARD LVCMOS33 [get_ports usb_wr]
set_property IOSTANDARD LVCMOS33 [get_ports usb_txen]
 
set_property IOSTANDARD LVCMOS33 [get_ports usb_rxfn]
set_property PACKAGE_PIN F1 [get_ports usb_rxfn]
set_property PACKAGE_PIN E1 [get_ports usb_rdn]
 
set_property PACKAGE_PIN E2 [get_ports usb_txen]
set_property PACKAGE_PIN D2 [get_ports usb_wr]
set_property PACKAGE_PIN E3 [get_ports CLK_IN_P]
 
create_clock -period 20.000 -name CLK_IN [get_ports CLK_IN_P];
 
set_property PACKAGE_PIN R12 [get_ports {led[7]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[7]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[5]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[6]}]
set_property PACKAGE_PIN T11 [get_ports {led[6]}]
set_property PACKAGE_PIN T9 [get_ports {led[5]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[4]}]
set_property PACKAGE_PIN U11 [get_ports {led[4]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[3]}]
set_property PACKAGE_PIN V11 [get_ports {led[3]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[2]}]
set_property PACKAGE_PIN V10 [get_ports {led[2]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[1]}]
set_property PACKAGE_PIN R10 [get_ports {led[1]}]
set_property IOSTANDARD LVCMOS33 [get_ports {led[0]}]
set_property PACKAGE_PIN T10 [get_ports {led[0]}]
set_property PACKAGE_PIN J3 [get_ports {usb_d[7]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[7]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[5]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[4]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[3]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[2]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[1]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[0]}]
set_property IOSTANDARD LVCMOS33 [get_ports {usb_d[6]}]
set_property PACKAGE_PIN H4 [get_ports {usb_d[6]}]
set_property PACKAGE_PIN G4 [get_ports {usb_d[5]}]
set_property PACKAGE_PIN G3 [get_ports {usb_d[4]}]
set_property PACKAGE_PIN H2 [get_ports {usb_d[3]}]
set_property PACKAGE_PIN H1 [get_ports {usb_d[2]}]
set_property PACKAGE_PIN G2 [get_ports {usb_d[1]}]
set_property PACKAGE_PIN G1 [get_ports {usb_d[0]}]
I used serial command to send data from matlab, following is my complete code in Matlab

s=serail('COM27');
fopen(s);
d=['01'];
d1=sscanf(d,'%d');
fwrite(s,d1,'uint8');
fclose(s);

Hello,

The extra bytes may be due to lack of biasing on the RS485 transceiver. If you could email into support1@ftdichip.com we can share the RS485 biasing schematic that will be able to help you.

Best Regards
FTDI Community 

Hi everyone,

I have a problem like I mention in title shortly. I designed a board to communicate between pc and a device which use RS485. I can communicate but every time receive a data it comes with a FE or FF byte as prefix. I'm using FT2232HQ with ADM3485EARZ-REEL7 on my board. Then I used USB-COM485-PLUS2 and I compared the waveform of the two converters. Even though the waveforms are same, I did not receive any extra byte while using USB-COM485-PLUS2. I wonder if I get schematic of COM485-PLUS2? Or does anyone have an idea about that situation?

Thank you.

Cristian

Hello,

Yes, there are internal pullups on the RXD lines of FT232R and FT232H.

the typical value is 75 KΩ. You can find more information in 5.3 of the FT232H datasheet.

Best Regards
FTDI Community