FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software  (Read 101 times)

versat

  • Newbie
  • *
  • Posts: 3
    • View Profile

Hi all,

I have issues with the FT232H software/drivers using it for I2C communication.
I simply want to write repeatedly one byte to one I2C device.

Using the I2C_DeviceWrite() function it works for one byte, then a timeout occurs, then it works
two times, then a timeout occurs and it goes on working two times and failing one time.
I have tried so many things but it all does not help.
Some things I have tried:
-Baudrate 100 kHz, 400 kHz
-Delay after each I2C_DeviceWrite() call from 1 ms up to 20 ms
-Recompiled the libMPSSE-I2C library against libftd2xx-x86_64-1.4.8
-Increased the delay from 1 to 5 ms before FT_Channel_Read() is called in I2C_Write8bitsAndGetAck()
-Enabled debugging in the libMPSSE-I2C => I saw that FT_Channel_Read() returns successfully but says 0 bytes transferred. That means it timed out waiting for an answer from the FTDI chip as far as I understand the sources. That is exactly what I observe (5 seconds default timeout until the program continues)
-Only reading repeatedly one byte from the device works
-Repeatedly writing and reading one byte does not work. It fails the same way as when writing one byte repeatedly.
-Verified the settings and used different latency timer values did not help anything
-Verified that Drive Only Zero mode is enabled (disabling it does not help)

Using the Python module pyftdi for I2C works perfectly fine (even at 400 kHz). So there seems to be no hardware issue.
Looking at the signals with an Oscilloscope shows that anything is fine. Edges are good, the timing looks good. ACK is sent from the device (even when the FTDI chip does not react to the FT_Channel_Read()).
We have written an application in Python using pyftdi that works well on the same system.
But I want to test if the performance using the FTDI C libraries is better. If someone has experience with the performance that would also be interesting.
For a new application, we would maybe use the D2XX library if the performance is really better.

I have already created a small program to read out the GPIO pins and observed issues there too.
The first four calls to FT_ReadGPIO return wrong/random values. Then the correct values are returned.
When calling FT_ReadGPIO() repeatedly forever it sometimes fails or returns random values.
I verified that the direction is correct. So there seem to be issues too.

Sure, there is a 3rd party open source python module, but it does not yet support GPIOs in I2C mode and the performance maybe could be better.

Device and system information:
FTDI device: FT232H
OS: Linux, Debian 9.9 (64 bit)
Driver: libftd2xx-x86_64-1.4.8
Lib: LibMPSSE-I2C Version 0.3 12-December-2011

Snippet from the debug output where the issue can be seen:
../../TopLayer/I2C/src/ftdi_i2c.c:434:I2C_DeviceWrite():Entering function
../../TopLayer/I2C/src/ftdi_i2c.c:447:I2C_DeviceWrite():handle=0x92936cd0 deviceAddress=0x58 sizeToTransfer=1 options=  0x3
../../MiddleLayer/src/ftdi_mid.c:714:Mid_PurgeDevice():Entering function
../../MiddleLayer/src/ftdi_mid.c:716:Mid_PurgeDevice():Exiting function status=0
../../TopLayer/I2C/src/ftdi_i2c.c:1646:I2C_Start():Entering function
../../MiddleLayer/src/ftdi_mid.c:580:FT_Channel_Write():Entering function
FT_Channel_Write called with noOfBytes=93
 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x3 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x1 0x13 0x80 0x0 0x13
../../MiddleLayer/src/ftdi_mid.c:627:FT_Channel_Write():Exiting function status=0
../../TopLayer/I2C/src/ftdi_i2c.c:1669:I2C_Start():Exiting function status=0
../../TopLayer/I2C/src/ftdi_i2c.c:1555:I2C_WriteDeviceAddress():Entering function
../../TopLayer/I2C/src/ftdi_i2c.c:1559:I2C_WriteDeviceAddress():7bit I2C address = 0x58
../../TopLayer/I2C/src/ftdi_i2c.c:1566:I2C_WriteDeviceAddress():7bit I2C address plus direction bit = 0xb0
../../TopLayer/I2C/src/ftdi_i2c.c:764:I2C_Write8bitsAndGetAck():Entering function
../../TopLayer/I2C/src/ftdi_i2c.c:765:I2C_Write8bitsAndGetAck():----------Writing byte 0xb0
../../MiddleLayer/src/ftdi_mid.c:580:FT_Channel_Write():Entering function
FT_Channel_Write called with noOfBytes=12
 0x80 0x2 0x13 0x13 0x7 0xb0 0x80 0x0 0x11 0x22 0x0 0x87
../../MiddleLayer/src/ftdi_mid.c:627:FT_Channel_Write():Exiting function status=0
../../TopLayer/I2C/src/ftdi_i2c.c:792:I2C_Write8bitsAndGetAck():FT_Channel_Write returned: noOfBytes=12,                noOfBytesTransferred=12
../../MiddleLayer/src/ftdi_mid.c:508:FT_Channel_Read():Entering function
FT_Channel_Read called with noOfBytes=1
 0x0
../../MiddleLayer/src/ftdi_mid.c:555:FT_Channel_Read():Exiting function status=0
../../TopLayer/I2C/src/ftdi_i2c.c:813:I2C_Write8bitsAndGetAck():FT_Channel_Read returned: noOfBytes=1,          noOfBytesTransferred=0
../../TopLayer/I2C/src/ftdi_i2c.c:819:I2C_Write8bitsAndGetAck():Requested to send 1 bytes, no. of bytes sent is 0                               bytes../../TopLayer/I2C/src/ftdi_i2c.c:830:I2C_Write8bitsAndGetAck():Exiting function status=4
../../Infra/src/ftdi_infra.c:97:Infra_DbgPrintStatus():Entering function
../../Infra/src/ftdi_infra.c:118:Infra_DbgPrintStatus():Status: FT_IO_ERROR
../../Infra/src/ftdi_infra.c:189:Infra_DbgPrintStatus():Exiting function status=4
../../TopLayer/I2C/src/ftdi_i2c.c:1581:I2C_WriteDeviceAddress():Exiting function status=4
../../TopLayer/I2C/src/ftdi_i2c.c:468:I2C_DeviceWrite(): status != FT_OK
../../Infra/src/ftdi_infra.c:97:Infra_DbgPrintStatus():Entering function
../../Infra/src/ftdi_infra.c:118:Infra_DbgPrintStatus():Status: FT_IO_ERROR
../../Infra/src/ftdi_infra.c:189:Infra_DbgPrintStatus():Exiting function status=4
Logged

FTDI Community

  • Administrator
  • Sr. Member
  • *****
  • Posts: 263
    • View Profile
Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« Reply #1 on: July 10, 2019, 03:41:46 PM »

Hello,

Can you give it a try with the latest version of the LibMPSSE library and let me know your results?

You can download it here:
ftp://u45902898-gavinmoore:ftd1$erv@ftp.ftdichip.com/CES/LibMPSSE/libMPSSE__0_6_Beta.zip

The source is available at the following:
ftp://u45902898-gavinmoore:ftd1$erv@ftp.ftdichip.com/CES/LibMPSSE/0.6Plus_Beta_Source.zip

Best Regards,
FTDI Community
Logged

versat

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« Reply #2 on: July 19, 2019, 02:19:12 PM »

Hello,

thanks for the Beta version, I tried it.
The results are the same as before.
I have even compiled it so it fits the 64-bit application and driver (only the x86 binary is included).
I am using the driver libftd2xx-x86_64-1.4.8.gz that is officially released, so I compiled libMPSSE against it.
Compiling against libftd2xx1.1.12 does not change anything too.
Any further ideas?

Best Regards
Logged

FTDI Community

  • Administrator
  • Sr. Member
  • *****
  • Posts: 263
    • View Profile
Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« Reply #3 on: July 23, 2019, 02:03:10 PM »

Hello,

Is it still exhibiting the FT_IO_ERROR?

Best Regards,
FTDI Community
Logged

versat

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« Reply #4 on: July 23, 2019, 02:55:11 PM »

Yes status=4 (FT_IO_ERROR)
Logged

FTDI Community

  • Administrator
  • Sr. Member
  • *****
  • Posts: 263
    • View Profile
Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« Reply #5 on: July 23, 2019, 03:10:49 PM »

Hello,

FT_IO_ERROR indicates that the driver has sent a message to the IC but there was no response from the IC. This is usually caused by hardware issues. We have some hardware guidelines at the following:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_146_USB_Hardware_Design_Guidelines_for_FTDI_ICs.pdf

Power configurations can be found in the ICs datasheet.

Best Regards,
FTDI Community
Logged