Hallo Experten, habe Grundsatzfrage zu I2C. Ab und zu kommt es vor das I2C Slaves durch Störungen oder Ähnlichen den Bus blockieren. Nun möchte ich die eine Funktion schreiben um die Slaves frei zu Takten. Wie funktioniert das Grundsätzlich? Kann man zu diesem Zweck einfach einen Takt erzeugen und auf ein ACK warten? Danke für Eure Hilfe Peter
Hallo Peter, gut das du das Thema einmal ansprichst. Ich habe hin und wieder auch das Problem, das vor allem die EEPROMs der 24xxx Reihe das tun. Aus welchem Grund das passiert ist mir wirklich auch noch nicht klar, aber das Problem ist dann fatal weil SDA und SCL beide nach GND vom entspechenden Baustein blockiert werden. Ein weiteres Takten ist dadurch aber nicht mehr möglich. Die Probleme kenne ich aber schon seit nun fast 15 Jahren und dei einzige Lösung, die ich habe ist die Versorgungsspannung von den Bauteilen kurz zu nehmen. Auch ein Display Interface von NXP hat diesen Effekt bei mir gezeigt. Wenn der SCL Pin das Signal nach Masse zieht, will er den Clock verlängern, weil seine interne Verarbeitungszeit nicht reicht, aber warum gibt er den SCL dann nicht mehr frei? Im I2C Protokoll von NXP steht ja auch einiges drin, aber das Verhalten der Bausteine kann ich so nicht nachvollziehen. Situation kann ja nur beim ACK oder aktiven Datenausgabe erfolgen? Gruß Sascha
Hallo Peter, diesen Effekt hat man immer wieder. Beide Leitungen liegen auf GND und mit Freitakten ist da nichts mehr. Der Bus steht dann so lange, bis ich die Versorgung abklemme. Bei den heutigen Bausteinen kommt das zwar nicht mehr so oft vor, aber das Phänomen ist nicht gänzlich bereinigt. Ich konnte vor vielen Jahren das HangUp des Busses auf falsches Timing der Flanken zurückführen. Irgendwann musste ich eine Schaltung aufbauen die diesen Effekt nicht zeigen durfte, also habe ich zwei I/O Pins des Controllers auf den SDA/SCL "schnüffeln" lassen und mden Controller den Leitungszustand nach jeder Übertragung kontrollieren lassen. Wenn der Bus hing, hat der Controller die I2C Pripherie am Bus kurz von der Versorgung genommen und wieder angelegt. Das ist nicht schön, es hat aber einwandfrei funktioniert. Der Bus war danach wieder benutzbar. Gruß Didi
Ja man findet nicht besonders viele Informationen zu diesem Thema. Habe irgendwo gelesen das es durch frei takten gelöst werden kann. Weiß da jemand mehr dazu? Peter
Wenn ein Slave die SDA Leitung nach der Stop Condition immer noch auf low hält, und die SCL Leitung auf high ist, dann kann es helfen auf der SCL Leitung weitere Takte zu erzeugen bis der Slave die SDA Leitung wieder "los lässt". Das kann passieren wenn Slaves ihren internen Status vom SCL Signal ableiten und es dabei zu (Protokoll-)Fehlern kommt. Das wird dann wohl als Freitakten bezeichnet. Wenn aber SCL durch den Slave auf low gezogen wird und der lässt den nicht wieder los, dann helfen wohl nur die oben genannten Lösungen.
Frank K. schrieb: > Wenn ein Slave die SDA Leitung nach der Stop Condition immer noch auf > low hält, und die SCL Leitung auf high ist, dann kann es helfen auf der > SCL Leitung weitere Takte zu erzeugen bis der Slave die SDA Leitung > wieder "los lässt". Das kann passieren wenn Slaves ihren internen Status > vom SCL Signal ableiten und es dabei zu (Protokoll-)Fehlern kommt. Das > wird dann wohl als Freitakten bezeichnet. Wenn aber SCL durch den Slave > auf low gezogen wird und der lässt den nicht wieder los, dann helfen > wohl nur die oben genannten Lösungen. Ja ich habe Dieses Verhalten gemeint! Bekommt man nach den zusätzlichen Takten ein ACK ? Danke für Eure Hilfe
Pier S. schrieb: > Bekommt man nach den zusätzlichen Takten ein ACK ? Da Du nicht weißt, an welcher Stelle die State-Machine im Slave hängengeblieben ist, würde ich die Übertragung als komplett fehlgeschlagen einstufen. uli schrieb: > Wäte interrssant zu wissen wie ed gemacht wirt! Ich würde die I2C-Funktion im Master deaktivieren und manuell am GPIO wackeln (blinky). Grüße Maik
Ich würde die I2C-Funktion im Master deaktivieren und manuell am GPIO wackeln (blinky). Ja und wie oft? oder kann man einfach 7 Takte machen? Vielen Dank für Eure Hilfe!
In den Grundlagen zum I2C Bus von Philips (heute NXP) war eine Prozedur beschrieben, die ich leider nicht vollständig in der Rübe habe. M.W. ging es so: 1 erstmal ne STOP Condition 2 SDA hochohmig machen und 9 mal SCL wackeln, dabei SDA beobachten. 3 Wenn SDA high wird, aufhören. 4 Wenn SDA high bleibt, aufhören. 5 Wenn SDA zwischendurch nochmal Low wird, wieder zu 2. 6 Wenn SDA nach der ganzen Wackelei immer noch Low bleibt -> Buserror. Das ganze funktioniert natürlich nur bei Single-Master, aber damals war I2C immer genau das. Genaueres ist in den Ur-Dokumenten zu I2C zu finden.
:
Bearbeitet durch User
Matthias Sch. schrieb: > 1 erstmal ne STOP Condition > 2 SDA hochohmig machen und 9 mal SCL wackeln, dabei SDA beobachten. > 3 Wenn SDA high wird, aufhören. > 4 Wenn SDA high bleibt, aufhören. > 5 Wenn SDA zwischendurch nochmal Low wird, wieder zu 2. > 6 Wenn SDA nach der ganzen Wackelei immer noch Low bleibt -> Buserror. Super Danke für die Info hast Du vielleicht noch den link zur Ur-Dokumentation LG Peter
http://www.nxp.com/documents/application_note/AN10216.pdf Seite 17 und noch eins: http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf
:
Bearbeitet durch User
Matthias S. schrieb: > M.W. > ging es so: Das ist ja nichts anderes, als ein Ansprechen mit der Annahme, dass er schon einem zyklischen Lesemodus oder Schreibmodus ist. Da kann man auch eine Reihe von Starts und Stopps mit einigen Takten senden. Nach spätestens 9 Zyklen ist er aus einem Modus raus. Wie aber schon angedeutet, funktioniert das nur, wenn der SCK noch bedienbar ist. Das ist er aber im Streching-Fall nicht. Da hilft nur, das teil vom Bus abzuhängen.
Du glaubst, daß jetzt jemand nach vier Jahren auf den PC starren sich die Spinnenweben aus den Haaren wischt, erschöpft durchatmet und aufsteht, um sich was zu essen zu machen?
Sascha schrieb: > Ich habe hin und wieder auch das Problem, das vor allem die EEPROMs der > 24xxx Reihe das tun. Aus welchem Grund das passiert ist mir wirklich > auch noch nicht klar, aber das Problem ist dann fatal weil SDA und SCL > beide nach GND vom entspechenden Baustein blockiert werden. DAs ist unmöglich, da SCL ein Eingang ist. Der 24Cxxx hat schlichtweg keinen Transistor, um ihn auf low zu ziehen. Wer SCL auf low zieht, ist der Master selber, d.h. Du mußt den Master disablen, dann kannst Du auch SCL als normalen Portpin takten.
Peter D. schrieb: > DAs ist unmöglich, da SCL ein Eingang ist. Der 24Cxxx hat schlichtweg > keinen Transistor, um ihn auf low zu ziehen. Hallo Peter, heißt das, ich kann sicher sein, daß ein 24Cxxx niemals clock stretching macht? Viele Grüße W.T.
Hi, In den Datenblättern zum 24Cxxx gibt es kein Schlüsselwort "strech" und das Block Diagramm deutet es auch nicht an, das da eine IO Zelle dran wäre -> Nein, ein 24Cxxx macht kein Clock streching. Du musst immer ein vollständige Start - Controlbyte - Address - Data - Stop senden. Wenn nach dem Controlbyte kein ACK kommt, ist das Ding noch beschäftigt und nochmal probieren. Gruß N2
Beitrag #5115642 wurde vom Autor gelöscht.
Beitrag #5115660 wurde von einem Moderator gelöscht.
Walter T. schrieb: > Hallo Peter, > heißt das, ich kann sicher sein, daß ein 24Cxxx niemals clock stretching > macht? Ja. Er verwendet eine andere Methode, um zu sagen, daß er busy ist. Er sendet NACK auf seine Adresse. Clock Stretching verwenden nur MCs. Es gibt aber einige Periperie, die intern als ROM-MC realisiert ist. Erkennen kann man das daran, daß SCL auch Ausgang ist.
Beitrag #5116527 wurde von einem Moderator gelöscht.
Pier S. schrieb: > Super Danke für die Info hast Du vielleicht noch den link zur > Ur-Dokumentation Das wurde schon in den 90igern von Microchip so heraus gebracht, weil deren EEs sich gern mal aufhängten. Ich ziehe dann einfach den Stecker und starte meine Kiste wieder neu, wenn die EEs sich als nicht ansprechbar herausstellen bzw bei einem Design habe ich deren VCC über einen uC Pin gelegt, so dass der die abschalten kann.
Analog OPA schrieb: > Peter D. schrieb: >> Clock Stretching verwenden nur MCs. > Sicher?? Wenn der I²C-Slave komplett in Hardware implementiert ist, dann sind Wartezeiten normalerweise nicht notwendig. (Ich könnte mir vorstellen, dass ein ADC warten will, bis ein neues Sample erzeugt wurde, oder dass ein EEPROM auf das Ende eines Schreibzugriffs wartet. Allerdings würde mit Clock Stretching dann der komplette Bus blockiert; in der Praxis wird das selbe Register gelesen, oder Zugriffe mit NACK blockiert.)
Eventuell mit dem holzhammer. einen fet mit lo-rds_on und logiklevel zwischen scl und gnd. (der muss stärker sein als die ports) wenn's hängt, durchschalten. Das hat auch den Vorteil einen versehentlich aktivierten hi-side driver zu zerstören.
Oh! Die serienwiderstände musst du natürlich weglassen. o_O
Christian J. schrieb: > Das wurde schon in den 90igern von Microchip so heraus gebracht, weil > deren EEs sich gern mal aufhängten. Wir setzen schon ~25 Jahre 24Cxx von ST, Microchip und Atmel ein, ohne Probleme. Es wäre auch nicht gut, dem Kunden sagen zu müssen, ziehen sie mal den Stecker. Es kann sein, wenn die EEPROM an langen Leitungen hängen, daß Störimpulse den Master und den Slave asynchron machen, d.h. der Master will ein STOP senden, der Slave legt aber gerade ein Datenbit 0 an und der Master scheitert. In dem Fall kann man den Slave mit 9*SCL takten abschalten und dann klappt das STOP wieder. Weiterhin kann ein Brownout- oder Watchdogreset des MC mitten im Lesen den Slave asynchron machen. Ich hab aber auch schon bei Fremdgeräten einen simplen Softwarefehler beobachten können, d.h. der Master sendet nach dem letzen Byte lesen ein ACK, statt NACK. Dann scheitert das STOP vom Master auch, wenn das nächste Datenbit vom Slave 0 ist.
Peter D. schrieb: > Es kann sein, wenn die EEPROM an langen Leitungen hängen, daß > Störimpulse den Master und den Slave asynchron machen, d.h. der Master > will ein STOP senden, der Slave legt aber gerade ein Datenbit 0 an und > der Master scheitert. In dem Fall kann man den Slave mit 9*SCL takten > abschalten und dann klappt das STOP wieder. > Weiterhin kann ein Brownout- oder Watchdogreset des MC mitten im Lesen > den Slave asynchron machen. Es gibt auch Situationen, da will (muss) man die aktuelle Übertragung schlichtweg abwürgen. Bei meinem Arbeitgeber und dessen Produkten stellen spontane Spannungsausfälle ein großes Problem dar. Zur Überbrückung jeglicher Lücken muss der Prozessor so gut wie sämtliche Peripherie sofort abschalten, unter anderem auch die I2C Schnittstellen. Die verwendeten 24AA müssen dabei regelmäßig wieder "freigetaktet" werden.
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.