Not getting acknowledgement on I2C2 of DM814x processor

Hello Sunil,

Please check these:

dm8168 i2c-2 error but i2c-1 is ok

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/194420.aspx

I2C2 bus conflict with HDVICP F/W?

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/164435/598903.aspx

I think it is explained there.

You could try to search the forum for more info.

Thank you very much.

BR

Vladimir

Dear Vladimir,

Thanks for your reply. As per the links you have shared, the issue we are facing is because of HDVICP settings, But we have already disabled HDVICP and we are using I2C pin-muxs for I2C2 line.

We are connecting our I2C2 lines on VOUT[1]_G_Y_YC[2]/GPMC_A[13]/VIN[1]A_D[21]/HDMI_SCL/SPI[2]_SCS[2]n/I2C[2]_SCL/GP3[20] --> AF27 and

 VOUT[1]_R_CR[3]/GPMC_A[14]/VIN[1]A_D[22]/HDMI_SDA/SPI[2]_SCLK/I2C[2]_SDA/GP3[21] --> AG28   pins of DM814x. In our firmware we are detecting I2C2 lines as I2C3 lines.

We have checked by connecting temperature sensor IC TCN75AVUA on these I2C2 (For firmware I2C3) lines. The same IC is working on I2C-0 (For firmware I2C1) lines (pins AC4 and AB6 of DM814x processor) .

Can you help us on this case?

Dear Vladimir,

The  I2C being talked about is the 3rd I2C instance on DM8148. Is this known to work ? Could not see any errata on this?

Best Regards

Feroz

Can you try adding i2c_bus=3,400 in bootargs? This will ensure i2c2 is configured at 400 KHz

After this boot and run 'i2cdetect -l' command on console it should show i2c-3 instance.

Dear Sunil,

Can you please try the diagnotics at 

http://www.mistralsolutions.com/pes-support/support-downloads/tmdxevm8148.html?phpMyAdmin=01ab13889148490e8d23c7ff6925ee04

to rule our hardware issues?

Thanks and Best Regards

Feroz

Hi,

We have found that in “arch/arm/mach-omap2/i2c.c” file of DVRRDK Scl and Sda of I2C3 are pin muxed as mux0,

please find relevant code below,

if (cpu_is_ti814x() && bus_id == 3) { sprintf(mux_name, "uart0_dcdn.i2c2_scl_mux0"); omap_mux_init_signal(mux_name, OMAP_PIN_INPUT); sprintf(mux_name, "uart0_dsrn.i2c2_sda_mux0"); omap_mux_init_signal(mux_name, OMAP_PIN_INPUT); } else { sprintf(mux_name, "i2c%i_scl.i2c%i_scl", bus_id, bus_id); omap_mux_init_signal(mux_name, OMAP_PIN_INPUT); sprintf(mux_name, "i2c%i_sda.i2c%i_sda", bus_id, bus_id); omap_mux_init_signal(mux_name, OMAP_PIN_INPUT); }

We found that I2C2 is working as MUX0 on lines

UART0_DSRn/UART3_TXD/SPI[0]_SCS[2]n/I2C[2]_SDA/SD1_SDWP/GP1[3] --> AG4

UART0_DCDn/UART3_RXD/SPI[0]_SCS[3]n/I2C[2]_SCL/SD1_POW/GP1[2] --> AH4

Can we configured Scl and Sda of I2C3 as mux2 or have to use the same as mux0 only?

Team,

FYI more inputs here below

Best Regards

Frooz

Can you help answer a few questions:

1)      For the provided waveforms, is this the address phase, or the data phase of an I2C transaction?

1. If it’s the data phase, can you show the previous activity on the bus that would correspond to the address phase?
2. If it’s the data phase, is it a read or a write?

[Feroz] It is only one byte written and  9^th bit is NACK and there the SCL stops as I2C2 seemingly fails to respond.

 Priyesh : Waveform taken is for address phase only. Whenever we are getting NACK, We dont see any further activity from processor. So only address phase we can capture.

2)      The signal looks much worse on picture #2 for the NACK scenario.  Is this measurement problems, or is the signal really that noisy?  I2C in general is sensitive to noise/glitches, especially those that look like clocks.  It’s interesting that on the final “glitch” of the SDA signal, the SDA signal is driven low immediately after what looks like significant noise on the SCL signal.

[Feroz] picture #2 is the waveform of the problem I2C 2. Picture #1 was a correct expected waveform with I2C 0

 Priyesh : "Glitch" is coming on I2C2 in always. We have tried to give regulated supply to this IC but still "Glitch" is coming. Mitesh Patel is aware about this situation.

3)      I don’t think there is any issue/workaround for the pin muxing that can be extracted from the driver code. 

1. It looks like the “hack” for I2C2 is due to I2C not being the primary function for that signal (i.e., not the ball name).
2. Whereas for I2C0 and I2C1, they are the primary signal/ball name, so that a C macro can be used instead of the hard coded names.

[Feroz] I hope that is true. Not sure why the code force is needed

Priyesh : Can you confirm this?

4)      Is it possible for them to use I2C0 or I2C1 via a board modification.

1. I2C0/1 uses I2C buffer type, which have much slower edge rates, and is more immune to noise/glitches on the bus.
2. I2C2/3 use LVCMOS buffers which have faster edge rates, and are more sensitive to noise/glitches on the bus.

 [Feroz] Not an option at present as board is to be delivered soon.

                 Priyesh : This design is "first time right design". We dont see any further revision for this hardware.

Hi,

We spent lots of efforts debugging this issue both from hardware and software front, but found nothing positive. We decided to check if pins MUXED as I2C2_SCL_MUX2 and I2C2_SDA_MUX2 are working as GPIO based I2C or not.

 We integrated, GPIO based I2C driver and added support for the same in kernel, and with this, I2C2_Mux2 works perfect. We are surprised that why GPIO based I2C driver works fine with I2C device on same hardware, and I2C as peripheral does not!

Our question is;

1. Is I2C2_Mux2 used by some EVM or another 814X based hardware?

2. What could be the reason for I2C2_MUX2 working fine as GPIO based I2C, but not working as I2C peripheral?

Regards,

Dharati Shah

Hi Dharati,

Assume this GPIO based I2C is run on the same physcial pins as I2c 2 - Mux2....

Please see inputs on what could be wrong here. Key aspect would be ti know if the same behavior/waveform is seen on TI EVM. Then our TI team can replicate this easily.

As mentioned in #2 … the I2C protocol in general is sensitive to glitches on the CLK (or data).  It seems that both signals are very noisy.  Is there a reason for the noise?  That may be the source of the problem. 

Can they try increasing the low time and high time for the I2C signaling via the SCLL and SCLH values?   This will change the point in time that the I2C module samples the signals, and may shift the timing to reduce the sensitivity to any noise that may be present.

Best Regards

Feroz

Further inputs from Kyle:

Feroz>>It seems the same pins work when GPIO based I2C protocol are run. That should rule out a board hardware issue isn’t it?

Kyle>> Not necessarily … the timing will be different for a GPIO based implementation.

Best REgards

Feroz

As of now, GPIO based I2C driver is sufficient for product requirement. So we are moving ahead with that only. 

Thanks a lot for extended support and answers.

Regards,

Dharati