DOG XL 240-7 antwortet ab und zu mit NAK?

[Michael R. (Firma: Brainit GmbH) (fisa)]

Guten Morgen allerseits,

ich hab hier ein EA DOG XL 240-7 über I2C an einem ATmega328P. 
Grundsätzlich funktioniert alles, nur ab und zu (1-2 mal pro Minute) 
krieg ich beim Senden von Daten ein NAK zurück.

Beim Schreiben einer (Grafik-)Zeile wird zuerst Column- und Page Adress 
gesendet, dann ein Dummy-Read durchgeführt (keine Ahnung warum das 
notwendig ist) und danach alle 240 Byte geschrieben. Dazwischen liegen 
"repeated starts".

Und hier kriege ich fallweise ein NAK zurück, nach unterschiedlich 
vielen Bytes (mal nach 10-20, mal nach 200)

Nach diesem NAK breche ich die aktuelle Operation ab, im nächsten 
Durchlauf funktioniert wieder alles problemlos.

Ganz selten krieg ich auch ein "Arbitration lost", was ich mir in einem 
Single-Master-System schon gar nicht erklären kann...

I2C läuft mit 100kHz. Signale sehen sehr sauber aus.

der AVR läuft mit 5V/12 MHz, das Display mit 3.3V, dazwischen hängt 
sogar ein PCA9515 als Pegelwandler. Pullups sind 4k7 (jeweils am AVR und 
am Display) und 10k am Pegelwandler.

ich bin mir nun nicht sicher, was mir das Display damit sagen will. Für 
"ich hab grad keine zeit" wäre ja eigentlich Clock-Stretching 
vorgesehen.

Oder ist es üblich, mit NAK ein "Warten" bzw. ein Retry anzufordern?

[Crazy Harry (crazy_h)]

Hi Michael,

ich hab leider keine Antwort auf deine Fragen, aber eine Frage an dich: 
Woher hast du das Display ? EA verkauft nicht an privat ..... oder du 
bist ne Firma ?
Übrigens: wenn das der selbe Murks wie beim DOGXL160 ist nimm SPI. Ist 
viel schneller. Mehr als 100kHz wirst du dank des relativ hohen 
Innenwiderstandes bei I2C (und der damit recht hochohmigen Pullups) 
nicht schaffen.

Gruss
Harry

Datenblatt:
> Beachten Sie bei der Auswahl der Pull-up Widerstände, dass die
> Anschlusspins SDA+SCK einen Innen-widerstand von ca. 600..1000 Ohm,
> evtl. auch mehr haben (betrifft LO-Pegel beim Lesen von Daten bzw.
> dem ACK-Bit).

[Michael R. (Firma: Brainit GmbH) (fisa)]

Crazy H. schrieb:
> Hi Michael,
>
> ich hab leider keine Antwort auf deine Fragen, aber eine Frage an dich:
> Woher hast du das Display ? EA verkauft nicht an privat ..... oder du
> bist ne Firma ?
Ich bin zwar eine Firma :-) aber die kann man auch privat z.B. bei 
Reichelt kaufen.

> Übrigens: wenn das der selbe Murks wie beim DOGXL160 ist nimm SPI. Ist
> viel schneller. Mehr als 100kHz wirst du dank des relativ hohen
> Innenwiderstandes bei I2C (und der damit recht hochohmigen Pullups)
> nicht schaffen.

Es ist Murks, aber SPI ist in dem Fall keine Option, Master-Board (AVR) 
hat nur i2c nach außen vorgesehen.

[Crazy Harry (crazy_h)]

Michael Reinelt schrieb: ne Firma ?
> Ich bin zwar eine Firma :-) aber die kann man auch privat z.B. bei
> Reichelt kaufen.
Ahhhh ok danke. Vor 2...3 Wochen gabs die bei Reichelt aber noch nicht 
;o)

[spess53 (Gast)]

Hi

>Ahhhh ok danke. Vor 2...3 Wochen gabs die bei Reichelt aber noch nicht

Der Preistrend des Displays fängt am 18.12.2013 an. Die gibt es schon 
länger.

>Es ist Murks, aber SPI ist in dem Fall keine Option, Master-Board (AVR)
>hat nur i2c nach außen vorgesehen.

Welcher AVR ist es denn? Alle neueren AVRs können SPI auch mit der/den 
USART(s)-> USART im SPI-Mode.

MfG Spess

[Michael R. (Firma: Brainit GmbH) (fisa)]

spess53 schrieb:
> Welcher AVR ist es denn? Alle neueren AVRs können SPI auch mit der/den
> USART(s)-> USART im SPI-Mode.

Hab mich falsch ausgedrückt: der AVR (ATmega328P) kann natürlich SPI, 
aber die Platinen (sowohl diverse Master mit AVR als auch das 
"Interface" zum Display mit Spannungserzeugung für Backlight) sind 
fertig und haben nur i2c vorgesehen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Ich glaub ich hab einen Hinweis gefunden... sehts euch mal die 
Oszi-Bilder von SDA/SCL an. Der "Peak" auf SDA dürfte wohl so nicht 
sein, oder?

Jetzt muss ich nur noch draufkommen, wer den macht :-(

[spess53 (Gast)]

Hi

>Jetzt muss ich nur noch draufkommen, wer den macht :-(

Ich würde spontan auf zu große Pull-Up-Widerstände tippen.

MfG Spess

[Michael R. (Firma: Brainit GmbH) (fisa)]

spess53 schrieb:
> Ich würde spontan auf zu große Pull-Up-Widerstände tippen.

Hmmm... glaub ich erstmal nicht.

Ich hab mal versucht das erste Oszi-Bild zu analysieren. Dabei habe ich 
mich am "kleine" Höcker auf SDA orientiert, ich gehe davon aus das ist 
ein ACK vom Slave (der SDA nicht ganz auf 0V ziehen kann, praktisch zur 
orientierung) Den hab ich mal rechts orange markiert. Dann weiter nach 
links, 8 Bit. Dann kommt mein "Peak", und davor eine ganz normales 
sauberes START (wieder orange markiert): SCL = High, SDA wechelt von 
High auf Low.

Nachtrag: Eigentlich müsste es ein "Repeated Start" sein. Kann auch so 
stimmen, kommt im Code so vor.

a) Der Peak tritt auf, während SCL Low ist => da darf SDA sogar 
wechseln, ist zwar unschön, sollte aber kein Problem sein.

b) ich vermute, mein Code schickt das START, nach vollendetem Start gibt 
TWI erstmal SDA und SCL frei, deshalb geht SDA richtung High. Dann kommt 
vermutlich ein interrupt, der die weitere Verarbeitung etwas verzögert, 
SDA hat also mehr Zeit, über den Pullup nach High zu gehen. Dann kommt 
wieder mein i2c-Code, lädt das SLA+RW, damit geht SDA wieder auf Low.

Wenn meine Vermutung stimmt, ist das zwar unschön, aber problemlos. 
Hoffe ich halt.

Leider habe ich damit immer noch keine Erklärung für mein eigentliches 
Problem :-(

Vielleicht nochmal meine zentrale Frage: Was bedeutet ein NAK vom Slave 
auf ein Write? "gib mir mehr zeit, und probiers nochmal", oder eher "es 
ist was faul im Staate Dänemark"?

[Frank (Gast)]

Michael Reinelt schrieb:
> Vielleicht nochmal meine zentrale Frage: Was bedeutet ein NAK vom Slave
> auf ein Write? "gib mir mehr zeit, und probiers nochmal", oder eher "es
> ist was faul im Staate Dänemark"?
Das hängt von der Realisierung im  Slave ab.
Du kannst ja mal den Support von EA kontaktieren.

Grüße,
Frank

[Michael R. (Firma: Brainit GmbH) (fisa)]

Wieder neue Erkenntnisse:

ich hab einen freien Pin des AVR verwendet, um dort ein "Triggersignal" 
fürs Oszi auszugeben (auf die idee hätt ich auch schon viel früher 
kommen können!)

Dann hab ich auf i2c START den Trigger gegeben, und versucht meinen 
"Peak" zu finden. Das ist mir (leider?) nicht gelungen. Alle 
START-Sequenzen sehen ganz ganz sauber aus.

Ich müsste mich vielleicht noch mal mit den diversen Trigger-Optionen 
meines Rigol spielen. Ich glaube der kann auch auf "Impulsbreite < x" 
triggern...

Auch meine Interrupt-Theorie von oben musste ich verwerfen: So wie der 
Code aussieht, wird TWINT erst gelöscht (und damit der TWI-Hardware 
erlaubt, SCL wieder freizugeben) wenn SLA+RW bereits geladen ist. Selbst 
wenn hier ein Interrupt auftreten würde, wäre maximal die low-Phase von 
SCL verlängert. Es kann aber (zumindest aus meiner Sicht) nicht dazu 
kommen, dass er es sich im letzten Moment "anders überlegt".

Aber, viel interessanter: Mithilfe des Triggersignals kann ich jetzt die 
sporadisch auftretenden NAKs identifizieren und visualisieren. Siehe 
Bilder. Man sieht sehr schön die vorhergehenden ACKs, gesendet werden 
meist nur Nullen (die Zeile am Display wird gelöscht), bis irgendwann 
ein NAK kommt. Und das ist ein so sauberes NAK, schöner gehts nicht. Ich 
schließe also Störungen und falsche Pullups hiermit aus.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Der Peak ist weg!

Tatsächlich kann mein Oszi auf "kurze Impulse" triggern, damit konnte 
ich den Peak nachvollziehbar visualisieren. Er war nämlich sehr wohl 
noch da...

Meine Interrupt-Theorie muss ich auch wieder aufleben lassen: es scheint 
so zu sein, dass das TWI nach der Start-Condition gleich das MSB des 
TWDR auf den Bus gibt. Nachdem üblicherweise das SLA+RW erst nach 
erfolgreichem START nach TWDR geladen wird, ändert sich u.U. das MSB. 
Das ist, wie schon festgestellt, unkritisch, da zu dem Zeitpunkt SCL 
noch auf Low liegt, aber unschön :-)

Einfache Abhilfe: schon bevor die START-Condition auf den Bus gegeben 
wird, TWDR bereits mit SLA+RW "preload"en, dann gibts keinen Peak mehr.

Löst zwar immer noch nicht mein Problem, aber immerhin...

[Michael R. (Firma: Brainit GmbH) (fisa)]

so, nun scheint alles zu funktionieren. Ich hab in allen i2c-routinen 
die mit dem Dog sprechen, ein retry eingebaut. Es kommen zwar nach wie 
vor ab und zu die Fehler, aber mit dem retry scheints stabil zu 
funktionieren.

EA kann man hier ohnehin keinen Vorwurf machen, "Schuld" dürfte der 
verkorxte Controller UC1611s sein (allein schon dass der für 
Command/data zwei verschiedene I2C-Adressen belegt...)

Falls Interesse am Code besteht, kann ich den gerne posten (oder 
vielleicht gleich unter "Projekte und Code" hochladen?)