46
Discussion - Drivers / Re: I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)
« on: August 30, 2019, 03:11:43 PM »
FTDI support suggests “FT4222_ChipReset”. I will investigate and report my findings.
- April 28, 2024, 02:58:18 PM
- 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.
47
Discussion - Drivers / Re: FT4222_I2CMaster_Write sizeTransferred returning 4 extra bytes.
« on: August 29, 2019, 02:39:21 PM »Which version of LibFT4222 are you using? Which version of the D2XX driver are you using?
The latest are v1.4.2 and 2.12.28 respectively (for Windows).
I am using the latest ZIP, downloaded recently:
LibFT4222-v1.4.2.zip
Quote
Which FT4222H IC revision are you using?
D
Quote
Have you tested out the I2C examples provided with LibFT4222?
I am currently using a modified example, yes.
When I use FT4222_I2CMaster_Write() and tell it to write 7 bytes, the value returns with 11. I've tested it with other numbers, and see it returns 4 higher than what I passed in. Here's a slightly edited snippet:
Code: [Select]
sizeTransferred = 0;
ft42Status = FT4222_I2CMaster_Write(FTDIHandle, slaveAddress, writeBuf, (ushort)sizeToWrite, &sizeTransferred);
Writing 7 bytes...
11 SENT: aa 00 06 00 02 4e ffAs you see, I clear sizeTransferred before I pass it in.
48
Discussion - Drivers / [Confirmed Bug] FT4222_I2CMaster_Write sizeTransferred returning 4 extra bytes.
« on: August 26, 2019, 10:56:01 PM »
Somewhere I read that FTDI added some header bytes that needed to be accounted for. I cannot find where I saw this, but maybe this is what I am seeing.
Per the App Note 329, I am using FT4222_I2CMaster_Write() and passing in a value of 8 for "bytesToWrite", and a zeroed out sizeTransferred before passing it in. "sizeTransferred" returns as 12 rather than the 8 I expected. (Verifying with a line analyzer shows the 8 bytes we went without extras.)
What are the extra 4 bytes?
Per the App Note 329, I am using FT4222_I2CMaster_Write() and passing in a value of 8 for "bytesToWrite", and a zeroed out sizeTransferred before passing it in. "sizeTransferred" returns as 12 rather than the 8 I expected. (Verifying with a line analyzer shows the 8 bytes we went without extras.)
What are the extra 4 bytes?
49
Discussion - Drivers / I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)
« on: August 26, 2019, 02:39:12 PM »
How can the I2C "bus clear" be done using the Windows API? See 3.1.16 in the I2C specification:
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
This is needed for situations when the i2c hangs or has a lockup. I find many examples of how to do this on ST, Arduino, Raspberry Pi, etc. and want to replicate that on FTDI Windows code.
Thanks for any pointers.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Quote
3.1.16 Bus clear
In the unlikely event where the clock (SCL) is stuck LOW, the preferential procedure is to
reset the bus using the HW reset signal if your I2C devices have HW reset inputs. If the
I2C devices do not have HW reset inputs, cycle power to the devices to activate the
mandatory internal Power-On Reset (POR) circuit.
If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device
that held the bus LOW should release it sometime within those nine clocks. If not, then
use the HW reset or cycle power to clear the bus.
This is needed for situations when the i2c hangs or has a lockup. I find many examples of how to do this on ST, Arduino, Raspberry Pi, etc. and want to replicate that on FTDI Windows code.
Thanks for any pointers.