RTB2000 I2C Probleme mit Dekodierung

[Peter D. (fenstergucker)]

Ich verwende einen Raspberry Pico mit dem picod Package [1] um ein 
AT24C02 EEPROM zu beschreiben. Das schreiben und lesen funktioniert ohne 
Fehler, auch mit anderen EEPROMS.

Mit dem R&S RTB2004 Oszilloskop wollte ich mir das Protokoll mit den 
digitalen Kanälen anzeigen lassen. Aber die Pakete werden immer in rot 
als fehlerhaft angezeigt. Auch mit den analogen Kanälen ist es dasselbe. 
Einstellungen wie Treshhold, Samplerate, 20 MHz Bandbreite, Speicher 
usw. bringen keine Besserung.

Erst wenn ich bei einen analogen Kanal die Deskew-Einstellung ändere 
funktioniert das Dekodieren ohne Fehler. Bei den digitalen Kanälen gibt 
es keine entsprechenden Einstellungen. Aber nach Änderung der Zeitbasis 
usw. muss man wieder etwas die Deskew-Einstellung ändern, oder es hift 
dann auch nicht mehr.
Das I2C Demo-Signal vom Oszilloskop selbst, wird ohne Fehler dekodiert 
und angezeigt.

Ich habe mir vor kurzem ein Tektronix MSO2024B gekauft und damit 
funktioniert die Dekodierung ohne Probleme.

Ich würde gerne verstehen wo das Problem liegt, ist es das Signal, das 
RTB2000, oder?

Peter

[1]  https://github.com/joan2937/picod

[Vanye R. (vanye_rijan)]

> Ich würde gerne verstehen wo das Problem liegt, ist es das Signal, das
> RTB2000, oder?

Ich meine das liegt an dem von dir verwendeten Triggerzeitpunkt/art. 
Also dem Zeitpunkt ab dem dekodiert wird. Ich hatte das naemlich auch 
schonmal. Ich weiss aber die Loesung nicht mehr. Spiel mal ein bisschen 
mit den diversen Triggermoeglichkeiten rum.

Vanye

[Thomas W. (goaty)]

Wenn der Fenstergucker als RTB2k Experte es nicht weiß, sehr ich 
schwarz.
Ist das 2.4 oder schon 3.0 Firmware?

[Vanye R. (vanye_rijan)]

> Ist das 2.4 oder schon 3.0 Firmware?

Sollte man die hier eigentlich mal hochladen oder wird dann R&S boese? 
:)

Vanye

[Peter D. (fenstergucker)]

Danke für die Rückmeldungen.
Ich habe so ziemlich alles ausprobiert was möglich ist, aber das Signal 
wird nicht richtig dekodiert. Nur wenn ich die Deskew-Einstellung ändere 
funktioniert es, abhängig von der Zeitbasis, und nur bei den analogen 
Kanälen.

Die Firmware ist v03.000, und ich habe sie auch im EEVblog zur Verfügung 
gestellt:
https://www.eevblog.com/forum/testgear/new-killer-scope-a-true-game-changer-from-rs-rtb2002-rtb2004/msg5876902/#msg5876902

Peter

[Thomas W. (goaty)]

Dann geht's mit 2.4 auch nicht ?
Ich vermute es ist eine Einstellung in den Bus Parametern. High/Low 
irgendwas mit der Triggerung.
Muss ich heute Mal ausprobieren.

[Vanye R. (vanye_rijan)]

Ich meine mich gerade dunkel zu entsinnen das ich von StartID auf normal 
Flanke umgestiegen um das Problem zu beheben als ich es hatte. 
Vielleicht ist das auch wirklich noch ein Bug im Decoder den R&S gerne 
beheben wird falls man sie drauf hinweist....

Vanye

[Peter D. (fenstergucker)]

Mit Usb4all von sprut.de und einem PIC18F4550, kann ich das 
I2C-Protokoll von einer DS1307 RTC ohne Probleme dekodieren.
Es liegt also wahrscheinlich an dem Signal vom Raspberry Pico. 
Vielleicht ist irgendein Parameter für das RTB2000 an der Grenze, und 
wird darum als Fehler angezeigt.

Peter

[Peter D. (fenstergucker)]

Ich habe mir ein I2C-Paket erstellt und in den Patterngenerator vom 
RTB2000 geladen. Wenn sich die SDA-Bits sehr nahe oder direkt an der 
fallenden Taktflanke ändern, dann werden die Daten nicht mehr richtig 
dekodiert bzw. in rot angezeigt.
Darum hilft auch die Deskew-Einstellung von einem Kanal.

Peter

[Vanye R. (vanye_rijan)]

> Ich habe mir ein I2C-Paket erstellt und in den Patterngenerator vom
> RTB2000 geladen.

Ah, ich hab mich schon immer gefragt wofuer ich den wohl brauchen 
koennte. :)

>  Wenn sich die SDA-Bits sehr nahe oder direkt an der
> fallenden Taktflanke ändern, dann werden die Daten nicht mehr richtig
> dekodiert bzw. in rot angezeigt.

Das ist natuerlich irgendwie unschoen. Wohlmoeglich sogar ein Bug. 
Schick denen das doch mal, vielleicht ist es dann in der 3.1 draussen. 
Man darf ja noch hoffen.

Vanye

[Thomas W. (goaty)]

Ich bin nicht auf dem laufenden, aber ist das nicht irgendwie verletzte 
Setup Time?

[Vanye R. (vanye_rijan)]

Das hab ich gerade auch schon ueberlegt, allerdings war ich zu faul 
jetzt genau die Datenblaetter zu studieren. :-D
Aber denkbar ist es. Bei dem letztdem Controller den wo ich I2C 
implementiert habe, weiss garnicht mehr wo das war, da konnte man 
erstaunlich sensibel diese Timings fuer die Flanken einstellen und da 
haette man da was falsch machen koennen.
Angesichts der Wetterlage ueberlassen wir also mal dem geneigten Leser 
dieses Threads das Studium der Datenblaetter. :)

Vanye

[Thomas W. (goaty)]

Nee das war doch Quatsch von mir, ist ja fallende Flanke, bin noch zu 
müde.

Eher Hold Time dann.

Im Handbuch hab ich nix gefunden über die Fehlerbedingungen beim 
Dekodieren, vielleicht fragt Peter mal im eevblog ob jemand sagen kann, 
welche Fehlerzustände es da gibt.

[Stefan K. (stk)]

Im NXP I2C-bus specification and user manual steht unter 3.1.3 Data 
validity:
"The data on the SDA line must be stable during the HIGH period of the 
clock. The HIGH or LOW state of the data line can only change when the 
clock signal on the SCL line is LOW (see Figure 4)."

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Wenn steigende oder fallende Flanken von SDA und SCL zusammenfallen ist 
diese Bedingung gerade nicht mehr erfüllt.

[Peter D. (fenstergucker)]

Bin zu spät, haber auch gerade nachgelesen.
In der NXP I2C Spezifikation steht bei allen I2C Modes für "tHD;DAT data 
hold time [1]" Minimum 0 µs.
Aber es gibt zwei Bemerkungen dazu :

[1] tHD;DAT is the data hold time that is measured from the falling edge 
of SCL, applies to data in transmission and the acknowledge.

[2] Ensure SCL drops below 0.3VDD on falling edge before SDA crosses 
into the indeterminate range of 0.3 VDD to 0.7 VDD.

Das RTB2000 macht es also wahrscheinlich richtig, könnte aber etwas 
laxer sein meiner Meinung nach.

Peter

[Peter D. (fenstergucker)]

Der Vollständigkeit halber noch der PureBasic-Code für das Erstellen des 
I2C-Pattern. Und das Skript für mein 'Messinstrumente-Skript'-Programm, 
um die Daten in das RTB2000 zu kopieren. Sowie die Datei mit den Daten.

Peter