FTDI Community

General Category => Discussion - Software => Topic started by: SebastianM on July 10, 2019, 02:16:36 PM

Title: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on July 10, 2019, 02:16:36 PM
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
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community 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://ftp.ftdichip.com/CES/LibMPSSE/libMPSSE__0_6_Beta.zip (ftp://u45902898-ide:Ftd1$erv@ftp.ftdichip.com/CES/LibMPSSE/libMPSSE__0_6_Beta.zip)

The source is available at the following:
ftp://ftp.ftdichip.com/CES/LibMPSSE/0.6Plus_Beta_Source.zip (ftp://u45902898-ide:Ftd1$erv@ftp.ftdichip.com/CES/LibMPSSE/0.6Plus_Beta_Source.zip)

Best Regards,
FTDI Community
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM 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
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community on July 23, 2019, 02:03:10 PM
Hello,

Is it still exhibiting the FT_IO_ERROR?

Best Regards,
FTDI Community
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on July 23, 2019, 02:55:11 PM
Yes status=4 (FT_IO_ERROR)
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community 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 (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
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on July 24, 2019, 07:28:05 AM
Hmm, we have not found any hardware issue.
Currently, we are using the UM232H development board, I guess it is designed according to AN_146_USB_Hardware_Design_Guidelines_for_FTDI_ICs.pdf?
With the Python module "pyftdi" the communication works without problems.
With the libMPSSE it does not work without problems even when slowing I2C down to 100kHz, adding delays and so on.
The signals look very good on an oscilloscope and the slave ACKs the byte that the FTDI IC does not handle properly but times out (libMPSSE times out after 5 seconds while trying to read one byte to get the status).
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community on July 24, 2019, 11:36:07 AM
Hello,

How have you connected the module to the host, is this through a hub (powered)?
Have you tried on any other Linux distros? Do you have a 32 bit machine you can try it on?

Best Regards,
FTDI Community
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on July 24, 2019, 02:53:23 PM
It is directly connected to a USB slot of the mainboard.
I have no 32-bit machine for test. I could set up a virtual machine.
What Linux distribution would you recommend?
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community on July 24, 2019, 03:32:48 PM
Hello,

Shouldn't be any hardware issues then as long as you are using an appropriately spec'd USB cable.

You could try a virtual machine to see if the issue persists, I usually run Ubuntu distros when testing things on VMs.

You could also try the code from AN_411, this does not use LibMPSSE (you would need to port it from C# back to the standard D2XX C definitions):
https://www.ftdichip.com/Support/Documents/AppNotes/AN_411_FTx232H%20MPSSE%20I2C%20Master%20Example%20in%20Csharp.pdf (https://www.ftdichip.com/Support/Documents/AppNotes/AN_411_FTx232H%20MPSSE%20I2C%20Master%20Example%20in%20Csharp.pdf)

Best Regards,
FTDI Community
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on July 29, 2019, 12:46:43 PM
I have tested it with a virtual 32-bit machine with Ubuntu 32 bit and it also does not work.
The behavior is the same as before (timeouts every second or third command that is sent).

Currently, I am testing the open-source libmpsse (https://github.com/l29ah/libmpsse).
At least simply writing one byte repeatedly to one slave address seems to work reliably compared to the FTDI libMPSSE.
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community on July 29, 2019, 04:03:10 PM
Hello,

If you can capture a USB analyser trace of the software executing and the FT_IO_Error happening we can investigate this occurrence further.

Best Regards,
BRT Community
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on August 01, 2019, 08:32:46 AM
Thanks for your help.
I tried to attach a USB trace file but the size limit of 128KB/192KB is a bit low. I don't get it smaller than about 224KB with a filtered trace packed into a .7z file.
Can you increase this limit or can I send it somewhere else?
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: FTDI Community on August 01, 2019, 09:51:54 AM
Hello,

You can email in to support1@ftdichip.com.
Please quote this thread.

Best Regards,
FTDI Community
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: SebastianM on August 01, 2019, 11:52:51 AM
Thanks, I have mailed the files.
Title: Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
Post by: derlinchow on September 08, 2020, 07:11:20 PM
Hi FTDI,

I have same problem using MPSSE-I2C (my PC is Ubuntu 16.04), I have to wait for 1s for 2nd write. Can you give me some assistance?

Thanks!

Derlin