1

I have a ZedBoard FPGA device and I'm trying to implement an I2C interface to communicate with a camera module. I'm using Vivado 2014.2 and I have added an AXI IIC block to my design with the SCL clock frequency set to 90KHz. The physical SCL/SDA pins have a 10k pullup resistor to VCC (tried 4K7 also). For some reason, my scope shows both pins as already having some kind of invalid signal being output on them, when it should be asserted low as I have not setup any actual communication in software yet. Also notice that the speed of these signals is 24MHz! Which happens to be the speed of the onboard processor clock for some reason (no, the pins are NOT mixed up). Here is the scope output with the SCL/SDA pins:

photo

Any idea why this is happening?

Dave Tweed
  • 172,781
  • 17
  • 234
  • 402
bparker
  • 121
  • 2

3 Answers3

1

So, the unwanted signals are synchronised but not perfectly identical (although that could be the scope) and about 1Vpp.

Crosstalk, perhaps? Is there another synchronised but digital signal on a nearby pin or trace? Do the unwanted signals disappear if you ground the pins rather than leaving them floating with pullups?

If you don't include the I2C module in the build, do the pins exhibit the same behaviour? If you build in some GPIO attached to those pins and drive the pins high and/or low, is the unwanted signal overlaid on the driven logic level or does it disappear?

Also, doesn't the Zynq PS block have two I2C peripherals already? Why aren't you using one of them?

markt
  • 4,956
  • 2
  • 15
  • 13
  • Yes there is a 24MHz clock pin adjacent to the SCL/SDA lines on the same PMOD connector, which is the master clock input for the camera module (using the PS FCLK output). I have not tried grounding the pins... do you mean connecting the SCL pin directly to ground without the pullup or scope probe? The pins do not exhibit the behavior without the module. Even with the I2C block, it's not until the PS is booted (which is when the FCLK is turned on) that it does this. I'll try your GPIO suggestion... how would I fix this if it's crosstalk? Yes the PS already has I2C, I just haven't tried it yet. – bparker Aug 17 '14 at 02:09
  • Clocks tend to be leaky, unfortunately. If you could make it differential that would help enormously. Alternatively, a snubber might help - a small resistor in series with a tiny cap (say, 68R + 10pF) to ground, placed at the receive end of the clock line. Re grounding the pins, I mean driving them to ground, either with a piece of wire or by programming their drive logic to output a 0; either way I'd leave the pullups in place. Also, if this is a commercial module designed to attach to the ZedBoard causing problems, have you tried asking the vendor? – markt Aug 17 '14 at 07:33
  • Hmm, do you have a link that explains how/why they leak? The camera does not support a differential clock unfortunately, and it's not designed for the ZedBoard, but this is it: http://goo.gl/5OEpGa. Would the fact that the PMOD connector I'm using is setup as differential be a factor? Would physically moving the leaky clock to another pin/connector help (and/or using the PS I2C)? – bparker Aug 17 '14 at 15:52
  • "Leakiness" (not very technical, but an accurate description of the behaviour) is common to signals with high slew rates, and is more noticeable if they're highly repetitive and regular; clocks are a good example. If the clock can't be differential, then moving it to a different pin and putting ground traces either side of it (by e.g. making the relevant pins outputs and driving them low), plus the snubber I mentioned to reduce the slew rate, should help a lot. – markt Aug 18 '14 at 07:39
  • I tried moving the problematic 24MHz clock pin "XCLK" to a different PMOD and putting ground traces around it, which maybe helped a little: https://i.imgur.com/uOTKeBA.jpg but driving SCL to ground still shows the same pattern as the XCLK pin, just with very little voltage now: https://i.imgur.com/8Vfvwbx.jpg I tried using the PS I2C block but the signal still appears the same, although I can actually read registers now, but the data I get back is corrupted. – bparker Aug 18 '14 at 14:35
0

It looks to me like you are not actively driving the SCL/SDA pins. They are probably configured as high-impedance by default in the bitstream and therefore simply show adjacent pin clock noise as others have suggested. It looks like the scope is showing 500mv per division so the magnitude of the noise seems large to me but that doesn't rule it out when in high-impedance, iff your pullup wasn't working.

Try looking at the pin/pad editor of the device to make sure you actually have the pins turned on as driven pins. Check that the GND and power pins for the specific IO-Bank containing these pins are both connected on your board and not floating. Check that the verilog/vhdl connections are intact. Depending on the vendor FPGA toolchain look for the schematic view and chase back from the IO Pin to make sure it is actually driven by some flip flops and that the pin's en-signal (the IO cell's driver for logical 'z') isn't replaced with constant 1.

I am certain that as soon as the active drivers for these pins are enabled the noise will be completely dwarfed by the signal.

shuckc
  • 3,032
  • 15
  • 19
  • The AXI IIC block is set to actively drive the pins high, and I can tell from the scope that it is doing so, I just still see the noise... the gnd/vcc from the same pmod connector are hooked up and there isn't any HDL code involved at this point... not sure how to track down the flip flop thing but somehow I got it to 'work' by using the built-in zynq I2C controller, even though the noise is still there (but not as much). – bparker Aug 20 '14 at 13:27
0

Sorry if this is too obvious, but do you have the scope probes set to 10:1 and 20MHz band limit 'off' on the 'scope?

Spehro Pefhany
  • 397,265
  • 22
  • 337
  • 893
  • I am a couple of years late to this party, but I would also add, make sure the o-scope probe grounds are actually attached to ground, preferably through a nice short wire. – Annie May 04 '18 at 22:34