1. Home
  2. Field-Programmable Gate Arrays
  3. I2C "SCL" line problem

I2C "SCL" line problem

Hi all,

I faced the following problem with my I2C slave code(VHDL).

I was incrementing a counter on the negative edge of SCL(this clock is coming from the processor's I2C port , 100 KHz frequency). But what i observed on the CRO was that my bit counter which was running on the "negative edge" of SCL , was incrementing on "positive edge" also and this was not happening always.

The solution to this problem was i inverted the incomimg clock "SCL" and used the rising edge to increment my counter now it was fine.

Can any I2C experts clarify what is the problem with working on "negative edge of "SCL" clock.

Regards, Prav

Reply to
praveen.kantharajapura
Loading thread data ...

I2C is an open-collector bus with a resistor pullup. So the falling edge is sharp and the rising edge is exponential.

I would guess that the rising edge is too slow and is causing problems for your input buffer at the input threshold.

Alan Nishioka

snipped-for-privacy@gmail.com wrote:

Reply to
alan

schrieb im Newsbeitrag news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

Yes, you should use the schmitt trigger option for the input (if it is a coolrunner-II) I2C is terribly slow for nowadays CPLDs, so a rising edge can (and WILL) have enough noise on it to make the CPLD see double edges. I also suggest to NOT use SCL directly as a clock (for the given reason). Use a "high speed" (lets say 10 MHz) clock to sample SDA/SCL and make your state machine rung on this 10 MHz clock using the samples SDA/SCL.

Regards Falk

Reply to
Falk Brunner

Well, the I2C interface has those funny START and STOP conditions relating to data changing while on the clock is high state. Are you aware of that and could that influence your circuit?

Brad Smallridge b r a d @ a i v i s i o n . c o m

Reply to
Brad Smallridge

Hi Falk,

We cannot go for the Scmitt trigger option , because the PCB's are already out.Could any thing be done to avoid flase triggering in FPGA's only.

Regards, Prav

Falk Brunner wrote:

Reply to
praveen.kantharajapura

Falk mentioned using a higher frequency clock ( if you have one in the FPGA already) and running a state engine.

Other solutions are to lower the SCL pullup resistor, and so raise the dV/dT.

You can also create delay line elements in the FPGA, and create a SET-RESET latch: effectively a low pass system, so that rapid clocking is not legal.

-jg

Reply to
Jim Granville

specifically, a separate "glitch filter" may be what the state engine needs. The I2C calls for glitch handling of specific sizes in different modes. It's pretty easy to delay the edge long enough to make sure the transition isn't a glitch at or below the specified size and still capture the data well within the setup/hold time.

The glitch handling is really a must for I2C.

Reply to
John_H

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.