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?
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
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.
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.
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.
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...
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.
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!
Zoom_Layout.png
(47 KB)
