Flex10K10A, I2C, MultiVolt IO, pull-ups

Dear experts,

We have a PIC MCU, an Altera Flex10k10 (EPF10K10ATC100-3) and a serial EEPROM connected to a I2C bus. The PIC and EEPROM are 5V devices, the FPGA is a 3,3V device with MultiVolt IOs. There is a I2C slave controller implemented in the FPGA that is definitely working correct. Our problem is that we are experiencing difficulties when writing from the PIC to the FPGA over I2C. The FPGA doesn't read the correct bytes (it reads 0xFFs). It didn't help to change the pull-ups from 400R to 1K, 4K7, 10K! Now, we realized that communication works if we connect 5,6V to the pull-ups instead 4,7V as we used before. Can somebody please explain why this solved our problem? Currently it is more a workaround than a solution since we don't know what exactly our problem is.

Thank you in advance.

Best regards, Markus

Reply to
Markus Fuchs
Loading thread data ...

I believe when you say "4,7V" you mean what we call 4.7 volts in the US, no? If so changing it to 5.6 volts should not make a difference if your power supplies are connected correctly. The FPGA should be using a threshold around 1.4 volts give or take 0.6 volts. So even 3.3 volts should work for all devices in the chain.

Have you taken any voltage measurements on the I2C signals? What values do you get with the two different pull up voltage?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

If the PIC is always the master, you could try making the SCL line always CMOS drive : In single master, only SDA needs to be open drain.

That will ensure faster clock edges - what you describe is a little counter-intuitive, esp as you say the resistor change had no effect, but sounds closest to edge-effects. FPGAs tend to be slow edge intolerant.

-jg

Reply to
Jim Granville

Damn, just gave myself away! English is not my native language, but you're right: I meant 4.7 volts.

Jim Granville wrote:

I already tried that without success.

Thank you Jim, that was it! I put a buffer between the PIC and the FPGA on the SCL line and now it works. So, what do you, Jim, Rick and all the other experts, recommend to get the edges on the I2C lines faster? There must be another solution for it, I guess, since buffers won't work on bidir lines.

Thank you! Markus

PS: Microchip says max. rise/fall time for the I2C lines are 300ns! :-(

Reply to
Markus Fuchs

My concern was not your english, but the odd voltage values. Typically there is a 5 volt supply on the board, but 4.7 and 5.6 volts are both not very standard in digital logic.

I can't say what I would recommend since I still don't understand what was wrong. Did you put a scope on the signals out of the PIC? If the FPGA was reading 0xFF it sounds to me like the PIC was not pulling the data signal down to ground. A buffer might cure that since the PIC would not be pulling on a stiff pullup (perhaps), but you said the buffer was on the clock line, right? Earlier you said changing the pullup voltage from 4.7 volt to 5.6 volts fixed the problem while changing the pullup resistor value did not. I guess the higher voltage would improve the edge rate, but reducing the resistor value should do that as well.

I suggest that you figure out exactly what was wrong with the original design since it should have worked ok. Just adding a buffer is more of a bandaid than a real solution (not that there is anything wrong with just "getting it to work").

BTW, with the 400R resistor, your SCL line should have been within edge rate spec with up to 1 nF (1000 pF) capacitance on the line. Is this all on the same board or is it possible that you are running too long a line off the board and have a lot of capacitance?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Markus, IIRC, the I2C spec calls for hystersis on the SCL input. The slow rise time as someone else already pointed out, may be creating oscillations after the SCL is buffered into the FPGA via the IOB. One way to verify this is to bring out a test point from after the IOB buffer, and look at it with a scope. If the design is using the buffered SCL clock to clock in data, you may consider "filtering" the glitchy buffered SCL signal to create a clock enable with a (much) faster free running clock if one is available, and using the clock enable along with the free running clock to run the I2C logic.

H> > I believe when you say "4,7V" you mean what we call 4.7 volts in the US,

Reply to
newman

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.