OMAP-L138 I2C - spike on SCL

Hi Denis,

                I want to know I2C Bus Frequency?

                 If you reduce the I2C Bus frequency then what will happening? You can also try with reduce the Pull up Resistance value.

                1. When the spike visible every time of data transfer ?

                2. During Initialization of I2C is it happens?

                3. Distance of the device from Microcontroller.

                5. Is it possible to remove One by one I2C Device for a time?

Regards

Abhijit

Hi Abhijit,

The spike occures at every 0 to 1 transition at  I2C bus frequencies 400kHz and 100kHz.

The oscillogram above was captured in the following board configuration (a part of multiboard device):

Two TLV320AIC34 codecs are disconnected by bus switches (SN74CB3T3306).

BR,
  Denis

Hello Denis,

                       I think there is problem with load capacitance or electrical wiring in I2C connectivity.

                        1. For the time being Remove maximum no of I2c device.

                        2. Reduce clock speed as minimam as possible . Is it giving same spike with 400KHz & 100KHz. 

                        3.  Can you provide the list of Connected I2C device.

                        4. Try with Decrease Pull Up resistance value (< 1.5k)

                       5. Can send the details Circuit diagram of I2C units with I2C devices?

Regards

Abhijit

Hi Abhijit,

Yes, there's the same spike with 400KHz & 100KHz.

Devices connected to I2C are:

  - OMAPL138AZWT (I2C0 master)

  - MAX7500 temperature sensor (connected to SCL through 5.1k resistor)

  - TAS5504 digital audio PWM processor

  - 2 x TLV320AIC34 audio codecs (connected to SCL through CB3T3306 bus switch; switched off during measurements)

The circuit diagram including all currently installed components (Hyperlynx model) is given in my previous post.

The load capacitance value estimated via pull-up resistor value and SCL slew rate is about 40pF.

The scope probe was connected near TAS5504 SCL pin (cell E4 at the diagram)

Addition of 56pF capacitor reduces the spike and following oscillations about a half but doesn't remove them.

I'll try to disconnect devices and to change the pull-up resistance later.

BR,
   Denis

The oscillograms below were captured at the previous board revision that have the same schematic but different layout and stackup (note the different timescale).

1) The initial schematic (L138 + MAX7500 + CB3T3306(off) + TLV320AIC34(thru CB3T3306) + TAS5504), Rpullup=2.2k

.

2) All slaves are disconnected, there's only OMAP-L138 with 2.2k pullup

 3) The same as 2 (OMAP only) but Rpullup = 510 Ohm

4) OMAP-L138 without external pullup (only internal pullup is active)

Obviosly the spike parameters have no dependence on the pullup value. It seems like the top transistor of open-drain output turns on momentary at the SCL low-to-high transition.

Upd1:  Disabling the internal pullup at I2C0 in OMAP doesn't affect on the spike

Upd2: The currently available version of OMAP-L138 IBIS file doesn't include the open-drain output model. How could it be correctly modelled?

Hi all,

has anybody else observed the similar spike on the same or other TI processor models and/or chip revisions? It looks like the (undesirable) feature of the I2C module or output buffer.

Any comments on this from TI employees?

Hi Dennis

I observe at similar situation to the one you report. Did you ever find out the reason for this behavior?

So far my conclusion is similar to yours, that the SCK line is actively driven for a very brief moment.

One of the devices connected on my board is sensitive; the others are not. 22pF across the pull-up seems to solve the problem; but I'm not very happy with that solution...

Comments anyone?

Best regards,

Anders

Hi Anders,

In that particular case I have had to change the I²C bus structure in the final board release replacing or removing all of potentially sensitive devices off the bus.

Unfortunately that's not the only case when TI support leaves a problem unresolved - there's no confirmation of the phenomenon even...

BR,
   Denis

Hi all,

I've just found this issue has been recognized and corrected an year ago at least on AM335x - see Advisory 1.0.26 "I2C: SDA and SCL Open-Drain Output Buffer Issue" in AM335x Silicon Errata.

Background story:

I2C1_SCL strange signal  (AM3359)

AM3352 unreliable I2C operation

In addition to AM335x and OMAP-L138, at least OMAP3530 seems affected also (and again not corrected yet...)
PCA9517 - Extra Spike on I2C

I suppose this issue must be reflected in errata even if TI doesn't plan to correct it.

Question №1 for TI: what silicon revisions of OMAP-L138 are affected?

Question №2 for TI: what processor families (at least of AM1808, C6748, C6745, OMAP-L137) are potentially affected also?

BR,
   Denis