Hallo, ich habe Probleme mit dem Touch Sensor AT42QT2160. Im Anhang Schaltung und Layout. Einmal das Layout rangezoomt mit beiden Layern eingeblendet. (Fehler in der Schaltung R5 und R6 sind nicht 1k sondern 1M) Das Problem an der Sache, der Change Pin ist konstant auf low. Eigentlich sollte der Pin nach dem Start bzw. Reset kurz auf low gehen (Calibrierung) und anschließend auf high. Was ich bisher versucht/geprüft/getestet habe: Hardware: 1. Layout überprüft auf Fehler (Falsche Pins/Layout Fehler usw.) 2. Kurzschluss zwischen zwei benachtbarten Pins bzw. Kurzschluss zwischen Pin und GND beim löten. 3. Alle 1k Widerstände zu den Touch Flächen entfernt. 4. Zweiten IC auf zweite PCB gelötet. 5. Spannung bricht beim start nicht ein, mit Oszi angeguckt. Software: 1. Reset pin dauerhaft auf low ==> Change geht auf high, da 10k PullUp. Daraus schließe ich, dass der IC nicht defekt ist. 2. Abfrage der Device ID im Register 0x00. Hierfür habe ich die Geräte Adresse 0x0D verwendet. (Beide I2C Pins auf low) Signal wird korrekt ausgegeben (Mit LA geguckt) 3. Verschiedene Register versucht zu beschreiben, ohne Erfolg. Was könnte ich noch versuchen? Wo könnte mein Fehler liegen? Würde mich über jegliche Vorschläge freuen. Gibt es einen Fehler in der Schaltung oder im Layout?
Angehängte Dateien:
-
Zoom_Layout.png
47 KB
:
Bearbeitet durch User
Versuche deine Schaltung zu erkennen. Wenn ich es richtig sehe arbeitest du mit dem I2C Bus ???? Wenn das so ist, wird der IC erkannt?
Versuche deine Schaltung zu erkennen. Wenn ich es richtig sehe arbeitest du mit dem I2C Bus ???? Wenn das so ist, wird der IC erkannt? Widerstände zu 5V drin?
Lieber Klars schrieb: > Versuche deine Schaltung zu erkennen. Wenn ich es richtig sehe arbeitest > du mit dem I2C Bus ???? Wenn das so ist, wird der IC erkannt? > Widerstände zu 5V drin? Ja, der IC ist über I2C angeschlossen, wie oben erwähnt. Was meinst du mit "erkennt"? Ich habe versucht die Device ID abzufragen, ohen erfolg. PullUps sind drin, sonst wäre das verhalten wie oben nicht möglich. Christian S. schrieb: > 1. Reset pin dauerhaft auf low ==> Change geht auf high, da 10k PullUp.
Zumindest ist in Christian S. schrieb: > Zoom_Layout.png CHG und GND vertauscht beschriftet. Christian S. schrieb: > Hierfür habe ich die Geräte > Adresse 0x0D verwendet. Das hängt von der benutzten I²C Library ab. Wenn die Library die 8-bit Syntax für Adressen benutzt, ist 0x0D nicht richtig und es sollte 0x1A benutzt werden, das LSB ist dann bereits das R/W Bit. (Also 0x1A zum Schreiben und 0x1B zum Lesen) Zum Lesen muss erst mit gelöschten R/W Bit Register Adresse 0 gesetzt werden. Es folgt eine STOP Condition mit direkt folgendem START. Dann kommt ein Read Zugriff auf Register 0 und dann kommen die Daten
:
Bearbeitet durch User
Christian S. schrieb: > müsste so korrekt sein... Ich sehe im ersten Byte, das der Chip kein ACK sendet, sondern auf high geht (NoACK). Die Adressierung scheint also nicht korrekt zu sein. Wenn du dann 0x1B sendest (3.Byte), antwortet der Chip ja mit ACK, weil das für ihn eine korrekte Adressierung zum Lesen wäre. Sende also im ersten Byte mal 0x1A statt 0X0D und schaue auf dem LA, was passiert.
:
Bearbeitet durch User
Angehängte Dateien:
-
AT_id_LA2.png
38 KB
Wo siehst du da an NACK? Ich habs aus Verzweiflung tortzdem gemacht.
Klaus schrieb: > Christian S. schrieb: >> Wo siehst du da an NACK? > > Ein N auf rotem Grund > > MfG Klaus Schön das du nur den einen Beitrag gelesen hast. Die Frage bezieht sich auf den Screenshot zuvor.
Wenn nach dem 9. SCL Puls SDA auf high bleibt, ist das ein NACK. Fühlt sich der I²C Slave angesprochen, würde er SDA auf Low ziehen. Dein neuer Screenie zeigt, das der Chip gar nicht reagiert, was er oben beim 3. Byte aber gemacht hat.
:
Bearbeitet durch User
Angehängte Dateien:
-
i2c_erfolg.png
37 KB -
i2c_erfolglos.png
35 KB
Ich habe gestern noch ein wenig getestet, leider ohne Erfolg. Heute habe ich es erneut versucht. Dabei hat es funktioniert. Allerdings sehr unregelmäßig. Im Anhang ein Screenshot des LA. Warum antwortet der IC aber teilweise nicht mit einem noACK (zweiter Screenshot im Anhang), wohl die Adresse korrekt ist? (IC beschäftigt?) Komme ich zum Erfolg, wenn ich so lange den ersten Befehl schicke, bis der IC mit einem noACK antwortet? Und erst dann schicke ich das von mir gewünschte Register? Wie lange warte ich bis ich den Befehl erneut sende? Ich habe im Datenblatt keine Zeit bzw. Hardware funktion gefunden, welche mir das signalisiert.
Christian S. schrieb: > bis > der IC mit einem noACK antwortet? Das wäre ja genau falschrum, denn er soll ja mit ACK antowrten, also nach dem 9. SCL Puls die Leitung auf Low ziehen. Ich sehe genau ein einziges Mal ein ACK, und zwar im letzten Byte des 2. Screenies. Auch hier kommt das ACK sehr spät, als wäre dein I²C Takt viel zu hoch. Vom verwendeten Takt und auch vom Controller hast du ja noch nichts gesagt. Man sieht, wie der Master immer brav die Leitung auf high gehen lässt, um dem Slave die Chance auf ACK zu geben (Slave müsste die Leitung ja auf low halten für ACK), aber der tuts halt meistens nicht.
:
Bearbeitet durch User
Angehängte Dateien:
Matthias S. schrieb: > Auch hier kommt das ACK sehr spät, als wäre dein I²C Takt > viel zu hoch. Habe ich auch überlegt, ist aber aktuell bei 47,6kHz. (100kHz sollte der IC schaffen, Ergebnisse bei 160kHz sind identisch wie bei 47,6kHz) Matthias S. schrieb: > Vom verwendeten Takt und auch vom Controller hast du ja > noch nichts gesagt. MCU nutzte ich einen 8Bit AVR mit Software I2C. Ich hatte bisher nie Probleme mit der Software I2C. Habe am selben bus einen HC1080 von TI sowie einen DS1631 von Maxim hängen, die ohne Probleme korrekt antwortet. Im Anhang nochmal ein Screenshot von der eigentlich korrekten Kommunikation, aber mit falscher Antwort. Bei den ersten drei Bytes hält der Slave SDA auf LOW beim 9. Bit, gibt aber als Registerinhalt 0xFF aus.
Die I2C-Signale sind reichlich suspekt. Wenn es sich beim Master um ein Hardware-I2C handelt, müssten die SCL-Pulse recht genau gleich lang sein - sind sie aber bei weitem nicht. Selbst bei einem Software-Master sollte ein derart grobes Missverhältnis nicht sein. Oder die Abtastrate des LA ist unbrauchbar niedrig bzw. die Signalpegel sind jenseits von Gut und Böse, d. h. die Bilder haben wenig mit der Realität zu tun. Wenn es tatsächlich gelegentlich solche "Nadelimpulse" gibt, wär's nicht überraschend, dass die Eingangsfilter (die ja gerade bewusst eingebaut werden) die einfach wegbügeln (der Chip kann ja nur bis 100 kHz). Wie hoch ist der I2C-Takt? Vielleicht mal um den Faktor 10 runter setzen.
A. B. schrieb: > Wie hoch ist der I2C-Takt? Vielleicht mal um den Faktor 10 runter > setzen. Oh, wir haben gleichzeitig einen Beitrag verfasst. Lies bitte zwei drüber was ich da zu Takt und MCU geschrieben habe. :) Den Takt um ein 10-faches kleiner werde ich mal versuchen...
Angehängte Dateien:
-
5kHz.png
38 KB
A. B. schrieb: > Oder die Abtastrate des LA ist unbrauchbar niedrig bzw. die Signalpegel > sind jenseits von Gut und Böse, d. h. die Bilder haben wenig mit der > Realität zu tun. Hab einen 16 Kanal China LA und taste mit 1MHz ab. Die kleinen Spikes die du angesprochen hast sind "korrekt" vom LA gelesen, die habe ich mit dem Oszi ebenfalls. Im Anhang ein Screenshot mit einer Bus Geschwindigkeit von 5kHz. Geändert hat sich leider nichts.
Christian S. schrieb: > Geändert hat sich leider nichts. Oh doch, die Pulslänge von SCL ist jetzt relativ gleichmäßig, das sieht schon mal viel schöner aus. (Aber bei dieser Soft-I2C-Implementierung scheint es doch ansehnliches Verbesserungpotenzial zu geben, mal ganz euphemistisch formuliert.) Wenn das Bild so bis zum Ack nach dem "Data Write" reproduzierbar stabil ist, umso besser. Dass beim "Address Read" kein Ack kommt, ist eigentlich nicht weiter überraschend, wenn man das Erratum am Ende des Datenblatts liest. Offenbar ist das I2C-Interface nicht so ganz I2C-konform. Es geht aus dem Datenblatt nicht klar hervor, ob eine "Repeated Start Condition" (d. h. ohne vorherige "Stop") zulässig ist: "It is possible to stop the write after the address pointer is sent if no data is required to be written to the device. This is done when setting the address pointer for reading data." Das kann man durchaus so interpretieren, dass eine "Stop" nach dem "Address Write" folgen MUSS, insbesondere im Zshg. mit dem Erratum. PS Dass es mit DS1631 geht, ist hier kein Argument. Der darf erstens bis zu 400 kHz, und zweitens sagt dessen Datenblatt ja gerade ausdrücklich, dass nach dem Senden der Adresse genau diese "Repeated Start Cond." folgen MUSS.
A. B. schrieb: > Das kann man durchaus so interpretieren, dass eine "Stop" nach dem > "Address Write" folgen MUSS, insbesondere im Zshg. mit dem Erratum. Ich verstehe das Datenblatt genauso. Es muss eine STOP Bedingung nach dem Setzen der Registeradresse kommen und dann eine START Bedingung und Leseadressierung des Chips. Habe ich allerdings erstmal beiseite geschoben, weil der Slave ja auch kein ACK bei den ersten paar Bytes (0x0D oder so) antwortet - da ist noch was anderes im Busch.
:
Bearbeitet durch User
A. B. schrieb: > Das kann man durchaus so interpretieren, dass eine "Stop" nach dem > "Address Write" folgen MUSS, insbesondere im Zshg. mit dem Erratum. Stimmt, wird auch klar auf S. 22 beschrieben und in der Grafik dargestellt. Ich bin davon ausgegangen, dass I2C korrekt umgesetzt wurde. Danke für eure Hilfe!
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.