Hallo zusammen, wir haben folgendes Phänomen mit dem DAC: Das System besteht aus einem Atmel SAMA5D3 an dem am I2C mehrere Slaves, unter anderem ein EEPROM und zwei der Analog Devices AD5696 DAC's hängen. Im Rahmen einer Testprozedur sende ich eine Folge von mehreren Bytes mit fortlaufend steigendem Wert (0x10, 0x11, 0x12, ...) in einem langen Transfer an das EEPROM. Jetzt das komische: Mitten im Transfer ab einer Bitfolge die der Adresse eines der DAC's entspricht scheint dieser ebenfalls die Kommunikation zu starten. Bemerkbar macht sich das indem der Prozessor sobald er merkt, dass die Datenleitung nicht seiner Vorgabe entspricht die Kommunikation abbricht - sprich die Taktleitung los lässt. In diesem Zustand nutzt es auch nichts prozessorzeitig weitere Taktzyklen "per Hand" zu senden um die Datenleitung zu lösen und ein Stop setzen zu können. Der DAC lässt die Leitung erst nach einem Reset des IC wieder los. Wenn ich den DAC vom Bus trenne, spielt sich das Selbe an einer anderen Stelle im Transfer ab, die dem Bitmuster der Adresse des zweiten DACs entspricht. Mit einem Oszi habe ich die Busleitungen direkt an den DAC-Pins beobachtet - keine Auffälligkeit. Da ist weit und breit keine Startcondition. Auch die Versorgungsspannung von 3.3V liegt zu jedem Zeitpunkt stabil an. Inzwischen habe ich auch einen DAC mal gegen einen aus einer älteren Lieferung getauscht - kein Unterschied. Das Verhalten ist absolut reproduzierbar und tritt bei jedem entsprechenden Transfer auf. Ich sehe keine Erklärung für das Verhalten. Hat jemand eine Idee was hier eigentlich passiert? Grüße Christian
:
Bearbeitet durch User
Hallo Christian, ich habe mir mal das Datenblatt des AD5696 angesehen (die Beschreibung ist wohl nicht ganz auf der Höhe, da für diesen Chip beide seriellen Übertragungsarten SPI/IIC beschrieben werden - diese sich aber immer auf den XX96-Typ beziehen, der ja wohl nur IIC ist. Der SPI Chip wäre dann der xx86-Typ). Egal: Der Chip sollte nur dann auf seine Adresse reagieren, wenn unmittelbar zuvor eine START Bedingung gesendet wurde. Die ist bei Dir aber nicht vorhanden (laut eigener Aussage), was doch sehr merkwürdig ist. Wie sehen denn die realen Pegel auf den Bus-Leitungen aus? Haben wir es eher mit abgerundeten "Dreiecken" oder doch mit steilen "Rechtecken" zu tun? Welche Geschwindigkeit nutzt Du (100/400kHz)? Was ist, wenn alle DACs vom Bus getrennt sind? (Und Oszi-Bilder / Schaltplan wäre hilfreich) Gruß TK
Angehängte Dateien:
-
Problem_at_0x1D_zoom.PNG
3,7 KB
Hi TK, die Flanken sehen meiner Meinung nach gut aus. Alles locker im Bereich der Vorgaben aus dem Datenblatt. Siehe Screenshot. Auch die Pegel sind im grünen Bereich. Der Spike im Bild stammt vom letzten regulärem Ack auf dem Bus. Dann sendet der Master 0x1D und der DAC mit Addr 0x0E fühlt sich anscheinend zu einem Lesezugriff aufgefordert. Aufgefallen ist mir das ganze bei 100KHz. Bin dann schrittweise auf 10KHz runter aber das hat überhaupt nichts geändert. Wenn alle DAC's vom Bus getrennt sind, läuft die Funktion einwandfrei durch. Die Schaltung sieht folgendermaßen aus: Der Bus läuft insgesamt über <50cm. Die Slaves sind über Stichleitungen von wenigen mm angebunden. Die Pullups sind nahe am Master platziert und schon mit verschiedenen Werten von 810 bis 4k7 bestückt worden - man ahnt es - ohne Veränderung. Der Screenshot wurde z.B. bei 810 gemacht. Grüße Christian
Angehängte Dateien:
Die Flanken sehen eigentlich gut aus. Die 810 Ohm sind grenzwertig. Bei 3V3 gehen noch 1k als Minimum. Ich kann Dir jedoch mit den gesendeten Bytes nicht folgen. Wenn ein 0x1D gesendet werden würde (roten Bereichsgrenzen im Bild), dann gehört der Spike nicht zum letzten ACK! Falls der Spike doch zum letzten ACK gehört, dann gelten die rosa Bereichsgrenezen und da lese ich ein 0xE0 - ACK - 0xE8. Es ist auch nochmal sinnvoll sich genau die SCL H-L Flanken anzusehen (großzoomen auf 1us/DIV oder besser) und mal an diesen Stellen die SDA Flanke zu suchen. Evtl. wird durch Laufzeiten doch mal die SDA VOR der SCL auf L (was dann ein Stopp wäre). Um das genau für den AD5696 auszuschliessen, muss exakt an den Pins des Chips gemessen werden! Wie gesagt, aus dem Bild kann ich jetzt nicht ausschliessen, dass SDA immer während SCL = L geändert wird. Gruß TK
Streiche: >Evtl. wird durch Laufzeiten >doch mal die SDA VOR der SCL auf L (was dann ein Stopp wäre) Setze: (was dann ein Start / repeated start wäre)
Angehängte Dateien:
-
danger.png
13 KB -
ok-clock.png
4,2 KB
Dein I2C Timing sieht nicht gut aus. Du hast gleichzeitig fallende Flanken der Clock und der Datenleitung. Da kann bei leichter Verzögerung des Clocksignals eine unbeabsichtigte Start-Condition herauskommen (rote Kreise). Ändere das Timing, so dass die Clock-Flanken nicht mit Datenflanken zusammenfallen. Siehe auch: http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/3465.i2c_2D00_timing.png
:
Bearbeitet durch User
@Joe:
Bei dieser gezeigten Auflösung im Zeitbereich kann man diese Aussage
>Dein I2C Timing sieht nicht gut aus.
nicht treffen. Es ist sehr wohl erlaubt sofort NACH der fallenden SCL
Flanke den SDA Pegel zu ändern. Ich hatte aber schon geschrieben, dass
man direkt am DAC-Chip messen sollte, ob es aufgrund von
Laufzeitverzögerungen nicht doch zu einem Nacheilen von SCL bzw.
Voreilen von SDA kommt. Dazu eben auch den Vorschlag an diesen Stellen
mal mit 1us/DIV rein zu zoomen.
Und wenn man auf der sicheren Seite sein möchte, dann kann man - sofern
es der Controller her gibt - auch in irgendwelchen Einstellungen
erreichen, dass eine Mindestlatenzzeit von - sagen wir mal - 1us nachdem
SCL=L geht, eingehalten wird.
Gruß
TK
Angehängte Dateien:
-
edges.PNG
2,8 KB -
falling_SDA_SCK.PNG
2,8 KB -
high_SDA.PNG
2,6 KB -
rising_SCK.PNG
2,7 KB -
ack_spike.PNG
2,7 KB
So, nun erst einmal weitere Screenshots... Die Flanken sind meiner Meinung nach ausreichend versetzt, dass die Timings eingehalten werden. Ändern lässt der Controller das leider sowieso nicht, sonst hätte ich die SDA Flanken auch lieber zwischen die SCK Flanken geschoben. Nochmal zum Ack: Du hast Recht das ist nicht das letzte. Das ist das letzte von dem ich glaube, dass es ohne Einmischung des DAC's gesendet wird. Es gilt der rote Bereich, den du markiert hast. Das 0x1D scheint den DAC anzusprechen. Vom darauf eigentlich folgenden 0x1E sieht man nur die ersten drei Bits.
Habe ich das so richtig verstanden: Der Atmel bricht mitten im Telegramm die Kommunikation ab indem er einfach aufhört zu Takten (SCL bleibt H) und OHNE ein Stop zu produzieren (was er evtl. machen würde, wenn der DAC die SDA Leitung nicht in Beschlag hätte)? Welche Device Adressen haben denn die DACs und das EEPROM genau? Der DAC muß ein b'00011(A1)(A0)' haben. Da wäre ein 0x1D auch eine mögliche DAC Adresse (bei A1,A0 = 1,0), wobei ja das letzte Bit der 0x1D eine "Lese"-Anweisung wäre. Was sagen denn überhaupt die Status-Bits bei der IIC-Übertragung des Controllers. Die müssen Dir doch irgend einen Fehler anzeigen. Oder wertest Du die gar nicht aus? (Wenn ich mir Dein Bild "falling_SDA_SCK" ansehe, dann könnte man dort schon - mit Wohlwollen - einen Fehler rein interpretieren. Der DAC gibt an eine 50ns Spike Unterdrückung zu haben und erkennt einen H-Pegel ab 0.7xVDD. Jetzt könnte nach ca. 50ns durch das Gewackel auf der SCL-Leitung doch noch mal ein H erkannt werden. Das wäre dann tatsächlich eine Start-Anweisung.) Gruß TK
Ja, das hast du richtig verstanden. Durch den Abbruch steht im Statusregister TWI_SR das TXCOMP sowie TXRDY auf 0. Die Adressen sind auf 0x0E und 0x0F konfiguriert. Den von dir interpretierten Fehler verstehe ich leider nicht. Das "Gewackel" auf SCL kratzt nach der eigentlichen fallenden Flanke die 1V Marke gerade so an. 0,7xVcc sind aber 2,3V. Es ist eventuell kein eindeutiges Low mehr (0,3xVcc) aber deswegen darf es doch noch kein High sein. Oder meinst du dass die fallende SCL-Flanke um 50ns versetzt erkannt wird? Müsste dann nicht auch SDA verzögert werden? Leider wäre die Start-Condition dann auch an der falschen Stelle. Sie müsste an der sechsten fallenden Flanke von SCL im ersten Bild des Threads auftreten. Dort ist aber SDA die ganze Zeit Low.
Wie sieht denn die Stromversorgung aus? Alles nach Datenblatt angeschlossen (Abblockkondensatoren)?
Ja, die beiden für Vdd geforderten Kapazitäten von 10u und 100n sind vorhanden. Die Versorgungsspannung sieht auch durchgehend hervorragend aus.
Angehängte Dateien:
Hallo Christian,
ich hatte im Bild die Null-Linie falsch interpretiert und so den
"Undershoot" für die Null-Linie gehalten. Was ich meinte war im Bild der
rosa Bereich. Die Spikeunterdrückung greift für 50ns nach der SCL
H-L-Flanke.
Es ist jetzt nicht ganz sauber eingezeichnet - aber es verdeutlicht, was
ich meinte. Nach 50ns könnte das Wackeln evtl. auch mal über den Pegel
gehen!?! Das muss ja nicht die gezeigte Stelle im Bild sein, sondern
kann ja schon weit vorher passiert sein. Und weil eben auch SDA mit der
Spikeunterdrückung beaufschlagt ist, würde der SDA-Pegel "sauber" auf L
liegen, während SCL "gerade" über den H gewackelt ist.
Normalerweise kann auch eine Start-Bedingung, die nicht im normalen
Taktzyklus kommt, den Bus wieder zurücksetzen.
Und die Device-Adresse des EEPROMs wird wohl 0xA0 sein.
Vielleicht sollten wir auch noch mal über die Device-Adr Interpretation
reden: DAC Device Adr = b'00011(A1)(A0)' + R/W-Bit! Bei Deiner
Konfiguration von A1,A0 = 1,0 für DAC1 und 1,1 für DAC2 ergeben sich
Adressen von 0x1C (Schreibzugriff DAC1), 0x1D (Lesezugriff DAC1), 0x1E
(Schreibzugriff DAC2) und 0x1F (Lesezugriff DAC2). Das sind die
möglichen 7-bit Adresse + 1-bit R/W. Du schreibst weiter oben:
>Dann sendet der Master 0x1D und der DAC mit Addr 0x0E fühlt sich >anscheinend zu
einem Lesezugriff aufgefordert.
Das würde ich so unterschreiben. Hast Du evtl. einen Denkfehler bei der
Device-Adr Übergabe?
Gruß
TK
Die Timingerklärung klingt sinnvoll aber es gibt neue Beobachtungen, die wohl eher dagegen sprechen. Mehr dazu am Ende. Zu den Adressen: Wenn ich von Adressen rede, dann meine ich die 7Bit-Adressen - deswegen 0x0E und 0x0F. Dazu kommt dann das R/W-Bit, wodurch sich die Adresse verschiebt/erweitert und die von dir genannten 4 möglichen ersten Bytes des Transfers entstehen. Ich trenne Adresse und Kommandobit gerne, da ich in den C-Funktionen auch nur die 7Bit angebe, die dann je nach Zugriff zum vollen Byte verwurstet wird. Das EEPROM hat das Startbyte 0xA2 (Addr + Wr). Nun zum Neuen: DAC2 (0x0F) hängt am Bus, DAC1 nicht mehr. Ich habe die Sequenz nun mal Stück für Stück auseinandergenommen und verändert. Am Ende steht nun eine Sequenz, die abgesehen von den EEPROM-spezifischen ersten 3 Bytes, bis auf ein "spezielles" Byte nur aus 0xFF-Bytes besteht. Das spezielle Byte hat den Wert 0x1F. Die Sequenz hab ich nun mehrfach aufgerufen und dabei das spezielle Byte jeweils um ein Byte nach hinten geschoben. Jetzt das Spannende: Immer nur wenn sich das 0x1F-Byte an einer Position nach dem Muster x*8 befindet (Das Erste Byte/Adressbyte in der Sequenz zähle ich als 0) grätscht der DAC dazwischen. (0x1F = Leseoperation) Als Bsp: 0xA2-0x01-0x00-0xFF-0xFF-0xFF-0xFF-0xFF-0x1F___Rums oder: 0xA2-0x01-0x00-0xFF-0xFF-0xFF-0xFF-0xFF-0xFF-0xFF-0xFF-0xFF-0xFF-0xFF-0x FF-0xFF-0x1F___Rums usw... Ich verstehe das allerdings nicht. Für mich spricht diese Beobachtung aber dafür, dass das Timing nicht die Ursache ist, denn der Master agiert auf Byte-Ebene. Da wird ein Byte wie das andere behandelt. Es gibt keinen Grund warum da alle 8 Bytes etwas besonderes passieren sollte. Ich glaube nun noch etwas mehr an einen Bug oder eine unsaubere Interpretation des I2C im AD5696. Grüße Christian
Übrigens ist Deine Sequenz 0xA2... ja ein Schreibvorgang ins EEPROM an die Adresse (0x0100). >Es gibt keinen Grund warum da alle 8 Bytes etwas besonderes passieren >sollte. Doch! Was sagt denn das EEPROM, wenn Du die PAGE-Größe mit Deiner Testsequenz überschreitest? Ist die evtl. genau 8Bytes? Welches EEPROM hast Du überhaupt im Einsatz? Vielleicht liegt ja hier das Problem und nicht beim DAC? Ansonsten: Um diese Theorie mit einem unsauber implementierten IIC im DAC zu verifizieren, probiere mal ein Muster (anstatt Deiner 0xFF) jetzt ein Muster (0x55). Und weiterhin an den gleichen Stellen wieder ein 0x1F. Wenn das Problem dann weg ist, liegts tatsächlich am DAC. Es ist nämlich so, dass ein z.B. aufgehängtes EEPROM durch mehrmaliges clocken bei SDA=1 wieder zum "leben" erweckt werden kann. Vielleicht ist das beim DAC genauso. Der hat sich irgendwo mitten in der Übertragung aufgehängt und wird jetzt durch senden von Deinen 0xFF wieder zum aktiven Busteilnehmer. Gruß TK
Hi TK, das EEPROM ist ein CAT24C512 mit 128Byte Pagesize. Dem DAC schein egal zu sein mit welchem Wert man die 0xFF-Bytes ersetzt. Hab verschiedene Muster getestet. Das 0xFF-Muster eignet sich nur besonders gut, um ein ziehen an der SDA Leitung durch eine zweite Quelle früh zu erkennen. Wie meinst du kann ein anderer Slave außer dem DAC die Ursache sein? Wenn der Zustand eintritt, dann hilft es, wie beschrieben, den DAC (und wirklich nur diesen einen DAC) per Reset zurück zu setzen und alles läuft wieder wie vorher. Das sieht für mich nach einem klaren Beweis für den DAC und gegen andere Slaves aus. Würdest du das anders interpretieren? Grüße Christian
Hallo Christian, so langsam bin ich jetzt auch mit dem Versuch der Analyse durch. Momentan fällt mir erst mal nichts mehr ein. Wenn man mal nach AD5696 und Problem gurgelt, dann kommt man interessaterweise direkt hier ins Forum. Also haben noch nicht so viele ein Problem mit dem DAC gehabt. Ein Vorschlag wäre auch mal sich direkt an den Support bei Analog zu wenden. Vielleicht wissen die ja mehr als im Datenblatt steht. Mist - ich war letzte Woche in Nürnberg auf der PCIM / Sensor+Test bei denen am Stand. Gruß TK
Hi all, Do you have a work around to this problem or some resolution? I have the same problem but with AD5697R probably using same i2c interface block . We have two 24lc512 NV memory, two PCA9555 and AD5697R on the ARM CPU i2c bus. On some address reading the NV memory the SDA gets stuck to LOW and will be released eventually after a 100 or so clocks. We disconnected all of the devices one by one and it was AD5697R that causing the problem. Just trying the chip itself we found that if you do reading of odd number of bytes, the chip holds SDA low after the stop - this explain why the SDA goes low but doesn't explain why it gets activated when it is not addressed? regards, Magda
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.