Hallo, ich habe hier ein ärgerliches Problem mit einem Mega8 als I2C Master. Und zwar würde ich gerne einen TVP7000 als I2C Slave ansteuern, bekomme aber kein Ack zurück, weshalb ich das Timing mal genauer nachgemessen habe. Dabei bin ich zur Erkenntnis gekommen dass die Hold Zeit zu kurz ist. Diese ist im Datenblatt mit 0.9us bei einer 400kHz Clk angegeben. Wenn ich nachmesse komme ich aber nur auf 450ns. Jetzt dachte ich, ok nehmen wir mal nur eine 100Khz Clk - leider bleibt die Hold Zeit dabei konstant... Was mich daran wundert ist dass diese Problem doch schon öfter aufgetreten sein müsste, wäre es ein allgemeines der AVR I2C Implementierung. Daher meine Frage: ist das überhaupt ein Problem? Kann man die Zeit irgendwie verlängern? ... In jedem Fall vielen Dank euch allen! Grüße Florian
Angehängte Dateien:
-
I2CHoldTime.png
20 KB
Der Dateianhang scheint aus einem Simulator zu stammen. Gelegentlich haben diese Tools Bugs, während der reale Controller den nicht hat.
Die maximale Holdzeit beträgt 0,9us; die Holdzeit darf beliebig kürzer sein als diese 0,9us, nämlich minimal 0ns. 450 ns liegt also im grünen Bereich. Bernhard
Hi >Der Dateianhang scheint aus einem Simulator zu stammen. Gelegentlich >haben diese Tools Bugs, während der reale Controller den nicht hat. Nö. Logicport LA. MfG Spess
Das sieht für mich - einfach mal in der Glaskugel - nach dem "off-by-one" Adressproblem des TWI aus: HW-Datenblätter geben die 7 Bit der Adresse linksbündig an, während manche Software sie rechtsbündig erwartet und selbst um 1 Bit nach links schiebt rsp das genaue Gegenteil. Bernhard
Die 7-Bit-Adresse des Slave belegt in der I2C Hardware die 7 höherwertigen Bit; das niederwertigste Bit wird als Read/Write Indikator verwendet. Manche I2C Software-Treiber benutzen für die Adresse die 7 niederwertigen Bit eines Byte und schieben selbiges Byte für den Hardware-Zugriff um ein Bit nach links, wenn sie es in das TWI-Datenregister stellen. Ohne weitere Informationen - speziell den Sourcecode der verwendeten Software - läßt sich allerdings nichts sagen. Der LA-Screenshot zeigt mir jedenfalls kein Problem. Bernhard
Hat der AVR nicht die i2c-Ansteuerung bereits in Hardware? Dann sollte das Timing sowieso soweit stimmen. Ich würde erstmal einen Bus-Scan machen: Alle Adressen durchlaufen lassen und schauen wann ein ACK kommt. Pull-Ups usw. setze ich mal hier voraus!
Hallo Bernhard, nein das ist es leider nicht... Könnte jetzt noch einen Screenshot machen wo man das sieht aber es ist so dass die gemessene Bitfolge genau der Adresse im Datenblatt enspricht und anschließend noch ein Read/Write Bit kommt. Grüße Florian
Nicht Bekannt schrieb: > Dabei bin ich zur Erkenntnis gekommen dass die Hold Zeit zu kurz ist. Nö ist sie nicht. Z.B. im Datenblatt des bekannten DS1307 bei 100kHz: Holdtime: >0ns Setuptime: >250ns D.h. die Daten können gleichzeitig mit SCL = 0 wechseln und müssen mindestens ab 250ns vor SCL = 1 stabil sein. Peter
Die Clock timings sehen doch gut aus. Das würde ich machen: 1. Pullups testweise 1k-1k2 egal wer was erzählt. Anstiegskurven anstelle Flanken kann man mit dem Logicport nicht sehen. Das eingrenzen mittels threshold schieben geht. Wenn dann bei extra Trigger über einen unbelasteten Ausgang die Zeiten wandern hast du "Bananenflanken". 2. Adresse prüfen. Die verschiebt sich bei I2C um ein Bit wg. Read Write, es gibt reservierte usw.
@ Nicht Bekannt Wo bleiben die Informationen: - Schaltbild der Hardware - Sourcecode der Software ?? Mir drängt sich der Eindruck auf, daß Du irgendwo am "Bit 57" rumwurschtelst, während Du grundlegende Dinge noch überhaupt nicht verstanden hast. Bernhard
Angehängte Dateien:
-
I2Cganz.png
4,9 KB
Hallo, nein ich habe auch gröber gesucht als an Pin 57. Im Anhang die komplette I2C Messung. Ihr sehr dass als Adresse die 0b10111000 übertragen wird. Laut Datenblatt ist diese auch 0xB8 für schreiben und 0xB9 für lesen sein soll. Passt also meiner Ansicht nach. grüße Florian
>Ihr sehr dass als Adresse die 0b10111000 übertragen wird. Laut >Datenblatt ist diese auch 0xB8 für schreiben und 0xB9 für lesen sein >soll. Passt also meiner Ansicht nach. Wenn da alles richtig ist bekommst du auch ein Ack. Das stellt der Intronix nach meiner Erfahrung zu 100% richtig da. Eingrenzen ist das Zauberwort für systematische Entwicklung Hak evtl. also erstmal diese Liste ab http://www.i2c-bus.org/common-problems/ Dann! Eine Adress $Bx gibt es bei 7 bit I2C nicht. Die Adressen sind 7 Bit (alles über $7F existiert nicht) um ein Bit Richtung MSB verschoben und um das schreib-lesekommando ergänzt http://www.i2c-bus.org/addressing/ Evtl liegt da der Hase begraben
Hallo, erstmal zur Adresse: Ja das ist mir klar dass diese nur 7bit lang sein darf. Im Datenblatt ist die aber als 8bit Wert angegeben daher habe ich oben 0xB8 bzw. 0xB9 geschrieben. Ich habe dazu auch das Adressbyte "uninterpretiert" mit 0b10111000 angegeben. Im Datenblatt ist es zudem noch Bitweise aufgelöst angegeben. Und dort steht auch S 10111000 ACK, also genau das was ich gemessen habe... Die Liste werde ich durchgehen! Vielen Dank! Grüße Florian
Hm. Kommt nun nie ein ACK zurück? Vielleicht ist der Chip intern beschäftigt - aus welchen Gründen auch immer... Manche Chips wie EEPROMs stellen sich dann gerne erstmal tot. Nach Beendigung des internen Schreibvorgangs sind sie wieder online. Macht der Chip clock-stretching und du reagierst nicht drauf? Ansonsten frage mal TI. Der Chip scheint ja von denen zu sein. Quarz-Clock, Spannungsversorgung usw. kontrollieren.
Nein das I2C ist mit 400Khz Spezifiziert, das sollte also klappen. Intern beschädigt liegt natürlich immer nahe, allerdings wäre dann nur das I2C Interface Betroffen da er sonst korrekt arbeitet.
Dann wäre noch der Klassiker schneller Transienten durch parallellaufende Leitungen, die einkoppeln in die Busleitungen. Je nach Auflösung der Meßgeräte ist sowas nicht zu sehen. Originale Philips-Schaltkreise haben für sowas extra Entstörfilter auf dem Chip. Andere Hersteller kochen aber jeder anders. Vielleicht hilft die alte '100 Ohm Seriellwiderstand in den Leitungen'-Technik von Grundig/Philips hier. Ich würde mir das mal mit einem Scope ansehen.
>Die Liste werde ich durchgehen! Vielen Dank! Gern geschehen. Dann: >Im Datenblatt ist es zudem noch Bitweise aufgelöst angegeben. Und dort >steht auch S 10111000 ACK, also genau das was ich gemessen habe.. Ok, du funkst aber ins leere. Versuch doch mal die alternative Adresse des TI Chips und ändere mal schreib lese Kommando. Als letzes: Glichtes kannst du mit dem Intronix wunderbar sehen wenn du die Sample rate auf 200Mhz drehst und am threshold spielst (Transitions z.B trigger to cursor A muß stabil bleiben)
Vielleicht wurde die Basisadresse versehentlich umprogrammiert? Viele komplexere Chips unterstützen dies - teils sogar dauerhaft auch das Ausschalten überlebend. Also doch Bus-Scan. Verstehe nicht, wieso man so einen Tipp nicht sofort umsetzt.
>Also doch Bus-Scan. Verstehe nicht, wieso man so einen Tipp nicht sofort >umsetzt. Evtl. verzichtet der Threaderöffner darauf weil der TI Chip lt. Datenblatt nur 2 feste Adressen hat.
Hallo, "Bus Scan" habe ich gemacht. Hat tatsächlich auf keiner Adresse geantwortet. Gibt es eigentlich eine Möglichkeit das automatisiert zu machen? War doch etwas nervig... Den 100 Ohm trick habe ich gemacht. Leider keine Verbesserung. Selbstverständlich habe ich die aternative Adresse schon gecheckt. Den Glitch Versuch habe ich eben gemacht. Zwischen Vth = 0,75V und 2,95V sind die Transistions völlig Konstant. Ich denke das ist ein guter Wert? Grüße und nochmals vielen Dank Florian
Nicht Bekannt schrieb: > Gibt es eigentlich eine Möglichkeit das automatisiert zu > machen? War doch etwas nervig... Es gibt beim I²C Bus eine GC (General Call) Adresse (0000 000x) Schick darauf einen Request, schalt deinen "Master" für eine gewisse Zeit auf Empfang (Slave) und warte einfach was zurückkommt. Da I²C ja ein MultiMaster Bus ist, wartet ein Master sowieso, wenn gerade ein anderer sendet (Arbitration).
>Den Glitch Versuch habe ich eben gemacht. Zwischen Vth = 0,75V und 2,95V >sind die Transistions völlig Konstant. Ich denke das ist ein guter Wert? Wenn Sie über 2,95 Richtung 0 gehen ist wohl alles bestens. Würde das Pinning noch mal prüfen (double check! 2x rum ums Haus alle Pins des Slave ob noch ne Enable line etc versteckt ist und alle auch nachmessen). Dann die Signale direkt an den IC Beinchen des Slaves (wenn man rankommt) abgreifen.
Ich bezweifel das der GC weit verbreitet ist. Eigentlich kenne ich den Begriff nur aus der NXP-i2c Dokumentation. Dazu müßte man ins Datenblatt sehen. Ja, das habe ich mir erspart. Wenn ich jetzt so lese "Wie macht man einen Bus-Scan automatisiert?", klinke ich mich wohl besser aus. Noch nie von einer Schleife in Software gehört? Gut, einen letzten Tipp habe ich noch: Hänge einen anderen i2c-Chip mal alternativ ran und spiele erstmal mit dem.
>Es gibt beim I²C Bus eine GC (General Call) Adresse (0000 000x) >Schick darauf einen Request, schalt deinen "Master" für eine gewisse >Zeit auf Empfang (Slave) So denn general call auch implementiert ist. I2C ist ein Chip to Chip Standard der nichts zwingend vorschreibt (u.a. deshal da sich auf diesem level sowieso keiner daran hält, wozu auch) Das kann mehr verwirren als Nutzen.
So letzte gute Tat für heute: Der Chip ist ein 3.3V chip Schau mal auf den Datenblattauszug: VOH_SCLK DATACLK output voltage high IOH = 4 mA 0.8 IOVDD V VOL_SCLK DATACLK output voltage low IOH = –2 mA 0.2 IOVDD V -------------------------------------------------^
Ja und? Du meinst sein AVR läuft mit 5V ?? Hoffentlich hat er dann die Bus Pull-Up-Rs auch an 3,3V gehangen. Setze ich eigentlich mal voraus. Time-out a la smBus wäre auch noch möglich.
Ja der AVR läuft mit 5V, dazwischen habe ich aber einen PCA9515 der zwischen 5V und 3V shiftet. Alle geposteten Messungen habe ich selbstverständlich auf der 3V Seite vorgenommen!
Wie gesagt, nimm einen anderen i2c Baustein und teste es damit. Irgendein EEPROM wirste ganz sicher in deiner Wohnung finden.
>Alle geposteten Messungen habe ich >selbstverständlich auf der 3V Seite vorgenommen! Das widerspricht sich mit > Den Glitch Versuch habe ich eben gemacht. Zwischen Vth = 0,75V Sollte theor. dann wesentlich weiter runtergehen. Deine Vil schwelle ist ~ 0,2V. (Unter vorbehalt: Hab selbst aber nur 5V I2C am laufen)
Nicht Bekannt schrieb: > Gibt es eigentlich eine Möglichkeit das automatisiert zu > machen? War doch etwas nervig Einfach eine Schleife für alle 127 Adressen: Start, Adresse, ACK testen, Stop. Mache ich z.b in einem Gerät so. Anhand der erkannten Module entscheidet dann die Software, als welches Gerät sie arbeiten muß. In Deinen Bildern ist eindeutig, daß sich Dein Slave tot stellt. Also entweder ist die Adresse falsch oder der Slave ist kaputt oder falsch angeschlossen. Manche ICs benötigen auch einen Takt (Quarz), um zu arbeiten. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.