AM62A7: I2C bus timeout issue

Hello Jay,

Does the same camera work reliably on the AM62A SK EVM?

Thanks,

Jianzhong

Hi Jianzhong,

We have observed same issue on the EVM as well when we were integrating and testing the camera sensor with EVM.

Regards,

Jay

Jay,

You camera board may have some issues with I2C design. Let me loop in our I2C expert to help.

Regards,

Jianzhong

Hello Jay,

Collecting more information

What camera are you using?

Is there anything else on that I2C bus?

It looks like the bus is currently set to 400kHz. Do you have the option to reduce clock speed to 100kHz and see if that changes any behavior?

Analyzing the Saleae waveform capture 

Can you tell us a bit more about what exactly you are capturing on the Saleae waveform?

It looks like this data capture is about 400 seconds long. Starting at 34 seconds I see a start command, which looks the way I would expect:

And then the waveform you pointed out is around 396 seconds, about 40 seconds after the last I2C communication:

Just to confirm, we know for sure that the last waveform at the 396 second mark is associated with the "controller timed out" message?

With the caveat that I do not have a ton of experience looking at I2C waveforms, 4 milliseconds is a very long time for the start condition. Looks like it is about 2usec for a "good" cases elsewhere in the waveform. I am not sure how to interpret that output with the information currently provided.

This is where the kernel driver is throwing that timeout error if you're interested in adding debug statements:

drivers/i2c/busses$ vi i2c-omap.c

/*
 * Low level master read/write transaction.
 */
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
                 struct i2c_msg *msg, int stop, bool polling)
{
...
    /*
     * REVISIT: We should abort the transfer on signals, but the bus goes
     * into arbitration and we're currently unable to recover from it.
     */
    if (!polling) {
        timeout = wait_for_completion_timeout(&omap->cmd_complete,
                              OMAP_I2C_TIMEOUT);
    } else {
        do {
            omap_i2c_wait(omap);
            ret = omap_i2c_xfer_data(omap);
        } while (ret == -EAGAIN);

        timeout = !ret;
    }

    if (timeout == 0) {
        dev_err(omap->dev, "controller timed out\n");
        omap_i2c_reset(omap);
        __omap_i2c_init(omap);
        return -ETIMEDOUT;
    }

But the OMAP_I2C_TIMEOUT value is set to 1 second by default, so I am not sure how that would relate to a 4 millisecond pulse on the SDA without any clock pulses (assuming no other I2C masters on the bus).

Regards,

Nick

Hi Nick, 

Thank you for your response.

Nick Saulnier said:

Just to confirm, we know for sure that the last waveform at the 396 second mark is associated with the "controller timed out" message?

Yes, you are correct. Last pulse is associated with "controller timeout" message. 

Nick Saulnier said:

Do you have the option to reduce clock speed to 100kHz and see if that changes any behavior?

Sure. we will try this as well.

Nick Saulnier said:

(assuming no other I2C masters on the bus)

Correct. There is only one master (AM62A7 processor).

Yes, as you see in the last pulse, SDA line is pulled low, but SCL line is not getting low and Due to this, I2C START condition did not happen. So, what could be the reason that master is not able to pull SCL line low after pulling the SDA line low? Could this happen if the slave is not ready yet? Or there could be any other reason? Let us know if there could be other reason, So, we can debug on other possibilities.

Regards,

Jay 

Hello Jay, 

Did you share the I2C interface related schematics.

Do you have the required pullups. I assume you have read the I2C exception and added a series resistor to control the fall time.

Regards,

Sreenivasa

Hi Sreenivasa,

Please find the schematics screenshots of I2C interface and waveforms of fall and rise time. 

Kallikuppa Sreenivasa said:

Do you have the required pullups

Yes, we have used the required pull-ups.

Kallikuppa Sreenivasa said:

I assume you have read the I2C exception and added a series resistor to control the fall time.

We are not aware about this. Can you provide document in reference to this?

IMG_SENSOR_DET.pdf

Regards,

Jay

Hello Jay, 

Please refer below section of the data sheet.

7.10.5.12 I2C

– Exceptions:
• The IOs associated with these ports are not compliant to the fall time requirements defined in the I2C
specification because they are implemented with higher performance LVCMOS push-pull IOs that were
designed to support other signal functions that could not be implemented with I2C compatible IOs. The
LVCMOS IOs being used on these ports are connected such they emulate open-drain outputs. This
emulation is achieved by forcing a constant low output and disabling the output buffer to enter the Hi-Z
state.
• The I2C specification defines a maximum input voltage VIH of (VDDmax + 0.5 V), which exceeds the
absolute maximum ratings for the device IOs. The system must be designed to ensure the I2C signals
never exceed the limits defined in the Absolute Maximum Ratings section of this datasheet.

Regards,

Sreenivasa

Hi Sreenivasa, 

Thank you for sharing this.

I guess i found the reason for the timeout issue. It is the void message. Due to this,  controller is locked-up and provides the timeout error. I found below from TRM of processor.

When I observed the Saleae waveform again, I found the void message condition when i2c got timeout error at last waveform at the 396th second. This image is from the Saleae log shared before.

Can expert suggest how can we prevent the void message on I2C bus?

Regards,

Jay

Hello Jay, 

Thank you for the inputs.

Jay Kaneria said:

Can expert suggest how can we prevent the void message on I2C bus?

Could you please start a new thread with the updated title to be assigned to the right expert.

Regards,

Sreenivasa

Hello Jay,
There is one more thing I would like you to verify from the hardware side: can you confirm that the void message is in fact coming from the AM62Ax, and not something else on the I2C bus?

I would expect that test to look like placing a resistor in series with the SDA line, and measuring the voltage on each side of the resistor. Which side of the resistor starts changing voltage first?

Hello Sreenivasa,

Do you have any additional inputs on how Jay might set up the above test? e.g., any suggestions for resistor settings?

Regards,

Nick

 Hey Sreenivasa,

Can I get you to comment on Jay's followup question from here?

"There is one more thing I would like you to verify from the hardware side: can you confirm that the void message is in fact coming from the AM62Ax, and not something else on the I2C bus?

I would expect that test to look like placing a resistor in series with the SDA line, and measuring the voltage on each side of the resistor. Which side of the resistor starts changing voltage first?"

Could you please provide resistor value and some schematic diagram where we have to measure the data? Also, please let us know if anything else needed to be measured. Our hardware team wants to verify this again. 

Thanks,

Nick