Hallo zusammen, ich nehme gerade ein altes Projekt wieder auf, in dem ein TMC222-Mikroschritt-Schrittmotorcontroller verbaut ist. Als ich mit dem Projekt damals angefangen habe, habe ich festgestellt, daß der die I2C-Anbindung nur bis zu einem I2C-Takt bis 250kHz korrekt funktioniert. Laut Datenblatt (März 2011) schafft der TMC222 allerdings bis zu 350kHz. Getestet wurde mit insgesamt drei I2C-Implementierungen auf zwei Plattformen. Immer ergab sich die "magische" 250kHz-Grenze. Ist es für mich wichtig, ob ein Datentelegramm jetzt statt 201µs ganze 290µs dauert? Ja, ist es! Ein kürzeres Datentelegramm würde mein Projekt deutlich vereinfachen. Bin ich mit der Beobachtung, daß der TMC222 nur 250kHz schafft allein? Oder gilt für den Bereich zwischen 250 und 350kHz irgendeine Besonderheit zu beachten? Viele Grüße W.T.
Wie groß sind die Pullups? Wo sind die Pullups? Wie lang sind leitungen? hast du mal nen Oszibild von den Signalen?
uwe schrieb: > Wie groß sind die Pullups? Wo sind die Pullups? Wie lang sind leitungen? > hast du mal nen Oszibild von den Signalen? Pull-Ups sind 2k2, I2C-Länge ist (wenn kein Logger dranhängt) <5cm und die Signale sehen auf dem Oszi aus wie gemalt. Zumindest bis zu dem Zeitpunkt, wenn der TMC222 den Clock bis in alle Ewigkeit stretcht. Ich kann aber heute abend nochmal ein Bild machen.
:
Bearbeitet durch User
Versorgungsspannung >8v und erster Befehl getfullstatus1, auf den der chip auch nicht unbedingt antworten braucht wegen Bug.
chris schrieb: > Versorgungsspannung >8v und erster Befehl getfullstatus1, auf den der > chip auch nicht unbedingt antworten braucht wegen Bug. Gibt es zu diesem Bug eine Beschreibung? Tatsächlich mache ich am Anfang ein getfullstatus1 (und prüfe auch den Rückgabewert). Es kann tatsächlich sein, daß hier schon ein falscher Rückgabewert als Fehler aufgefaßt wird. Es kann auch sein, daß mein Todes-clock-stretching schon hier auftritt. Ich weiß nur, daß bei meinen Exemplaren bei <250kHz die Antwort immer stimmte. Hat jemand einen TMC222 mit vollen 350kHz in Betrieb?
:
Bearbeitet durch User
Gab es, der Link den ich hatte geht auf ein 404 auf der Trinamic Seite. Zusammenfassung ist, Der Reset ist nicht sauber implementiert und der erste getfullstatus1 liefert falsche Werte und löst gleichzeitig einen internen Reset aus. Danach passt es.
OK, es war genau das: Ich hatte (entgegen obiger Angaben als erstes ein "setmotorparam" und kein getfullstatus1 - irgendwie muß ich (eine ältere Version des) Datenblatt(s) so gelesen haben, daß ein getfullstatus1 nur vor der ersten Bewegung erfolgen muß, nicht vor als erstes Telegramm (bzw. wußte nicht, daß das erste getfullstatus1 fehlschlagen darf). Vorher:
1 | status = tmc222_setmotorparam(i2c_addr,pParameters); |
2 | checkforerror(status); |
3 | // => I2C-Status OK
|
4 | |
5 | status = tmc222_getfullstatus1(i2c_addr,pTmcStatus1); |
6 | checkforerror(status); |
7 | // => Status OK
|
8 | |
9 | status = tmc222_getfullstatus1(i2c_addr,pTmcStatus1); |
10 | checkforerror(status); |
11 | // => Status OK
|
Diese Version funktioniert bis 250 kHz und produziert über 250kHz reproduzierbar einen "clock stretch des Todes". Nachher:
1 | status = tmc222_getfullstatus1(i2c_addr,pTmcStatus1); |
2 | //checkforerror(status);
|
3 | // => Status nicht OK!
|
4 | |
5 | status = tmc222_getfullstatus1(i2c_addr,pTmcStatus1); |
6 | checkforerror(status); |
7 | // => Status OK!
|
8 | |
9 | status = tmc222_getfullstatus2(i2c_addr,pTmcStatus1); |
10 | checkforerror(status); |
11 | // => Status OK
|
12 | |
13 | status = tmc222_setmotorparam(i2c_addr,pParameters); |
14 | checkforerror(status); |
15 | // => I2C-Status OK
|
Diese Variante funktioniert auch bis 350kHz. *) Danke für den hilfreichen Tipp! P.S.: Allerdings noch nicht zuverlässig. Aber den Grund werde ich auch noch finden.
:
Bearbeitet durch User
Angehängte Dateien:
-
waveform_i2c.png
2,7 KB
Hier wie versprochen das Oszillogramm. Wie man sieht, ist der I2C bei 350kHz sicher nicht überfordert. Es tritt leider oberhalb von 250kHz immer wieder das gleiche Phänomen auf: Die Motorsteuerung ist sehr unzuverlässig. Er kann viermal hin- und herfahren und beim fünften Mal zieht einer der Busteilnehmer SDA herunter und gibt ihn erst nach einem Neustart (Versorgung Aus-Einschalten) wieder her.
OK, war ich feststelle: Es ist immer ein getfullstatus2, bei dem sich der TMC222 aufhängt und SDA dauerhaft auf low zieht. Freitakten nach AN10216-01 I2C Manual funktioniert auch nicht. Beim ersten Takt läßt der TMC222 zwar die Leitung los - beim 9. Takt zieht er sie allerdings wieder an. Ich probiere mal testweise AN-686 zu implementieren. Am Grundproblem, daß sich der TMC222 bei "getfullstatus2" bei höheren Taktraten gerne verschluckt, ändert das aber leider nichts.
OK, ein freitakten nach der AN-686 bringt den TMC222 wirklich wieder dazu, per I2C zu kommunizieren, ohne einen Reset per Versorgungsspannung zu benötigen. Aber das ändert erst einmal nichts am grundlegenden Problem: Der TMC222 kann sich bei einem getfullstatus2 aufhängen. Und zwar nur dann, wenn der I2C-Takt >250kHz beträgt.
Kann es sein das die Spannung unter -.3V geht Im Vergleich zu gnd des Bausteins. Wenn ja braucht es 100 ohm Widerstände wie im Datenblatt beschrieben.
chris schrieb: > Kann es sein das die Spannung unter -.3V geht > Im Vergleich zu gnd des Bausteins. Wenn ja braucht es 100 ohm > Widerstände wie im Datenblatt beschrieben. Danke für den Hinweis! Aber meine minimalen Unterschwinger (Peaks) waren jetzt bei 100 Initialisierungsversuchen bei minimal -145mV. Da liegt das Problem vermutlich nicht. Mein Test besteht aus: -tmc222_init (die besteht wiederung aus) - getfullstatus1 (Ohne Auswertung ob fehlgeschlagen) - 1ms warten - getfullstatus1 - setmotorparam - 1ms warten - getfullstatus1 - getfullstatus2 -getfullstatus1 -getfullstatus2 -getotpparam -gotosecureposition -1000ms warten -setposition -evtl. I2C-Reset, wenn oben ein Fehler aufgetreten ist. Ich habe diesen Test ein paarmal hintereinander gemacht bei 350kHz, ohne das Gerät auszuschalten: 46x durchgelaufen ohne Fehler 18x Fehler bei init, erstes getfullstatus beim I2C-Empfang (timeout) 27x Fehler bei init, ab setmotorparam, wieder beim I2C-Empfang (timeout) 13x Fehler bei getfullstatus1, beim I2C-Empfang (timeout) 6x Fehler bei getotpparam, beim I2C-Empfang (timeout) Der Timeout liegt bei 800ms. Freitakten nach Analog Devices Application nach einem Fehlversuch lief immer. Bei 250kHz: 0% Fehlerquote. Der Quelltext ist nicht geheim, aber vermutlich eine Zumutung, deswegen die Beschreibung als Text.
:
Bearbeitet durch User
Man kann nicht verfolgen, wie die Übertragung passiert, ob sie gemäß Datenblatt ist oder nicht. Kannst du bitte erörtern, ob du Ack sendest oder nicht, wie im Datenblatt beschrieben ? Welchen Widerstand hast du am Hw pin, welche Betriebsspannung. Eventuell schau mal ob deine Revision des Controllers den Befehl 0x9f kennt. SW wird zum analogen Ausgang, da kannst du dann mit dem Scope dran um die Schaltung zu optimieren/debuggen. Ein HW POR beendet diesen Modus.
Achso, wenn Fehler sind, und man getstatus1 auslesen kann, kannst du das Resultat posten, eventuell passt der Motor nicht zu den Standardparametern.
Noch mal zum ursprünglichen Sachverhalt: Ich habe ein Projekt wiederaufgenommen, daß seit etwas mehr als einem Jahr brach lag. Es existierten drei I2C-Implementierungen (I2C auf STM32, I2C auf AVR, Bitbang-I2C auf beiden) auf zwei Plattformen. Alle können ein M24C02 und einen LM75 in einem Rutsch fehlerfrei auslesen, die beiden Implementierungen auf STM32 bis 400kHz, bei AVR hatte ich nicht mehr als 250kHz ausprobiert, da die Leitung dort etwas länger ist. Die Kommunikation mit einem TMC222 funktionierte immer mit bis zu 250kHz, darüber nur sporadisch. Also stellte sich die Frage: Kann der TMC222 überhaupt mit 350kHz betrieben werden, oder ist das ein Druckfehler im Datenblatt? (Es wäre ja nicht der erste gewesen. Im ersten (englischen) Datenblatt stimmte ja die Antwort auf getfullstatus1 nicht oder bezog sich auf eine andere Hardware-Revision, im deutschen war es korrekt.) Also lautete meine ursprüngliche Frage: "Betreibt jemand einen TMC222 erfolgreich bei 350kHz I2C-Takt?". Eine explizite Antwort darauf kam nicht, aber implizit lautet die Antwort "Ja." Gestern abend habe ich ein wenig Zeit mit dem Bus-Logger verbracht, und das Bild sieht mittlerweile etwas anders aus: - Die AVR-I2C-Implementierung kann nie mit 400kHz getestet worden sein, weil das Programm bei 300kHz schon nicht mehr korrekt startet. Da hat mich einfach meine Erinnerung getrübt. Die I2C-Implementierung auf dem AVR hat also einen Fehler (vermutlich in der Initialisierung). - Der STM32F103V8 sendet bei 350kHz beim Empfang unmotivierte NACKs und Start-Bedingungen, wo gar keine hingehören. Daß der TMC222 dies mit Unwillen quittiert, ist sein gutes Recht. Erstaunlicherweise tritt dieses Verhalten mit dem M24C02 an der gleichen Bus-Leitung nicht auf. Aber ich gehe davon aus, daß irgendwo in der I2C-Implementierung am STM32 auch etwas faul ist. Das werde ich in vermutlich mehreren ruhigen Stunden mit einem Logikanalysator klären müssen. - Die dritte I2C-Implementierung habe ich gestern abend nicht mehr getestet. Es war spät genug. chris schrieb: > Eventuell schau mal ob deine Revision des Controllers den Befehl 0x9f > kennt. > SW wird zum analogen Ausgang, da kannst du dann mit dem Scope dran um > die Schaltung zu optimieren/debuggen. Ein HW POR beendet diesen Modus. Scheinbar hast Du Dich mit dem TMC222 länger herumgeschlagen, oder woher hast Du diese Info? Mit "POR" meinst Du einmal wackeln? Jetzt bin ich heilfroh, die beiden Widerstände an HW/SW auf dem TOP-Layer zu haben. :-) Längsdämpfungswiderstände lassen sich leider in meinem Testaufbau nicht so leicht unterbringen, weil ich momentan keine Zugriff auf 0402-Widerstände habe. Aber kommt Zeit, kommt Reichelt.
Hier das file, delay sowie ev. init und defines solltest to checken, timing sollte so gehen.
Danke! Ich werde vor morgen abend nicht dazu kommen, es auszuprobieren, aber dann habe ich eine sichere Rückfallebene.
Sehe ich das richtig, daß Du mit Deinen i2c-Routinen ein Kommando wie "getfullstatus1" mit einem "i2csendbyte -> I2C_Read" ausführst? "I2C_Send" erzeugt ja immer eine Stop-Bedingung am Ende...
Angehängte Dateien:
-
Laengswiderstaende.jpg
370 KB
Mein defekter Bus-Logger (ca. 10% der Pakete werden falsch dekodiert, und zwar nur im letzten Bit eines Bytes, wenn eine 1 auf eine 0 folgt) hatte mich ein ganzes Stück zurückgeworfen. Viele Vermutungen, was sich auf dem Bus abspielte, haben sich schlichtweg als falsch herausgestellt. Inzwischen sind auch die bestellten SMD-Widerstände eingetroffen und wurden als Serienterminatoren am TMC222 verbaut. Das Zeug ist ja so klein, daß man beinahe eine Lupe dafür braucht. Die Hoffnung, daß jetzt plötzlich alles gut würde, und der TMC222 jetzt plötzlich mit 350kHz funktionieren würde, hatte ich zwar nicht. Aber immerhin: Mit den 47 Ohm Längswiderständen ist zumindest bei 310kHz kein einziges Paket mehr verlorengegangen, und der "clockstretch des Todes" ist auch kein einziges Mal mehr aufgetreten. Generell reichen mir die 300kHz. Aber um ein wenig Sicherheitsreserve zu haben, werde ich noch ein wenig auf der Bus-Hardware aufräumen. Danke für die Diskussion!
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.