cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

BrSc_4720546
New Contributor

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.

0 Likes
1 Solution
Rashi_Vatsa
Moderator
Moderator

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.

Regards,
Rashi

View solution in original post

0 Likes
7 Replies
Rashi_Vatsa
Moderator
Moderator

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  

Regards,
Rashi
0 Likes
BrSc_4720546
New Contributor

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

 

0 Likes
Rashi_Vatsa
Moderator
Moderator

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.

Regards,
Rashi
0 Likes
BrSc_4720546
New Contributor

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;

    }

 

0 Likes
Rashi_Vatsa
Moderator
Moderator

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.

Regards,
Rashi

View solution in original post

0 Likes
BrSc_4720546
New Contributor

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?

0 Likes
Rashi_Vatsa
Moderator
Moderator

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. 

Regards,
Rashi