4 Replies Latest reply on Sep 17, 2020 12:47 PM by KyTr_1955226

    PSoC5LP: What could cause master I2C slow rise times?

    KyTr_1955226

      Hello,

       

      I have a question regarding how the PSoC5LP handles I2C.  I'm using the PSoC as an I2C master for a TW8844 video processor.  I'm finding that I'm occasionally running into communications issues.  Issues like sometimes the bitmaps for the font OSD not downloading correctly, or being corruped.  I think I've traced this to the I2C.

       

      I am running the I2C component at 400kHz (350kHz - 375kHz in practice), and I'm finding the rise time of the I2C signals to be a little bit slow.  For reference, the TW8846 has a max "Rise Time" spec of 120ns.  When I take a look at the I2C signals on the scope, I find that I am failing this requirement.  On a 2us/div timescale you can see the rise time is not great:

       

      Zoomed in to 120ns/div, you can see the 120ns rise time spec is not met.  It takes a little over 120ns to reach the 2V input high threshold of the I2C Slave, and over double that time to hit 3.3V VDD:

       

       

      Using a different MCU (SI Labs C8051F) on the same I2C bus (disconnecting the PSoC from the bus) produces much quicker rise times, so the issue doesn't appear to be with the conditions of the bus itself, but specifically with the PSoC.  The pull-up resistors are 1k on SDA and SCL, so they are plenty strong enough for 400kHz.

       

      The I2C pins are configured for Open-Drain Drive Low, Slew Rate Fast, Drive Level VDDIO, 4mA Source/8mS Sink, and Transparent Output mode.

       

      Might anyone know why I'm seeing these rise times, and if it's fixable through configuration of the Pin or I2C components (or elsewhere)?

       

      Thanks in advance for the help!

        • 1. Re: PSoC5LP: What could cause master I2C slow rise times?
          StWa_1982846

          KyTr,

          Rise time on the I2C bus is controlled by only two things: 1) The pullup resistance R, and 2) the capacitance C on the bus. The upward curve you see on the trace is a classic exponential defined by e^(t/RC). R * C is the time constant, t is time, e is the engineering constant ~2.718. To reduce the rise time, you have to reduce either R or C. You can easily reduce R by swapping out your pullups, at the expense of extra current required by switching, and only as far as the bus drivers can effectively pull down the bus (see the device spec for current drive on the I2C pins). Your fast fall times suggest the drivers can easily handle somewhat reduced R pullups. C is harder to reduce but also reduces power - doing this means shortening your bus traces and/or removing any unused loads (like your scope probes ).

          On the other hand, your trace looks very clean. I believe the I2C receiver latches data on only the rising/falling phase of clock, while data transitions occur only on the opposite phase (falling/rising). That means there is (1/2 clock period - t rise/fall) for the data to settle. You did not show traces for both clock and data, so I can't tell where the problem is, but I would look for jitter or some rare event on the clock or data line which shortens the time between clock edge and data transition. You can use the advanced triggering on your scope to trap such an event.

          SW

          1 of 1 people found this helpful
          • 2. Re: PSoC5LP: What could cause master I2C slow rise times?
            DaBl_4548126

            StWa is correct, lacking some fancy circuit to improve the rise time (maybe your other MCU has this?) rise time on I2C is purely an RC charge curve. Your waveform, with a 1k pullup, tells me that you have about 150pF of total capacitance on this bus. Look at the data sheets for the pin capacitance on each IC, it should be in the 10 to 20 pF range. Also look at what the maximum sink current is for each IC. You state that you are using 8mA sink current on the PSoC, if the TW8844 is the same, you can reduce the pullup to 420 ohms. 100pF of trace capacitance seems really high, though. How long are those traces?

            You will also have to check the scope probe capacitance, it could be as low as 2pF or as high as 50pF, you will have to confirm what it is. If it is higher than about 20pF, you are probably meeting the rise time spec without the probe on there.

            But I agree with StWa, rise time is unlikely to be your problem. (I have seen I2C run with some really sloppy rise times.) Look at the phase relationship between data and clock (at both ends of the bus) and look for noise on both lines. If your scope has triggering capability for runt pulses or noise, use that. Otherwise use infinite persistence mode and look for issues.

            As I'm sure you know, things that work right MOST of the time can be the hardest to troubleshoot. Also look for excessive noise on your power rails (measured at each IC, you DID follow all bypassing recommendations, didn't you?), and general clock quality, and so on. Make sure that any PLL filters are correct, and properly laid out. Look over your artwork for anything stupid, especially with regard to analog effects such as power delivery and such. You didn't run the I2C traces over plane splits, did you? Or under a switching regulator? Question everything.

            1 of 1 people found this helpful
            • 3. Re: PSoC5LP: What could cause master I2C slow rise times?
              KyTr_1955226

              Thanks for the replies,

               

              We're looking into capacitance on the line.  This was the first thing that occurred to us, but the fact that we can put another MCU on the bus and get much quicker rise times sort of dispelled the notion of it being a bus capacitance issue.  We were thinking maybe the PSoC itself was putting additional capacitance on the line somehow.

               

              Going over how this is all connected again, we have a few things we can do to try and reduce the capacitance.  The traces for I2C on the PCB itself are quite short and routed "responsibly".  We did find more to consider, however:

              The PSoC is connected to this bus over an external connection.  This connection to the PCB is outfitted with ESD diodes and 100 Ohm series resistors.  it was mostly meant for general purpose IO from the PSoC, but we are trying to use them to act as I2C lines.  From the datasheet I can see the ESD diodes are 20pF on their own.  The TW8846 input is 5pF.  The probe we are using for the scope is 1M and 15pF (I think less since we are using a ground spring rather than a long ground probe?).  We also have the aforementioned C8051 on this bus.  This C8051 is no longer active in this design (being held in reset), so I can't imagine it is responsible for more than maybe 20pF on the line at worst.  We actually cut the traces to it on our prototype engineering PCB, and showed no difference in the rise time.

               

              Even with these considerations, the calculated capacitance appears to be much higher than the 50pF or so accrued by the components above.  We shortened the cable connecting the PSoC to the PCB by about half and saw no difference, so the cable itself is likely not the culprit.  We will see if we can remove the ESD diodes on SDA and SCL to see if that has any effect (should at least remove 20pF).

               

              Thanks again for the input!

              • 4. Re: PSoC5LP: What could cause master I2C slow rise times?
                KyTr_1955226

                As soon as I finish writing up my last post we got the ESD diode removed and it immediately solved the problem.  I was looking at the wrong datasheet for the ESD diode (same P/N, different manufacturer).  The one I was originally referencing said 20pF.  The ACTUAL datasheet for our part lists OVER 100pF(!!!) at Vr == 3.3V (and higher, the closer you are to 0V):

                 

                Removed the ESD diode, rise time is MUCH faster and now well within the spec.

                 

                Appreciate the tips, I will remember them next time I'm doing I2C debugging.