1
Discussion - Software / LibMPSSE-I2C : FT2232H is not sending ACK
« on: June 07, 2019, 08:47:10 am »
Hello,
I'm trying to use LibMPSSE-I2C to communicate between an FT2232H (in a FTDI Click board) and MCP23017 and MCP3426.
Almost everything runs fine, including opening the channels and writing, but I have some issue with the I2C_DeviceRead function : it doesn't seem to send ACK after every byte the device sends. It's not an issue with the MCP23017 as the device sends only one byte at a time, but with the MCP3426 it's more problematic : the device sends back 3 bytes, but because it doesn't receive an ACK from the FT2232H after the first byte, it just stops the transfer.
Here's what it looks like under the oscilloscope :
I numbered the bits. Every nine bits, I've written an 'X' where either the FT2232H or the device is supposed to ACK. The first 'X' is correctly ACKed by the device, but the second 'X' is not ACKed by the FT2232H, causing the MCP3426 to stop the transfer. In the end, I get the first byte (which I assume is correct), but the two remaining bytes ends up being 0xFF which is incorrect.
Here's the DeviceRead I tried:
Neither of them makes the FT2232H ACK.
Any idea where the problem could be ? Is it even a software problem ? On the hardware level, both SDA and SCL are pulled-up to the 3.3V (actually more like 3V but eh) with 4.7K resistors.
Thanks a lot !
I'm trying to use LibMPSSE-I2C to communicate between an FT2232H (in a FTDI Click board) and MCP23017 and MCP3426.
Almost everything runs fine, including opening the channels and writing, but I have some issue with the I2C_DeviceRead function : it doesn't seem to send ACK after every byte the device sends. It's not an issue with the MCP23017 as the device sends only one byte at a time, but with the MCP3426 it's more problematic : the device sends back 3 bytes, but because it doesn't receive an ACK from the FT2232H after the first byte, it just stops the transfer.
Here's what it looks like under the oscilloscope :
I numbered the bits. Every nine bits, I've written an 'X' where either the FT2232H or the device is supposed to ACK. The first 'X' is correctly ACKed by the device, but the second 'X' is not ACKed by the FT2232H, causing the MCP3426 to stop the transfer. In the end, I get the first byte (which I assume is correct), but the two remaining bytes ends up being 0xFF which is incorrect.
Here's the DeviceRead I tried:
Code: [Select]
int err = I2C_DeviceWrite(i2cChannel->handle, address, size, payload, byte_transfered, I2C_TRANSFER_OPTIONS_START_BIT | I2C_TRANSFER_OPTIONS_STOP_BIT | I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES);
Code: [Select]
int err = I2C_DeviceWrite(i2cChannel->handle, address, size, payload, byte_transfered, I2C_TRANSFER_OPTIONS_START_BIT | I2C_TRANSFER_OPTIONS_STOP_BIT);
Code: [Select]
int err = I2C_DeviceWrite(i2cChannel->handle, address, size, payload, byte_transfered, I2C_TRANSFER_OPTIONS_START_BIT | I2C_TRANSFER_OPTIONS_STOP_BIT | I2C_TRANSFER_OPTIONS_NACK_LAST_BYTE);
Neither of them makes the FT2232H ACK.
Any idea where the problem could be ? Is it even a software problem ? On the hardware level, both SDA and SCL are pulled-up to the 3.3V (actually more like 3V but eh) with 4.7K resistors.
Thanks a lot !