Seltsame I2C-Signale, die vom FPGA ausgegeben werden

Ich habe ein ZedBoard FPGA-Gerät und versuche, eine I2C-Schnittstelle zu implementieren, um mit einem Kameramodul zu kommunizieren. Ich verwende Vivado 2014.2 und habe meinem Design einen AXI IIC-Block hinzugefügt, wobei die SCL-Taktfrequenz auf 90 kHz eingestellt ist. Die physischen SCL / SDA-Pins haben einen 10k-Pullup-Widerstand gegen VCC (versuchte auch 4K7). Aus irgendeinem Grund zeigt mein Oszilloskop an, dass an beiden Pins bereits eine Art ungültiges Signal ausgegeben wird, obwohl es niedrig geltend gemacht werden sollte, da ich noch keine tatsächliche Kommunikation in der Software eingerichtet habe. Beachten Sie auch, dass die Geschwindigkeit dieser Signale 24 MHz beträgt! Das ist aus irgendeinem Grund die Geschwindigkeit der integrierten Prozessoruhr (nein, die Pins sind NICHT vertauscht). Hier ist die Scope-Ausgabe mit den SCL/SDA-Pins:

Foto

Irgendeine Idee, warum das passiert?

Benötigt der I2C-Block einen anfänglichen Reset-/Konfigurationsschritt?
Nein, das Signal sollte flach sein, bis ich ihm sage, dass es in ein Register schreiben soll.
Wie groß ist die Amplitude (v Spitze zu Spitze) der angezeigten Signale?

Antworten (3)

Die unerwünschten Signale sind also synchronisiert, aber nicht vollkommen identisch (obwohl das der Bereich sein könnte) und etwa 1 Vpp.

Übersprechen vielleicht? Gibt es ein anderes synchronisiertes, aber digitales Signal auf einem nahegelegenen Pin oder einer Leiterbahn? Verschwinden die unerwünschten Signale, wenn Sie die Pins erden, anstatt sie mit Pullups schweben zu lassen?

Wenn Sie das I2C-Modul nicht in den Build einbeziehen, zeigen die Pins das gleiche Verhalten? Wenn Sie einen an diese Pins angeschlossenen GPIO einbauen und die Pins hoch und / oder niedrig treiben, wird das unerwünschte Signal dem angesteuerten Logikpegel überlagert oder verschwindet es?

Hat der Zynq-PS-Block nicht auch schon zwei I2C-Peripheriegeräte? Warum benutzt du keinen davon?

Ja, es gibt einen 24-MHz-Taktpin neben den SCL/SDA-Leitungen auf demselben PMOD-Anschluss, der der Haupttakteingang für das Kameramodul ist (unter Verwendung des PS-FCLK-Ausgangs). Ich habe nicht versucht, die Stifte zu erden ... meinen Sie, den SCL-Stift ohne Pullup- oder Oszilloskopsonde direkt mit Masse zu verbinden? Ohne das Modul zeigen die Pins nicht das Verhalten. Selbst mit dem I2C-Block wird dies erst beim Booten des PS (wenn der FCLK eingeschaltet wird) durchgeführt. Ich werde Ihren GPIO-Vorschlag ausprobieren ... wie würde ich das beheben, wenn es sich um Übersprechen handelt? Ja, die PS hat bereits I2C, ich habe es nur noch nicht ausprobiert.
Uhren neigen leider dazu, undicht zu sein. Wenn Sie es unterscheiden könnten, würde das enorm helfen. Alternativ könnte ein Snubber helfen - ein kleiner Widerstand in Reihe mit einer winzigen Kappe (z. B. 68 R + 10 pF) gegen Masse, der am Empfangsende der Taktleitung platziert ist. Wenn Sie die Pins erneut erden, meine ich, sie auf Masse zu treiben, entweder mit einem Stück Draht oder indem Sie ihre Ansteuerlogik so programmieren, dass sie eine 0 ausgibt. Auf jeden Fall würde ich die Klimmzüge drin lassen. Wenn dies ein kommerzielles Modul ist, das zum Anbringen an das ZedBoard entwickelt wurde und Probleme verursacht, haben Sie versucht, den Anbieter zu fragen?
Hmm, hast du einen Link, der erklärt, wie/warum sie lecken? Die Kamera unterstützt leider keinen differentiellen Takt und ist nicht für das ZedBoard ausgelegt, aber das ist es: goo.gl/5OEpGa . Wäre die Tatsache, dass der von mir verwendete PMOD-Anschluss als Differential eingerichtet ist, ein Faktor? Würde es helfen, die undichte Uhr physisch auf einen anderen Pin / Stecker zu verschieben (und / oder den PS I2C zu verwenden)?
"Leckage" (nicht sehr technisch, aber eine genaue Beschreibung des Verhaltens) ist bei Signalen mit hohen Anstiegsgeschwindigkeiten üblich und fällt stärker auf, wenn sie sich stark wiederholen und regelmäßig sind; Uhren sind ein gutes Beispiel. Wenn die Uhr nicht differentiell sein kann, dann verschieben Sie sie auf einen anderen Pin und legen Sie Erdungsspuren auf beiden Seiten davon (indem Sie zB die relevanten Pins ausgeben und sie auf Low treiben), plus den von mir erwähnten Snubber, um die Anstiegsrate zu reduzieren, sollte viel helfen.
Ich habe versucht, den problematischen 24-MHz-Taktpin „XCLK“ auf einen anderen PMOD zu verschieben und Erdungsspuren darum zu legen, was vielleicht ein wenig geholfen hat: i.imgur.com/uOTKeBA.jpg , aber das Fahren von SCL auf Masse zeigt immer noch das gleiche Muster wie der XCLK Pin, jetzt nur mit sehr geringer Spannung: i.imgur.com/8Vfvwbx.jpg Ich habe versucht, den PS I2C-Block zu verwenden, aber das Signal erscheint immer noch dasselbe, obwohl ich jetzt tatsächlich Register lesen kann, aber die Daten, die ich zurückerhalte, sind beschädigt.

Es sieht für mich so aus, als würden Sie die SCL / SDA-Pins nicht aktiv ansteuern. Sie sind im Bitstream wahrscheinlich standardmäßig hochohmig konfiguriert und zeigen daher einfach benachbartes Pin-Clock-Rauschen, wie andere vorgeschlagen haben. Es sieht so aus, als ob das Oszilloskop 500 mV pro Teilung anzeigt, daher erscheint mir die Größe des Rauschens groß, aber das schließt es bei hoher Impedanz nicht aus, wenn Ihr Pullup nicht funktioniert hat.

Sehen Sie sich den Pin/Pad-Editor des Geräts an, um sicherzustellen, dass Sie die Pins tatsächlich als angetriebene Pins aktiviert haben. Überprüfen Sie, ob die GND- und Stromversorgungsstifte für die spezifische IO-Bank, die diese Stifte enthält, beide auf Ihrer Platine verbunden und nicht schwebend sind. Überprüfen Sie, ob die Verilog/VHDL-Verbindungen intakt sind. Suchen Sie je nach FPGA-Toolchain des Anbieters nach der schematischen Ansicht und jagen Sie vom IO-Pin zurück, um sicherzustellen, dass er tatsächlich von einigen Flip-Flops angesteuert wird und dass das en-Signal des Pins (der Treiber der IO-Zelle für logisches „z“) dies nicht ist durch Konstante 1 ersetzt.

Ich bin sicher, sobald die aktiven Treiber für diese Pins aktiviert sind, wird das Rauschen vom Signal vollständig in den Schatten gestellt.

Der AXI IIC-Block ist so eingestellt, dass er die Pins aktiv hoch treibt, und ich kann anhand des Oszilloskops erkennen, dass dies der Fall ist. Ich sehe nur noch das Rauschen ... gnd / vcc vom selben pmod-Anschluss sind angeschlossen und es gibt n An dieser Stelle ist kein HDL-Code beteiligt ... Ich bin mir nicht sicher, wie ich das Flip-Flop-Ding aufspüren soll, aber irgendwie habe ich es mit dem eingebauten Zynq-I2C-Controller zum "Arbeiten" gebracht, obwohl das Rauschen immer noch da ist (aber nicht so viel).

Entschuldigung, wenn dies zu offensichtlich ist, aber haben Sie die Oszilloskopsonden auf 10: 1 und die 20-MHz-Bandbegrenzung auf "Aus" auf "Oszilloskop" eingestellt?

Ich bin ein paar Jahre zu spät zu dieser Party, aber ich würde auch hinzufügen, stellen Sie sicher, dass die Erdung der O-Scope-Sonde tatsächlich mit der Erde verbunden ist, vorzugsweise über einen schönen kurzen Draht.
Seltsame I2C-Signale, die vom FPGA ausgegeben werden
AntwortenHierDatenschutz-Bestimmungen1y, 0v