[OMAP-L138] I2C issue (spike on SCL)

Hello Denis,

Have you tried to implement the same workaround as mentioned in AM335x errata in your OMAPL138A custom board ?

Is there any improvement on SCL waveform ?

Regards,

Senthil

Hi Senthil,

I have not tried to implement this workaround yet. In current board revision only L138 has master capability on I2C bus, there is no slave devices supporting clock stretching and all slaves have glitch filters implemented in accordance with I2C specs. I intend to use some slaves that support clock stretching in a new product line currently in development, so that issue could be crucial.

BR,
   Denis

OMAPL138BZWT4 (rev 2.0) - I2C0 SCL:

OMAPL138BZWT4 (rev 2.1) - I2C0 SCL (another device):

Hi Denis

Will check with the AM335x team on the background of the I2C errata. The OMAPL1x is a different design, as far as i know different IO buffers etc.

A1. On OMAPL138 this was not a known/reported issue (unlike AM335x), so there has been no change in behavior between the various revs of OMAPL138/OMAPL132, C6748/46/42 and AM18x. I would expect the same behavior across revs.

A2. I will check on OMAPL137/AM17x/C6745/7 family. Same I2C module , slightly different IO buffers (no support for dual LVCMOS etc). 

Regards

Mukul 

The same signals captured by active probe with higher bandwidth:

Hi Mukul,

Mukul Bhatnagar said:

On OMAPL138 this was not a known/reported issue...

I had reported this "not known" issue more than 3 years ago.

I will check on OMAPL137/AM17x/C6745/7 family.

Any comments are still appreciated

BR,
   Denis

A new board design is in progress. What's about C6745?

Hi E2E community users,

would owners of OMAPL137/AM17x/C6745/7 based custom and/or reference boards check I2C0/1 SCL/SDA waveforms with scope and report them here (both normal and glitchy)? Scope/probe bandwidth of 400+ MHz  is preferred, but I suppose 200MHz  (or even 100MHz in some cases) should be enough to reveal possible anomalies.

I really appreciate any info you can provide.

   Denis

Hello Denis,

I have captured and attached the I2C0 SCL waveform at different timescale in DA830 (OMAPL137) SDI EVM. I do not see any reflections in low to high transition. 

5707.OMAPL137 I2C SCL.zip

Moreover, we are investigating the highlighted issue with OMAPL138 internally. We will get back once we get a conclusion.

Thanks for your patience.

Regards,

Senthil

Hello Senthil,

Thank you for the fast response.

Some further questions and comments to these screenshots:

1) Seems it is one of the TDS20x2 series scope. What is the bandwidth of model used - 50/75/100/200MHz?

2) What kind of probe have you used? Many probes have significantly reduced their bandwidth with 1X attenuation selected relatively to 10X (e.g. 6MHz vs. 200MHz for P2200 series)

3) Probe's ground lead should be as short as possible (spring-type ground connector is preferable)

4) Horizontal scale should be set to 50ns/div maximum (preferably 5...20ns/div), vertical - 0.5V/div, trigger level - around 0,5V

BR,
   Denis

_______________________________________

P.S.  Other users' results are still appreciated too.

Hello Denis,

Yes, I used TDS2022 scope and the bandwidth of the scope is 200MHz.

I used passive probe (TPP0201) with 200MHz bandwidth and attenuation of 10x.

I will try to capture the signal with the above scale and update you.

Regards,

Senthil

Hi FDM

Senthil has been driving a deeper investigation with design team. On further review with the design team preliminary understanding is that the OMAPL138 family (AM18x, c6748/46/42 included) and OMAPL137x family (AM17x, C6747/45/43, DA8x) is susceptible to this issue (even though apart from your post, i have not heard anyone else reporting this on these devices as yet)

The issue lies , with the way the IO buffer implementation is done (as described in the AM335x errata) 

The I2Cx_SDA and I2Cx_SCL outputs are implemented with push-pull 3-state output buffers rather than open-drain output buffers as required by I2C. While it is possible for the push-pull 3-state output buffers to behave as open-drain outputs, an internal timing skew issue causes the outputs to drive a logic-high for a duration of (0–5 ns) before the outputs are disabled. .....

the same way on these family of devices. 

Unfortunately I do not have a time line on when we can provide the series termination and pull up values etc. Need to investigate and scope this further internally and figure the corrective action to add to errata. 

Hope this helps some , even though this is work in progress discussion.

Regards

Mukul 

Hi Mukul,

Thank you very much for this valuable confirmation.
At first glance these resistors' values mentioned in the AM335x errata should be quite adequate also for OMAP-L13x family.
Would you also clarify whether this issue is applicable to I2C pins only or any other pin that supports open-drain mode is potentially vulnerable too?
In addition it might be of practical interest to know - at least qualitatively - how temperature and supply voltages (core and/or I/O) could affect that internal timing skew.

BR,
   Denis

Denis

Can you confirm that currently you are looking for this in context of C6745/OMAPL137 , not OMAPL138?

fdm said:

Would you also clarify whether this issue is applicable to I2C pins only or any other pin that supports open-drain mode is potentially vulnerable too?

My recollection is these are the only open drain mode pins (perhaps RESETOUT too) , I will need to audit further. 

fdm said:

In addition it might be of practical interest to know - at least qualitatively - how temperature and supply voltages (core and/or I/O) could affect that internal timing skew.

This will likely be tougher part as this requires some level of design simulations, that will likely not be easy to prioritize as this is an older device. I don't have a time line on this, but understand that it will be of practical interest for designers. 

Regards

Mukul 

Hello Denis,

At first glance these resistors' values mentioned in the AM335x errata should be quite adequate also for OMAP-L13x family.

At this point, we cannot say the resistor value mentioned in AM335x would be adequate for OMAP-L13x too. We need to perform IO simulation to figure out the right value and errata will be updated accordingly.

Would you also clarify whether this issue is applicable to I2C pins only or any other pin that supports open-drain mode is potentially vulnerable too?

Following with Mukul's statement, I also investigated the datasheet for other open drain pins. I do not see any other open drain pins. Are you seeing a concern for any other pin or you thought there are other open drain mode implementations etc ?

Regards,

Senthil

Mukul Bhatnagar said:

Can you confirm that currently you are looking for this in context of C6745/OMAPL137 , not OMAPL138?

Mukul Bhatnagar said:

My recollection is these are the only open drain mode pins (perhaps RESETOUT too)

SenthilKumar Srinivasan said:

At this point, we cannot say the resistor value mentioned in AM335x would be adequate for OMAP-L13x too.

Hi FDM

Please help me better understand the design schedules and volumes of the boards etc, to see whether we prioritize OMAPL138/AM18x or C6745 (different device families). Please feel free to route this through your field team, if this is not something you want to put on public forum. 

I confirm that SPI and MMC etc are not impacted, and this is limited to I2C. 

It would also be great if you had additional data points on the following ( I apologize if I missed in your previous E2E threads)

1) Have you actually been able to see the issue on c6745 or only saw it on OMAPL138

2) On OMAPL138, did you see this only on I2C0? Did you see the issue on I2C1?

Regards

Mukul 

Hi Mukul,

1) I have had no possibility to see this issue on C6745 based boards. All of them have I2C pins unrouted or used for other purposes.

2) On OMAP-L138 I saw this only on I2C0 since I2C1 was inaccessible for the same reason.

Taking into account the information provided in some recent posts now I'm trying to avoid using I2C slave device that supports clock stretching in C6745 based board currently in design. So at this moment  OMAP-L138 based boards scheduled for redesign are of higher priority.

Yet another question on this issue. May that timing skew cause an internal contention with shoot-through current inside the push-pull output buffer (even if there's no external connections)?

BR,
   Denis

Hi Denis

Thanks for the additional updates and clarifications. Will request Senthil to see if he is able to replicate this on OMAPl138/C6748 on his LCDK setup.

fdm said:

Yet another question on this issue. May that timing skew cause an internal contention with shoot-through current inside the push-pull output buffer (even if there's no external connections)?

Talked to the folks more knowledgeable about the IO buffers and the AM335x I2C issue, the response as follows

There is no shoot through or any other concerns internal to the IO if there is no external driver contending with the internal driver (during the duration when the open-drain buffer drives the output high while the external driver is driving low)

I wanted to add that I too have seen this issue on OMAPL138BZWT4 (rev 2.1).  See the attached scope captures of both SCL and SDA on I2C0.  In my system, there is a distributed network of I2C devices on this bus (8 in total spanning several inches of PCB board distance).  The waveform seen directly on the OMAP balls is where the issue is worst.  By the time the signals arrive at the other devices, the glitch is somewhat attenuated.  This data is captured on a 1GHz scope using 1GHz passive probes (3.9pF) with a 1/2" ground lead.

The negative pulse is what concerns me as it is nearly 0.8V below ground after the first reflection.  I expect I need to add the series resistors as discussed in the above posts.

See screen shots here:

Has there been any further work on this?  Or any further investigation?

Thanks,

David

Hello,

We are using OMAP-L138 and seeing I2C failures.

Below is the capture at once such failure - part of write transaction.

The glitch in the clock is anything to do with the ringing reported in the previous threads?

We are seeing glitches on SDA also. but mostly when the SCL is low.

Regards,

Srinivas.

Hi Senthil,

At the below link I have started new thread.

e2e.ti.com/.../505001

Regards,

Srinivas