- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am trying to read from a Mfi chip through i2c using the FX3 SuperSpeed Explorer Kit. The transaction fails. I attached a scope capture showing a read of the mfi chip internal address 0x03. It looks like the chip is setting a short nak after the chip address (0x20). The FX3 i2c peripheral does not seem to care and the nak duration seems to be too short.
Do you have sample code that successfully reads or writes to a mfi chip?
Thanks.
Solved! Go to Solution.
- Labels:
-
USB Superspeed Peripherals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Apologies on missing out on that information.
Thank you for confirming that I2C is used in register mode. Please confirm if the CyU3PI2cReceiveBytes/CyU3PI2cTransmitBytes API fails with error code 0x4a - CY_U3P_ERROR_FAILURE (i.e. When a transfer fails with an error defined in CyU3PI2cError_t). If yes, you can try calling CyU3PI2cGetErrorCode in the error handler of CyU3PI2cReceiveBytes/CyU3PI2cTransmitBytes API check if CyU3PI2cGetErrorCode returns CY_U3P_I2C_ERROR_NAK_BYTE_1. If yes, the preamble can be sent again with a delay.
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
From the trace shared, the ACK from the slave arrives late. FX3 will sample the SDA (data) on the rising edge of the I2C clock.
Please check if the I2C connection between the FX3 and MFi chip is as per AN70707. Also, check if the I2C slave is compatible to the specifications supported by FX3 I2C master
Do you have sample code that successfully reads or writes to a mfi chip?
>>Please refer to similar thread Solved: MFi SDK for USB controllers like Fx3 - Cypress Developer Community
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thank you for your reply.
I checked the I2C connections following AN70707 and they are correct. The mfi coprocessor 3.0 has a few i2c constraints and I am not sure if the fx3 hardware can support it. Basically if the i2c slave responds with a nak at the second byte of the preample (the internal address), the fx3 needs to wait for 500us before reissuing the same preample. I have seen the repeat bit in the preample configuration but I cannot figure out how to make it wait for 500us. Would you have a solution?
Thanks again
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
It seems that you are using the I2C in register mode and using CyU3PI2cReceiveBytes/CyU3PI2cTransmitBytes API to read/write via I2C. Is my understanding correct?
For sending the preamble again when the NAK for the 2nd byte is seen, you can register the I2C callback function , put the retry count to 0 and when the error CY_U3P_I2C_ERROR_NAK_BYTE_1 (Slave NACK-ed the first byte (the numbering starts from 0th bytes) of the preamble) is triggered handler after a delay of 500 us try calling the API again to send the preamble again.
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
Thanks for this interesting solution. The I2C transfer is indeed used in register mode. I tried to register the I2C callback using the function CyU3PI2cSetConfig() but then it returns a BAD_ARGUMENT error. Looking at the code cyu3i2c.c, it seems that the callback is only valid in dma mode. Is there a workaround?
if ((!config->isDma) && (cb != NULL))
{
/* Callback is allowed only in DMA mode. */
return CY_U3P_ERROR_BAD_ARGUMENT;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Apologies on missing out on that information.
Thank you for confirming that I2C is used in register mode. Please confirm if the CyU3PI2cReceiveBytes/CyU3PI2cTransmitBytes API fails with error code 0x4a - CY_U3P_ERROR_FAILURE (i.e. When a transfer fails with an error defined in CyU3PI2cError_t). If yes, you can try calling CyU3PI2cGetErrorCode in the error handler of CyU3PI2cReceiveBytes/CyU3PI2cTransmitBytes API check if CyU3PI2cGetErrorCode returns CY_U3P_I2C_ERROR_NAK_BYTE_1. If yes, the preamble can be sent again with a delay.
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
Thanks, yes the returned error code is 0x4a, and I can see the i2c error. I used CyU3PBusyWait (500); to implement the delay. Could you confirm this is the proper way to do it?
The read now completes without error. For some unknown reason, the chip always reply with data=0x00 even for different register addresses, I believe it is an expected behavior but in case it is not, what else can I check from the I2C api to make sure the transaction was indeed successful?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thanks, yes the returned error code is 0x4a, and I can see the i2c error. I used CyU3PBusyWait (500); to implement the delay. Could you confirm this is the proper way to do it?
>> Yes, CyU3PBusyWait can be used for generating 500us delay.
what else can I check from the I2C api to make sure the transaction was indeed successful?
>> Please let me know if you probed the I2C signals to check if the I2C slave returns 0x00. This is to check if the data is received properly by the I2C master (FX3). Also, confirm if the API returns success.
Rashi