1
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« on: August 01, 2019, 11:52:51 AM »
Thanks, I have mailed the files.
- April 18, 2024, 06:13:50 AM
- Welcome, Guest
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
Show Posts
You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.
Pages: [1]
2
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« 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?
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?
3
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« 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.
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.
4
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« 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?
I have no 32-bit machine for test. I could set up a virtual machine.
What Linux distribution would you recommend?
5
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« 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).
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).
6
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« on: July 23, 2019, 02:55:11 PM »
Yes status=4 (FT_IO_ERROR)
7
Discussion - Software / Re: FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« 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
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
8
Discussion - Software / FT232H for I2C via LibMPSSE: Issues using Linux drivers/software
« 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
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
Pages: [1]