Fehlersuche: Owon SDS7102 kein Trigger auf beiden Kanälen

[Hannes W. (hannes_w129)]

Hallo mikrocontroller.net-Gemeinde!

Mein Owon SDS7102V möchte auf beiden Kanälen nicht mehr Triggern :(
Ich weiß nicht genau, was passiert ist, da ich mich bei einer Messung 
"verdrückt" hatte. Ich habe, glaube ich auf "Save" oder "Acquire" 
gedrückt, obwohl ich "Cursors" haben wollte. Anscheinend gibt es auch 
andere mit einem nicht-funktionierenden Trigger nach Aufruf des 
Save-Menüs [6], aber ich weiß nicht, ob es das gleiche Problem ist. Ich 
habe Werkseinstellungen, Selbstkalibrierung, Firmwareupgrade, 
Firmwaredowngrade, Ein-/Ausschalten, Kanäle aktivieren/deaktivieren 
probiert, ohne das etwas funktioniert hätte, bevor ich angefangen habe, 
die Hardware zu diagnostizieren:

Input: 5V, 1kHz Rechteck aus dem Tastkopfabgleich.
Display: Signal auf dem Bildschirm ok; Offset, Spannungs- (V/DIV) und 
Zeitteilung (s/DIV) scheinen zu funktionieren.

Ein gewisser Christer Weinigel [1] hat ja Linux auf dem Scope zum Laufen 
gebracht, und auch im EEVblog gab es einiges an Reverse-Engineering, 
daher war mir schon einiges über das Innenleben bekannt, auch wenn sich 
herausgestellt hat, das es einige Unterschiede zu meiner Version gibt.

Da die Anzeige von Signalen und deren Einstellungen funktionieren, habe 
ich mal angenommen, dass alles ab DAC über FPGA bis zum SoC soweit 
funktioniert.

Der Triggerschaltkreis (siehe Skizze im Anhang, falls ich es nicht 
vergesse) besteht im wesentlichen aus einem differentiellen 
Signal-Aux-Ausgang des VGA (LMH6518, [2]), passiver 
Signalfilterung/-Konditionierung, einem 4:1 Triggermux (LMH6574, [3]), 
der aus der gefilterten Triggersignalen, das Eingestelle (AC, DC, HF, 
LF) auswählt und einem Dual PECL Trigger Komparator (ADCMP562, [4]). Der 
Komparator hat hat differentielle PECL-Ausgänge die direkt auf einen 
differentiellen Eingang am FPGA gehen.

Die Commonmode-Spannung für den Aux-Ausgang am VGA ist auf 1,31V gesetzt 
(die Gleiche wie für das normale Signal). Am VGA-Aux-+-Ausgang messe ich 
das Rechteck von 1,26V - 1,36V auf dem Oszi. Die Commonmode-Spannung 
habe ich auf dem Multimeter gemessen, vielleicht ruht der Unterschied 
daher. Das Rechteck auf dem VGA-Aux-M-Ausgang geht von ~1,15V - 1,26V; 
also zwischen den differentiellen Paaren ca 200mVpp.
Soweit ich sehe geht nur der positive Zweig vom VGA auf den Trigger-Mux, 
und das mit einem Offset ~1,26V. Der Ausgangstreiber des Trigger-Mux ist 
mit Verstärkung 2 konfiguriert, also hat das Signal am Ausgang des 
Trigger-Mux einen DC-Pegel von 2,5V. Messung und Theorie stimmen hier 
überein.
Der Triggerlevel wird über einen DAC BU2506FV gesetzt. Der DAC-Ausgang 
geht über einen RC-Filter und dann direkt auf den Komparator-Eingang. 
Einstellung des Triggerlevels am Scope verändern den DAC-Ausgang von 
0-0,5V. Damit kann der Komparator natürlich nicht triggern.

Was ist nun kaputt?

Ich habe mich an den digitalen Eingang des DAC gehangen und verifiziert, 
dass der DAC die Spannung ausgibt, die ihm vorgegeben wird.
Als Bypass-Test habe ich ebenfalls den Widerstand aus dem RC-Filter 
zwischen DAC-Ausgang und Komparator ausgelötet und an der Stelle eine 
Fremdspannung als Triggerlevel eingespeist. Eingestellt auf die richtige 
Spannung wird nun der Komparator aktiv und das Rechtecksignal springt 
nicht mehr auf dem Bildschirm hin und her, sondern steht still. Man kann 
das stehenden Signal auch mit dem Trigger nach links und rechts 
verschieben.
Daraus schließe ich, dass der Komparator, FPGA, und alles was in der 
Signalverarbeitung aufwärts davon liegt ok ist.

Was mir noch aufgefallen ist: wenn man den Triggerlevel herunter dreht, 
springt der DAC ab Bildschirmmitte auf maximale Ausgangsspannung. Wenn 
man dem Signal ein Offset ungleich 0 gibt, also die Null-Linie des 
Signals auf oder ab schiebt, springt der DAC weiterhin auf der 
Bildschirmmitte auf maximum, also bei "0 DIV", und nicht etwa bei Signal 
0V.

Es fast so, als ob dem Triggerlevel-DAC 2,5V DC-Offset fehlen. Aber die 
DAC-Ausgabe stimmt mit der Konfiguration der Ausgangsspannungen überein. 
Vielleicht ist es wirklich ein Software-Problem?

Vielleicht hat jemand noch eine Idee was ich messen könnte oder wo ich 
einen Fehler gemacht haben könnte? Oder hat jemand das gleiche bzw. ein 
ähnliches Oszi, bei dem er oder sie Vergleichsmessungen machen würde? 
Ich bin mit meinem Latein am Ende … Ich verstehe warum es nicht Triggert 
(Komparator-Eingänge wechseln nicht die Polarität) aber ich weiß nicht 
warum es nicht geht (Trigger-Level-DAC-Spannung zu niedrig oder Signal 
aus dem Trigger-Mux zu hoch?).
Ich hoffe ich habe das Problem und meine Messungen gut beschrieben, aber 
wenn man jemandem etwas erklärt, miit dem man sich eine Weile 
beschäftigt hat, vergisst man immer etwas Wichtiges … :(

Ok, danke für's Lesen und vielleicht gibt es ja Kommentare.

[1] 
http://blog.weinigel.se/2016/05/27/another-look-at-sds7102-hardware.html

[2] https://www.ti.com/lit/ds/symlink/lmh6518.pdf

[3] https://www.ti.com/lit/ds/symlink/lmh6574.pdf

[4] 
https://www.analog.com/media/en/technical-documentation/data-sheets/ADCMP561_562.pdf

[5] 
https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bu2506fv-e.pdf

[6] https://www.eevblog.com/forum/testgear/owon-sds7102v-trigger-issue/

[Uwe (Gast)]

Hi,
also wenn ich das so richtig verstehe scheint es so als wenn der 
Trigger-DAC mit falschen Werten gefüttert wird was auf Software deuten 
würde.
Ich selbst habe ein TDS8104 und von Anfang an Softwareprobleme gehabt. 
Habe ich aber alle beim Verkäufer angezeigt und bekam fast umgehend 
Hilfe direkt aus China. Leider ist der Verkäufer nicht mehr verfügbar, 
aber in Chemnitz sitzt wohl der Generalvertreter für Owon.
https://www.messgeraete-chemnitz.de
Wenn er bemüht ist gute Geräte an den Mann zu bringen wird er dir wohl 
helfen.
Die Problembeschreibung ist auf jeden Fall gut und wenn der Mann in 
China Lust hat bekommst du ein neues Update. Wenn es was Grundsätzliches 
ist bekommen alle anderen Geräte auch ein neues Update.
Viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Vielen Dank für deine Antwort.

Das SDS7102 ist leider aus 2011, das letzte Firmwareupgrade von 2014. Ob 
man nach 10 Jahren für ein 300€ (?) noch Firmware-Updates bekommt? Bei 
1000€ Mobiltelefonen ist ja schon nach rund 4 Jahren schluss.
Ich glaube Owon hat nicht einmal mehr einen Computer mit der Toolchain. 
Vielleicht sind die Quellen auch schon weg … selbst wenn die mir helfen 
wöllten, habe ich einfach Zweifel, dass sie es wirklich könnten ;)

Ich habe das Gerät 2016 (?) auch direkt aus China bezogen. Daher finde 
ich es jetzt nicht so dufte eine deutsche Firma mit meinen Problemen zu 
belästigen - die haben an mir ja auch nicht verdient. Das wäre etwas 
anderes, wenn ich über die bzw. eine Firma das Gerät bezogen hätte.

Da der eingestellte Trigger Level über Reboots erhalten bleibt, muss er 
irgendwo gespeichert werden. Die beiden Speicher, die ich gefunden habe 
ist ein I2C AT88 Crypto memory und der NAND Flash. Den I2C-Bus vom AT88 
habe ich angezapft und da scheint nur eine 
Identifizierung/Authentifizierung drüber zu laufen. Mein Plan ist jetzt:

(1) einen NAND-Dump zu machen
(2) ausschließlich(!) den Trigger Level zu ändern
(3) noch einen NAND-Dump machen
(4) Speicherstelle mit dem Trigger Level identifizieren
(5) Speicherstelle über JTAG patchen
(6) Profit.

Wenn das auch nicht klappt, wende ich mich nochmals an Owon.
Wenn das klappt, wende ich mich vielleicht auch an Owon ;)

Uwe schrieb:
> Viel Erfolg, Uwe
Vielen Dank und viele Grüße,
Hannes

PS: Inzwischen habe ich auch im EEVblog-Forum ge-cross-postet: 
https://www.eevblog.com/forum/repair/owon-sds7102-no-trigger-on-both-channels-request-for-help!/

[Uwe (Gast)]

Hi,
unter
https://www.owon.com.hk/support_Firmware_Upgrade_list4
ist ein Upgrade Namens SDS7102UP3.3  zu finden. Das ist nach meiner 
Softwaremeckerei 2015 entstanden. Haste das schon drinn?
Einen Versuch ist es jedenfalls wert. Upgrades werden nur eingelesen 
wenn sie neuer als das momentane ist.
Sehe gerade auf Seite
https://www.owon.com.hk/support_Firmware_Upgrade_list8
ist noch eins SDS7102_UP3.4

Viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Ich habe die 3.4. Die habe ich vor kurzem aufgespielt, mit der Hoffnung, 
dass es das Problem beseitigt. Allerdings sind die Firmwareupdates an 
bestimmte Seriennummernbereiche gebunden. Ich vermute wenn man da 
Irgendeine aufspielt endet das Böse. Beide von dir genannten Versionen 
passen bei mir nicht, da ich Seriennummer SDS7102131xxxx habe.

Meine Version der 3.4er Firmware ist auf Seite 6 zu finden: 
https://www.owon.com.hk/support_Firmware_Upgrade_list6 :) Trotzdem Danke 
für deine Mühe!

Kleines Statusupdate: Ich habe jetzt den NAND mehrfach ausgelesen und 
der NAND wird tatsächlich verändert. Insbesondere wird ein Bereich von 
128kiB ge-remapped. Ich denke da werden die aktuellen Einstellungen 
gespeichert.

Die Dateisystemsektoren scheinen allerdings nicht in der richtigen 
Reihenfolge im Flash zu liegen. Nicht einmal für das FPGA-Image, OS, 
etc, also statische Daten. Das Dateisystem ist auch ein Eigenbau von 
Lilliput/Owon. Ich hänge gerade daran, dass ich nicht weiß wie das 
Remapping von Sektoren/Flash Pages funktioniert. Im Moment habe ich noch 
nichts gefunden, was wie eine Mappingtabelle aussehen könnte.
Ausserdem scheinen die die OOB-Daten nicht für ECC/FEC zu benutzen. 
OOB-Daten für die Bootloader sind z.B. 0xff. Ich nehme an, die OOB-Daten 
könnten Remapping-Informationen enthalten.

Ich denke der Wert des Triggerlevels sollte ja auch im RAM liegen. Ich 
denke ich lasse das rumpfuschen im NAND erstmal und versuche die magic 
number im RAM zu finden. Der Vorteil ist auch, dass ich nichts permanent 
kaputt machen kann.

Für den Weg mit dem NAND müsste ich ja auch die OOB-Daten generieren 
können. 32 von den 64 Byte sind zwar immer 0xff und die anderen 32 Byte 
haben auch eine Struktur, aber ich weiß nicht ob ich im Moment die Zeit 
& Mühe investieren möchte, dass zu Reverse Engineeren. Obwohl 
interessieren würde mich es schon …

[Uwe (Gast)]

Hi,
du steckst da aber recht tief drin, Hut ab.
>aber ich weiß nicht ob ich im Moment die Zeit
>& Mühe investieren möchte, dass zu Reverse Engineeren. Obwohl
>interessieren würde mich es schon …
Du wirst doch jetzt nicht aufgeben wo du schon so viel Zeit und Mühe 
reingesteckt hast. Ok, der Preis steht nicht dafür aber es irgendwann 
gelöst zu haben erzeugt schon einen gehörigen Kick und macht dich nicht 
dümmer.
Manchmal reicht es schon das gute Stück für Stunden / Tage in die Ecke 
zu stellen und dann neu anzusetzen- man verrennt sich.
Öm.. einschalten, nur Trigger verstellen, ausschalten, Auslesen und dann 
die Veränderungen suchen hilft nicht?

Ich wünsche dir jedenfalls viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Uwe schrieb:

> Manchmal reicht es schon das gute Stück für Stunden / Tage in die Ecke
> zu stellen und dann neu anzusetzen- man verrennt sich.
> Öm.. einschalten, nur Trigger verstellen, ausschalten, Auslesen und dann
> die Veränderungen suchen hilft nicht?

Ja, das war bzw. ist meine Idee. Allerdings, das auf dem Flash zu 
machen. Das hat aber seine Probleme:
(1) Das Auslesen über JTAG schnarch lahm (12kiB/s, 128MiB Flash). Das 
geht dann schneller, wenn man weiß, in welcher Region man suchen muss. 
Da ich das Remapping nicht kenne, muss ich zumindest am Anfang alles 
Dumpen, um das Remapping zu Reverse-Engineeren.

(2) Selbst wenn es mir gelingt die Stelle im Flash zu finden, muss im 
neuen Flashimage vermutlich alle ECCs und Prüfsummen stimmen. Das würde 
alles noch dazu kommen.

(3) Du hast Recht mit dem Verennen. Ich habe mich darin versteift, den 
Wert im Flash zu ändern. Ich kann allerdings versuchen, die Stelle im 
RAM zu finden und dort zu ändern! Das geht erstens schneller (100kiB/s 
bei 64MiB DRAM) und zweitens fällt der ganze Firlefanz mit dem 
Dateisystem, Remapping, ECCs, CRCs weg. Dazu mache ich jetzt einen 
Memdump, verstelle den Trigger, erstelle einen Memdump … Danach den diff 
über jedes paar von Memdumps, und schließlich gibt der Schnitt aller 
Diffs mir die Adresskandidaten. Wenn es denn so funktioniert, wie 
gedacht. ;)

Meine Schnittmenge ist gerade bei 75 Adressen. Wenn sie irgendwann 0 
Elemente enthält bin ich enttäuscht :(

Viele Grüße und schönes Restwochenende!

[Uwe (Gast)]

Hi,
langsam fängt es an mich zu interessieren.
>Was mir noch aufgefallen ist: wenn man den Triggerlevel herunter dreht,
>springt der DAC ab Bildschirmmitte auf maximale Ausgangsspannung. Wenn
>man dem Signal ein Offset ungleich 0 gibt, also die Null-Linie des
>Signals auf oder ab schiebt, springt der DAC weiterhin auf der
>Bildschirmmitte auf maximum, also bei "0 DIV", und nicht etwa bei Signal
>0V.
Habe ich jetzt nicht ganz verstanden.
>springt der DAC ab Bildschirmmitte auf maximale Ausgangsspannung.
0,5V oder 5V ? Das klingt ja fast wie negative Werte(-1)
Was sagt eigentlich dein Triggerinfo unten rechts wenn du auf 0 bzw.50% 
gehst
und wo steht dann der DAC? Wenn du die Nullinie deines zu triggernden 
Signals verschiebst, was macht denn dann dein DAC?
Wenn ich deine Worte richtig deute, nichts? Das wäre bischen wenig.
nun ja, viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Uwe schrieb:
> Hi,
> langsam fängt es an mich zu interessieren.

Ist auch nicht unspannend. Alle mal besser als RTL …

>>Was mir noch aufgefallen ist: wenn man den Triggerlevel herunter dreht,
>>springt der DAC ab Bildschirmmitte auf maximale Ausgangsspannung. Wenn
>>man dem Signal ein Offset ungleich 0 gibt, also die Null-Linie des
>>Signals auf oder ab schiebt, springt der DAC weiterhin auf der
>>Bildschirmmitte auf maximum, also bei "0 DIV", und nicht etwa bei Signal
>>0V.
> Habe ich jetzt nicht ganz verstanden.

Ok, ich spreche jetzt mal nur in der Einstellung von 1V/DIV und ändere 
die auch nicht, da es sonst zu kompliziert wird. Aber soweit ich das 
verstehe, passiert beim Einstellen der Ablenkung, was da passieren muss. 
Als "Signal" verwende ich einen offenen Eingang, aber das AFE hat einen 
schwachen Pulldown im Eingang. Vermutlich könnte ich den Eingang auch 
einfach auf GND-Kopplung stellen …

Also das Signal hat an der Stelle ein DC-Offset, da beide Ausgänge des 
VGA differentiell sind. Für den ADC spielt das keine Rolle, da dieser 
differentielle Eingänge hat. Der Trigger-Mux aber nicht. Nun wird der 
negative Zweig des differentiellen Signals einfach terminiert und der 
positive geht auf den Trigger Mux. An dieser Stelle hat das Signal noch 
den DC-Offset der Common Mode Voltage.

Also wenn der Nullpunkt des Signals in der vertikalen Bildschirmmitte 
liegt, hat das Signal vor dem Trigger Mux ein DC-Offset von 1,25V und 
hinter dem Trigger Mux 2,5V, da der Trigger Mux-Ausgang Verstärkung 2 
hat.

Wenn ich den DC-Offset des Signals jetzt verstelle auf -5 Div (mein Oszi 
hat 10 Div vertikal) ist die common mode voltage bei 1V, bei +5 Div bei 
1.5V. Also bedeuten, in der Einstellung 1V/Div, +/-5V auf dem 
Oszi-Schirm +/- 250mV (also 500mVpp) nach dem AFE, insbesondere am 
Triggermux-Eingang.

In meiner idealen Welt, müsste der Trigger-DAC jetzt diese common 
mode-voltage berücksichten (bzw die Firmware, die den DAC einstellt …). 
Das passiert aber nicht. (Soweit, denke ich hattest du das Problem schon 
verstanden.)

Also Signal zurück auf 0 Div und jetzt spielen wir mal am Trigger Level 
rum: Auf der 0 Div (entspricht hier jetzt 0mV) Trigger-level gibt der 
DAC auch 0V aus. Wenn ich den Triggerlevel auf +5 Div stelle, ist die 
Ausgangsspannung 436mV, das Oszi sagt auf dem Bildschirm natürlich 
Triggerlevel 5V. Der maximale Triggerlevel liegt bei 6V, laut 
Bildschirm. An dieser Stelle gibt der DAC 525mV aus.

Dreht man den Triggerlevel auf -5 Div (-5V auf dem Display) gibt der DAC 
3.665V). Der DAC hat die 4096mV Referenzspannung und 4096mV - 436mV = 
3660mV; nah genug, oder? Dreht man den Triggerlevel maximal negativ, 
also -6V laut Display gibt der DAC 3,577V aus.

Meiner Meinung nach, müsste der Triggerlevel DAC, wenn der Trigger auf 
0V eingestellt ist und, 2,5V ausgeben. Das müsste sogar für alle 
Ablenkungen stimmen, nicht nur 1V/Div, oder?

>>springt der DAC ab Bildschirmmitte auf maximale Ausgangsspannung.
> 0,5V oder 5V ? Das klingt ja fast wie negative Werte(-1)

Genau das ist/war mein Gedanke!

> Was sagt eigentlich dein Triggerinfo unten rechts wenn du auf 0 bzw.50%
> gehst

Also den Trigger Nullen setzt den Triggerlevel auf die Nulllinie des 
Signal auf dem Bildschirm. Das Oszi sagt an der Stelle auch Trigger bei 
0.00mV. Ich nehme an, die Triggerlinie, bzw der Marker für den 
Triggerlevel sind digital aus der Stellgröße abgeleitet. Das Oszi kann 
also die Spannung des DAC-Ausgang nicht messen (Warum auch, ist ja ein 
DAC, und das Oszi programmiert den DAC … ;))

Die 50%-Einstellung hängt natürlich vom Signal ab. Also mal das 5V 1kHz 
Rechtecksignal für die Tastkopfkompensation eingespeist und 50% 
gedrückt: Oszi sagt Triggerlevel 2.52V und die Triggerlevelmarkierung 
auf dem Bildschirm liegt in der Mitte des Rechtecksignals, auch wenn das 
Signal einen Offset hat. Ich schließe mal daraus, dass das Mininum und 
Maximum eines Signals zu bestimmen funktioniert.

> und wo steht dann der DAC?

Ok, Signal auf 0 Div, 50%, Oszi sagt 2,52V, DAC Ausgang 224mV. Das passt 
mit dem oben gemessenen 436mV für 5V ganz gut.

Schiebe ich jetzt das Signal auf dem Bildschirm nach oben, folgt der 
Triggerlevelindikator auf den Bildschirm der Bewegung (wie erwartet). 
Auch die Ausgangspannung am DAC steigt linear mit der Bewegung. Ist die 
Triggerlevelmarkierung bei +5 Div, gibt der DAC, wie erwartet 436mV aus.

Verschiebt man die Nulllinie nach unten, verringer sich die 
Ausgangsspanung des DAC wieder. Erreicht man die 0 Div-Linie mit der 
Triggermarkierung, gibt der DAC 0V aus. Geht man leicht darunter (einen 
"Tick" des Drehencoders) gibt der DAC volle Referenzspannung aus. An der 
Stelle hat sich die DAC-Einstellung von 0x000 auf 0x3ff (10 Bit-DAC) 
geändert.
Daher meine (und deine) Vermutung mit der -1. Mit dem Memory-dumps 
konnte ich die Vermutung bestärken. Ich habe mehrere Speicherstellen 
gefunden, die sich mit Drehen des Drehencoders ändern und die 
Speicherstelle des "Akkumulators" identifiziert. Mehr dazu unten.

> Wenn du die Nullinie deines zu triggernden
> Signals verschiebst, was macht denn dann dein DAC?
> Wenn ich deine Worte richtig deute, nichts? Das wäre bischen wenig.

Er geht mit rauf und runter. Sorry, wenn ich mich da ein wenig 
unglücklich/unverständlich ausgedrückt habe. Ich bin mir nicht sicher, 
wie ich das ganze Zeug nennen soll, so dass es unmissverständlich ist :)

Anders gesagt: der DAC-Ausgang passt sich an, wenn man das Signal auf 
und ab schiebt, aber es fehlen immer die 1,25V DC-Offset/common mode.

> nun ja, viel Erfolg, Uwe

Vielen Dank, ich habe, wie gesagt, die Speicherstelle identifiziert, die 
den "Drehencoderakkumulator" enthält. Da wird also beim weiterdrehen 
jeweils +1 bzw -1 aufaddiert. Ich habe da mal einen anderen Wert 
reingeschrieben und den Drehencoder gedreht: auf meinen geschriebenen 
Wert wurde +1 aufaddiert und der Triggerlevel sprang auf dem Display und 
am DAC.

Mit der Speicherstelle komme ich also erstmal nicht weiter.

Eine andere Speicherstelle schien den aktuellen Triggerlevel zu halten, 
der beim Ausschalten in den Flash gespeichert wird. Genau genommen waren 
es zwei Speicherstellen. Als ich beide in Tandem geändert hatte und das 
Oszi aus und wieder eingeschaltet habe (den Encoder darf man nicht mehr 
anfassen, da dieser den Wert wieder überschreiben wird), hat das Oszi 
auch mit einem neuen Triggerlevel gebootet (yay!), aber die 
Ausgangsspannung vom DAC hatte noch die gleiche (falsche?) Beziehung zum 
Triggerlevel, der auf dem Bildschirm angezeigt wurde.
Also habe ich beide getrennt von einander geändert. Das mochte die 
Firmware offenbar nicht. Jetzt bootet das Oszi immer mit dem gleichen 
Triggerlevel :( Die Beziehung zwischen angezeigtem Triggerlevel und 
DAC-Ausgang ist weiterhin unverändert.

Um das zu beheben habe ich noch nichts weiter probiert, aber ich habe da 
genug Möglichkeiten: Factory defaults, Firmware upgrade, NAND-Dump 
zurückspielen …

Als nächstes werde ich versuchen den DAC im Debugger anzusteuern. Das 
hilft mir zwar nicht direkt, aber ich hoffe einiges an Verständnis zu 
gewinnen, wie der SoC funktioniert. Auch kann ich probieren den DAC auf 
quasi beliebige Werte einzustellen und schauen, ob das Triggering dann 
funktioniert (sollte es, laut meinem Bypasstest).

Dann bliebe mir an dieser Stelle nichts übrig als den Codepfad von 
"Drehencoder wird gedreht" bis "DAC wird geschrieben" zu verfolgen und 
ggf zu disassemblieren, um rauszubekommen, wie aus dem Encoderwert das 
DAC-Command generiert wird.

Holzhammermethode wäre noch einen kleinen Attiny an den Bus zu hängen, 
der das DAC-Command mitliest und, um das Offset korrigiert, nochmal 
sendet :)

Viele Grüße,
Hannes

[Hannes W. (hannes_w129)]

Hannes W. schrieb:
> Als nächstes werde ich versuchen den DAC im Debugger anzusteuern. Das
> hilft mir zwar nicht direkt, aber ich hoffe einiges an Verständnis zu
> gewinnen, wie der SoC funktioniert. Auch kann ich probieren den DAC auf
> quasi beliebige Werte einzustellen und schauen, ob das Triggering dann
> funktioniert (sollte es, laut meinem Bypasstest).

Essig ist's. Der DAC hängt am FPGA. :(

[Uwe (Gast)]

Hi,
mein Bauchgefühl sagt mir du musst dir mal den DAC ansehen. kann man den 
ev. von singel auf dual umstellen?
>Dreht man den Triggerlevel auf -5 Div (-5V auf dem Display) gibt der DAC
>3.665V). Der DAC hat die 4096mV Referenzspannung und 4096mV - 436mV =
>3660mV; nah genug, oder? Dreht man den Triggerlevel maximal negativ,
>also -6V laut Display gibt der DAC 3,577V aus.
ich meine so von 0-4,096V auf +/- ~2V mit Offset? bei 2,5V?
Ich ziehe mir jetzt mal das Datenblatt rein, mal sehen ob da irgendwas 
geht.
Mal so mebenbei ist in deinem Oszi keine Batterie drin? Ich meine in 
meinem mal eine CR2032 gesehen zu haben und dachte die stützt die 
temporären Daten
im Ramm...Trigger Kanäle Positionen....hmm.

viel Erfolg, Uwe

[Uwe (Gast)]

Hi,
so ganz einfach ist es wohl doch nicht, aber kann es sein das Pin 1&2 
verbunden sind? Dann könnte man mit AO3 RefL anheben allerdings auch nur 
1,5V.
Was mich bischen stört ist das abwärts nach $000, $3FF kommt. Bei mir 
ist da eine Begrenzung bei -6V drin. Es springt ja auch nicht nach 
$FFFF, nein er bleibt schön in deinem Wertebereich. Der Ausgabekanal 
bleibt doch oder?

>ich habe, wie gesagt, die Speicherstelle identifiziert, die
>den "Drehencoderakkumulator" enthält. Da wird also beim weiterdrehen
>jeweils +1 bzw -1 aufaddiert. Ich habe da mal einen anderen Wert
>reingeschrieben und den Drehencoder gedreht: auf meinen geschriebenen
>Wert wurde +1 aufaddiert und der Triggerlevel sprang auf dem Display und
>am DAC.
Ämm du hast den Triggerakku gefunden, was sagt der denn zu $271 = 2,5V?
Sollte das nicht auch der Wert sein der bei "0" gesetzt wird.
nun ja, alles sehr komisch viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Uwe schrieb:
> Hi,
> mein Bauchgefühl sagt mir du musst dir mal den DAC ansehen. kann man den
> ev. von singel auf dual umstellen?

Den DAC? Ne, das geht nicht.

>>Dreht man den Triggerlevel auf -5 Div (-5V auf dem Display) gibt der DAC
>>3.665V). Der DAC hat die 4096mV Referenzspannung und 4096mV - 436mV =
>>3660mV; nah genug, oder? Dreht man den Triggerlevel maximal negativ,
>>also -6V laut Display gibt der DAC 3,577V aus.
> ich meine so von 0-4,096V auf +/- ~2V mit Offset? bei 2,5V?

Was meinst du? Ich kann den DAC nicht direkt steuern. Mit dem Knopf 
kommt man nicht nach 2.5V, nur 0 bis 0.5V und 4.096V bis 3.665V. Das ist 
ja mein Problem …

> Ich ziehe mir jetzt mal das Datenblatt rein, mal sehen ob da irgendwas
> geht.

> Mal so mebenbei ist in deinem Oszi keine Batterie drin? Ich meine in
> meinem mal eine CR2032 gesehen zu haben und dachte die stützt die
> temporären Daten
> im Ramm...Trigger Kanäle Positionen....hmm.

Doch, eine kleine Knopfzelle ist drin. Der SoC hat intern eine RTC, dazu 
würde auch der kleine Extraquarz auf der Platine passen. Ich habe die 
Batterie auch schon abgeklemmt - da passiert nix.

Der RAM ist SDRAM, kein SRAM, da reicht eine Batterie nicht zum stützen, 
selbst wenn der RAM Autorefresh macht, braucht er dabei zuviel Strom.

Uwe schrieb:
> Hi,
> so ganz einfach ist es wohl doch nicht, aber kann es sein das Pin 1&2
> verbunden sind?

Nein, wieso sollten sie?

> Dann könnte man mit AO3 RefL anheben allerdings auch nur
> 1,5V.

Nein, ich habe keine (direkte) Kontrolle über den DAC. Gut, könnte man 
extern lösen, aber so richtig löst es das Problem nicht.

> Was mich bischen stört ist das abwärts nach $000, $3FF kommt.

Warum? Wenn der Zähler nach negativ überläuft, stimmt das doch.

> Bei mir ist da eine Begrenzung bei -6V drin.

Bei mir auch. Zumindest auf dem Display.

> Es springt ja auch nicht nach
> $FFFF, nein er bleibt schön in deinem Wertebereich.

Warum sollte es? Den 10-Bit DAC mit 16Bit Programmieren wird ja nicht 
funktionnieren. Die 0x3ff sind direkt vom SPI-Bus, nicht aus dem RAM des 
Rechners!

> Der Ausgabekanal bleibt doch oder?

Du meinst den Kanal des Oszis? Ja, ich bin immer auf Kanal 1. Kanal 2 
ist genau so …

>>ich habe, wie gesagt, die Speicherstelle identifiziert, die
>>den "Drehencoderakkumulator" enthält. Da wird also beim weiterdrehen
>>jeweils +1 bzw -1 aufaddiert. Ich habe da mal einen anderen Wert
>>reingeschrieben und den Drehencoder gedreht: auf meinen geschriebenen
>>Wert wurde +1 aufaddiert und der Triggerlevel sprang auf dem Display und
>>am DAC.
> Ämm du hast den Triggerakku gefunden, was sagt der denn zu $271 = 2,5V?

2.5V wo? Anzeige auf dem Display? Dann ist der Akkumulator bei 0x3f

> Sollte das nicht auch der Wert sein der bei "0" gesetzt wird.

Nein, der Akkumulator sollte bei 0V auf 0 stehen, aber der DAC mit 0x271 
programmiert werden. Jetzt ist der Akkumulator bei 0 auch wenn 0V auf 
dem Display steht, d.h. Akkumulator und Displayanzeige sind gleich. 
Ändere ich den Wert im Akkumulator, ändert sich auch die Displayanzeige.

> nun ja, alles sehr komisch viel Erfolg, Uwe

Ja, da hast du Recht :)

PS: Im EEVBlog-Forum hat sich jemand gefunden, der Messungen in seinem 
Scope macht. Damit habe ich Verlgeichsmessungen und kann hoffentlich 
definitiv sagen ob das Problem am Signal vom AFE oder am Triggerlevel 
DAC liegt. Hoffentlich stimmen wenigstens die Werte eines Messpunnktes 
mit meinen überein :)

[Hannes W. (hannes_w129)]

Ok, es ist mir gelungen, herauszufinden, wie man den DAC über den FPGA 
ansteuert. Ist eigentlich nicht so kompliziert, der FPGA ist als 
DDR-Speicher an den SoC angeschlossen.
Der SoC kann so Samples vom FPGA lesen und anscheinend auch Geräte 
steuern, die am FPGA hängen. Quasi MMIO von hinten durch die Brust in's 
Auge. Das schwierige war die "magischen" Adressen herauszubekommen.

Die Werte reicht der FPGA 1:1 durch. D.h. ich habe mal die von dir 
erwähnten 0x271 geschrieben (plus natürlich die 4 Bit die den 
DAC-Ausgang auswählen. Schwupps, sind 2.5V am DAC-Ausgang. Cool.

Ich habe immer noch das 5V Rechteck dran. 50% sind 0x36 oder so, also 
0x271 Bias + 0x36 = 0x2a7. Bumm. Das Ding triggert!

Ich werde noch ein wenig den Codepfad disassemblieren, um zu schauen, 
wie der SoC aus dem Akkumulator für den Drehencoder den Wert 
zusammenbastelt, der an den DAC geht. Da muss ja jetzt dann der Fehler 
sein …

[Uwe (Gast)]

Hi,
wow, das klingt gut. Mein Gedanke war eigentlich das beim setzen auf "0 
Div"
der DAC Grundwert(0x271) für den DAC mit geladen werden muss. Das dann 
noch einiges an Verrechnung kommen muss ist eigentlich klar. Hat es den 
Grundwert ev. überschrieben?( oder eben die Adresse für den 
Grundwert)???
Du wirst es rausfinden, bist kurz davor. Super Leistung!
Viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Uwe schrieb:
> Hi,
> wow, das klingt gut. Mein Gedanke war eigentlich das beim setzen auf "0
> Div"
> der DAC Grundwert(0x271) für den DAC mit geladen werden muss.

Ich stimme dir zu 100% zu und ich glaube da liegt der Hase begraben. Der 
Hund im Pfeffer? Irgendwie so.

> Das dann
> noch einiges an Verrechnung kommen muss ist eigentlich klar. Hat es den
> Grundwert ev. überschrieben?( oder eben die Adresse für den
> Grundwert)???

Das ist auch mein Gedanke. Es ist ja auch zeitgleich auf Kanal 1 + 2 
passiert. Deswegen habe ich auch den Flashinhalt auseinander genommen, 
weil der Wert ja da drin sein muss … ggf in Zwischengespeichert in einer 
"Einstellungsdatei".

Die "Save"-Funktion, die ich damals versehentlich angewählt hatte 
speichert ja auch in den Flash. Nicht dass da etwas überschrieben wurde. 
Oder es gab einen überlauf beim Erstellen der Waveform im RAM … Ich weiß 
es nicht, aber gut möglich auf jeden Fall.

> Du wirst es rausfinden, bist kurz davor. Super Leistung!
> Viel Erfolg, Uwe

Danke! Ich bleibe am Ball!

Viele Grüße,
Hannes

[Hannes W. (hannes_w129)]

Hannes W. schrieb:
> PS: Im EEVBlog-Forum hat sich jemand gefunden, der Messungen in seinem
> Scope macht. Damit habe ich Verlgeichsmessungen und kann hoffentlich
> definitiv sagen ob das Problem am Signal vom AFE oder am Triggerlevel
> DAC liegt. Hoffentlich stimmen wenigstens die Werte eines Messpunnktes
> mit meinen überein :)

Ok, die Vergleichsmessungen sind da und bei der Person ist bei der 
Triggereinstellung "0V" der DAC-Ausgang wie von uns vermutet bei 2,5V. 
Damit bestätigt sich die Theorie, dass es definitiv nicht an der 
Hardware bzw. dem AFE liegt, sondern ein Fehler in der Firmware ist, der 
dafür sorgt, dass der DAC falsch programmiert wird.

[Uwe (Gast)]

Hi,
>Die "Save"-Funktion, die ich damals versehentlich angewählt hatte
>speichert ja auch in den Flash.
Ist die Datei Ok? Ist der Speicher ev. übervoll? Was geschieht wenn du 
die Datei mit 0x271 füllst.....
viel Erfolg, Uwe

[Hannes W. (hannes_w129)]

Uwe schrieb:
> Hi,
>>Die "Save"-Funktion, die ich damals versehentlich angewählt hatte
>>speichert ja auch in den Flash.
> Ist die Datei Ok?

Das weiß ich nicht, bzw. kann ich nicht beurteilen.

> Ist der Speicher ev. übervoll?

Der Flash ist zur Hälfte leer. Aber wer weiß ob die Software überhaupt 
den ganzen Flash benutzen kann.

> Was geschieht wenn du
> die Datei mit 0x271 füllst.....

Das werde ich garantiert nicht probieren, denn ich weiß nicht wie 
Checksummen berechnet werden, der FTL funktioniert, etc. Vermutlich 
würde das Oszi mit einem Prüfsummenfehler im Dateisystem nicht mehr 
booten. Oder es würde booten und noch mehr kaputt machen …

> viel Erfolg, Uwe