cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

mahac_4159481
New Contributor

Hello, I am working with the FX3 Superspeed Explorer kit. I was working on modifying the AN75779 application note to work with the OV5640 from Omnivision. Everything was working fine and then suddenly I2C stopped working, without me making any changes to the I2C functionality. Are there any known issues with the I2C component of the FX3 device that could cause it to stop generating any clock or data? I checked the voltage test points and the resistors and nothing appears to have gone wrong at either of those points. Nothing looks visibly damaged on the board either. Even with the stock AN75779 firmware with no modifications the device doesn't even attempt to send an I2C command.

I'd appreciate any help in additionally trying to debug why the FX3 will no longer generate any sort of I2C. Other signals I have it generating do function correctly and as expected (RESET and XCLK which are both on CTL pins remapped to simple and complex IO)

0 Likes
1 Solution
Hemanth
Moderator
Moderator

Hi,

If the Slave did not respond from the start that is when the preamble (with Slave address) is sent, then you may get CY_U3P_ERROR_TIMEOUT.

If the transfer is going on and the SDA has gone low when it should not/in case of clock stretching, then you are likely to get CY_U3P_ERROR_LOST_ARBITRATION.

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
8 Replies
Hemanth
Moderator
Moderator

Hi,

There are no known issues related to your description. Is it a custom board that you are using? Or is it Super speed Explorer kit? You can load the I2C example in the path - "C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\serialif_examples\cyfxusbi2cregmode" and send the vendor command which accesses the I2C bus. While you send the vendor command, you may have to probe I2C lines to see whether you see any activity. You can also try - changing the PMODE pins to I2C Boot and on power-up see for the activity on I2C lines.

Regards,

Hemanth

Hemanth
0 Likes
jogrc_1107386
New Contributor

Hello Hemanth,

We have seen a different I2C issue, which also involves the FX3 not driving clock or data and wanted to see if you could shed any light on this.

On very rare occasions, when calling function CyU3PI2cReceiveBytes, we receive a CY_U3P_ERROR_TIMEOUT status, however we do not see any activity on the I2C bus.  Our retryCount parameter is set to 128.  As a test, we have seen retry operations take place if our I2C slave device is purposely not setup to respond to a read operation.

Our assumption being that if an CY_U3P_ERROR_TIMEOUT  were being reported properly, we should see some retry operations occur automatically, but instead we see nothing.  Our work around is to simply call CyU3PI2cReciveBytes again when we see a timeout error, and this second try always works fine.  This is effective as a patch, but we are trying to get a better understanding of the initial failure.

Can you think of a situation where a timeout would be reported by CyU3PI2cReciveBytes, yet we would not see any I2C bus activity? 

0 Likes
Hemanth
Moderator
Moderator

Hi,

In your design, is there a chance for any other I2C device getting hold of the I2C Bus?

If the I2C bus is Busy/ FX3 I2C Block is busy transferring some data already, then there is a chance of issuing CY_U3P_ERROR_TIMEOUT error.

When FX3 is not generating clock or data (after calling ReceiveBytes API) what is state of Clock and Data lines. Is any one pulled low?

Does the situation of  not generating clock/data - happen after the I2C Slave address and the register address is sent? Or does it happen after certain amount of data is read (This can be seen by taking I2C trace)

Regards,

Hemanth

Hemanth
0 Likes
jogrc_1107386
New Contributor

Thank you for your thoughts on our I2C related issue.  We have seen a short glitch of the data line going low when one of our I2C slave devices is starting up.  This takes place at around the same time when the FX3 is trying to do an I2C read.  You mentioned that something like this could potentially cause a TIMEOUT error.  In such a case, could the FX3 declare this timeout without attempting any retry operations?  This is what we are seeing, so we are trying to determine if the data line glitch has caused the FX3 to abort the read (returns TIMEOUT) without doing any of the 128 retry operations it is setup for.

The condition that takes place 99% of the time is that the FX3 read operation will start, but will abort this after zero, or a few clocks.  In which case a retry operation takes place right away, and our system recovers properly.  Therefore, what we are trying to understand is the 1% case where no retries are attempted. 

0 Likes
Hemanth
Moderator
Moderator

Hi,

Yes, there is a possibility to declare timeout even before starting the actual read operation. It can happen even before retries occur.

When CyU3PI2cReciveBytes() API is called, before even sending out the preamble, I2C bus is checked if it is busy. If busy, then TIME_OUT can be seen.

Please refer to MyI2cSendCommand() call in CyU3PI2cReciveBytes() in cyu3i2c.c file of FX3 SDK Source.

FYI:

Cypress\EZ-USB FX3 SDK\1.3\firmware\fx3_sdk_1_3_4_src\sdk\firmware\src\lpp\cyu3i2c.c

Regards,

Hemanth

Hemanth
0 Likes
jogrc_1107386
New Contributor

Hi Hemanth,

Your response was very useful in helping us to understand the conditions we have seen.  The source files you pointed to clearly show how this can happen.  One thing that isn't clear to us, is how we would know if retries had taken place if we receive the TIMEOUT status.  It seems possible to get this status in either instance, first where the bus is busy, or where our device is not responding.  In the former case we would want to retry the entire operation because our device was never addressed.  In the latter case we would like to immediately declare a fault state, since our slave device is not responding properly.  Is there a way to know which event had taken place on the I2C bus?

0 Likes
Hemanth
Moderator
Moderator

Hi,

If the Slave did not respond from the start that is when the preamble (with Slave address) is sent, then you may get CY_U3P_ERROR_TIMEOUT.

If the transfer is going on and the SDA has gone low when it should not/in case of clock stretching, then you are likely to get CY_U3P_ERROR_LOST_ARBITRATION.

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
mahac_4159481
New Contributor

We are not currently using a custom board as we are in the development phase. When I would load the firmware in to the FX3 I would see the reset line assert low and then release as well as the XCLK PWM output being functioning correctly, however the I2C CLK line would end up held low and there would the device were never attempt to send an address + R/W bit to communicate with the image sensor. There is no other I2C device on the bus at this time. I am not quite sure what the issue is at the moment, I may try connecting the image sensor to a known working Arduino board to see if it can communicate with the image sensor to rule out the image sensor being damaged.

0 Likes