[bestätigt] Oszillator Bug auf Nexus als Ursache für ARM Boot-Fehler!?

Hallo Leute!

Dachte mir ich mach mal einen eigenen Thread auf der sich speziell mit dem bisher immer noch nicht geklärten ARM-Boot Problem der Nexus Karten befasst und vielleicht die Lösung des Problems beinhaltet.

Kurze Erklärung was das Problem ist:
Sporadisch kommt es bei Nexus Karten (vorallem Rev.2.3 - habs aber auch auf einer 2.1 beobachtet) beim Start zu folgenden Fehlermeldungen:
dvb-ttpci: load_dram(): timeout at block 0
dvb-ttpci: av7110_bootarm(): load_dram() failed

Bisher habe ich folgende Ursachen als Fehler ausgeschlossen:
-) Spannungstoleranzen -> alle innerhalb der Toleranzen
-) Hitze -> Lüfter direkt bei der Karte daher keine Überhitzung
-) Ein reboot hat bei mir nie geholfen. Daher habe ich das reine reset-sequenzing ebenfalls als unkritisch bewertet
-) vorigen Punkt bestätigt auch mein Test die Reset-Leitung des ARM während des Betriebs manuell nochmal zu reseten -> hat nix gebracht

Möglichkeiten den Fehlerzustand zu verlassen:
-) Einfach einen Power-cycle durchführen (hilft nicht immer!!!!)

Aber das wichtigste was ich herausgefunden habe war folgende Beobachtung:
Als der PC wieder mal hochgefahren ist und die Nexus nicht starten konnte (ARM-boot block 0 Problem) hab ich ein skript geschrieben, das permanent die treiber entlädt und wieder lädt.
Die Karte wurde also permanent versucht zu starten -> ohne Erfolg -> jetzt bin ich hergegangen und hab mit dem Finger auf dem Oszillatorschaltkreis herumgetastet und siehe da - plötzlich ließ sich der treiber laden, entladen, laden, entladen usw.
Der nächster schritt war zu testen, was denn passieren würde wenn ich den Oszillator (VCXO) beinhart anhalte. -> siehe da ich bekam wieder die bekannte ARM-boot Fehlermeldung

FAZIT:
Ich denke die Ursache liegt darin, dass der Oszillator manchmal nicht anschwingt -> Änderungen bei der Bestückung und den Kondensatorenwerten deuten stark darauf hin.

Mehr möchte ich hier in der Zusammenfassung nicht schrieben -> Details siehe ursprünglicher Thread ("DVB (Nexus-S) ist manchmal nicht da").
Dort stehen auch die bisherigen Modufikationen an der Karte beschrieben.

Wen's interessiert bitte dort reinschauen und dann hier weiter posten.

LG
Ferdl

Quote

Original von UFO
Hab's mal an einer Rev 1.3 nachgemessen. Bei der Rev 2.1 hast Du Dich vertan: Der Parallelkondensator Cy hat 47pF, Cx hat100pF. Bitte ändere das mal ab.

Laut Datenblatt hat die Kapazitätsdiode HVU359 ca. 7...27pF bei 4...1V.

Mal ein bischen gerechnet:
Mit den Kondesatoren hätten wir bei der Rev 1.3 also einen Regelbereich von 35...43pF (Cx in Serie zu (Kapazitätsdiode + Cy)).

Ohne die Parallelkondensatoren (nur Cx=100pF) kommt man auf 6,5...21pF.
Mit der Bestückung der Rev 2.3 (Cx=330pF) sind es 6,8...25pF.

Hm - bist Du sicher, daß die gleiche Kapazitätdiode verbaut ist?

CU
Oliver

Display More

Kann ich nicht sagen ob da die gleiche Kap.-Diode verbaut worden ist - sieht zumindest optisch danach aus.

Obwohl du in der Berechnung nicht den vollen Regelbereich (0...5V) verwendest siehst du schon, dass im man mit den Kapazitätswerten extrem weit nach unten kommt wo ein Oszillatorbetrieb nicht mehr gewährleistet ist - siehe nochmal meinen post über pierce-oszillatoren.

hättest du die möglichkeit dich mit einem oszi auf den gepufferten Inverterausgang zu hängen und mal zu messen was da rauskommt wenn die karte hängt?

LG
Ferdl

Quote

Original von Ferdl
Hallo Leute!

Dachte mir ich mach mal einen eigenen Thread auf der sich speziell mit dem bisher immer noch nicht geklärten ARM-Boot Problem der Nexus Karten befasst und vielleicht die Lösung des Problems beinhaltet.

Kurze Erklärung was das Problem ist:
Sporadisch kommt es bei Nexus Karten (vorallem Rev.2.3 - habs aber auch auf einer 2.1 beobachtet) beim Start zu folgenden Fehlermeldungen:
dvb-ttpci: load_dram(): timeout at block 0
dvb-ttpci: av7110_bootarm(): load_dram() failed

Bisher habe ich folgende Ursachen als Fehler ausgeschlossen:
-) Spannungstoleranzen -> alle innerhalb der Toleranzen
-) Hitze -> Lüfter direkt bei der Karte daher keine Überhitzung
-) Ein reboot hat bei mir nie geholfen. Daher habe ich das reine reset-sequenzing ebenfalls als unkritisch bewertet
-) vorigen Punkt bestätigt auch mein Test die Reset-Leitung des ARM während des Betriebs manuell nochmal zu reseten -> hat nix gebracht

Möglichkeiten den Fehlerzustand zu verlassen:
-) Einfach einen Power-cycle durchführen (hilft nicht immer!!!!)

Aber das wichtigste was ich herausgefunden habe war folgende Beobachtung:
Als der PC wieder mal hochgefahren ist und die Nexus nicht starten konnte (ARM-boot block 0 Problem) hab ich ein skript geschrieben, das permanent die treiber entlädt und wieder lädt.
Die Karte wurde also permanent versucht zu starten -> ohne Erfolg -> jetzt bin ich hergegangen und hab mit dem Finger auf dem Oszillatorschaltkreis herumgetastet und siehe da - plötzlich ließ sich der treiber laden, entladen, laden, entladen usw.
Der nächster schritt war zu testen, was denn passieren würde wenn ich den Oszillator (VCXO) beinhart anhalte. -> siehe da ich bekam wieder die bekannte ARM-boot Fehlermeldung

FAZIT:
Ich denke die Ursache liegt darin, dass der Oszillator manchmal nicht anschwingt -> Änderungen bei der Bestückung und den Kondensatorenwerten deuten stark darauf hin.

Mehr möchte ich hier in der Zusammenfassung nicht schrieben -> Details siehe ursprünglicher Thread ("DVB (Nexus-S) ist manchmal nicht da").
Dort stehen auch die bisherigen Modufikationen an der Karte beschrieben.

Wen's interessiert bitte dort reinschauen und dann hier weiter posten.

LG
Ferdl

Display More

Kurzes Update:
Die Karte funktioniert seit dem Umbau immer noch ohne einen einzigen Fehlstart
(waren inzwischen ca. 30 weitere VDR-Starts)

lg
Ferdl

Quote

Original von UFO
Seltsam ist halt, daß die Regelbereiche total verschieden sind. Wie soll da eine Regelung zustande kommen?

hab mal die regelschleife unterbrochen (Steuerspannung der Kapazitätsdioden fix auf 5V bzw. 0V gelegt) -> Hat bei der Wiedergabe kein sichtbaren/hörbaren Probleme verursacht.
die 27mhz weden soweit ich gesehen habe für das PAL-Signal und zur generierung der 91kHz clock für den mpeg-stream timer verwendet.
selbst wenn man wie ich testweise ein 25MHz signal hier einspeist funktioniert der ton und die mpeg-decodierung - nur der fernseher kann sich nicht auf das geänderte pal-timing aufsynchronisieren

Quote

Habe mal etwas gemessen: Es scheint vom Zufall abhängig zu sein, ob der Loop-Ausgang der Karte nach einem Reset High oder Low ist. Möglicherweise hilft es also, die Karte im Treiber mehrmals zu resetten.

danke für den test!
das mehrmalige resetten glaub ich hilft nix da das ja bei jedem treiberstartversuch gemacht wird und bei mir zumindest nie geholfen hat.

kannst du evtl. noch messen, was am ausgang deiner karte anliegt wenn du den rechner komplett stromlos gemacht hast und dann wieder einschaltest?

kann mal wer der vom arm-boot fehler betroffen ist folgendes testen:
-) wenn fehler auftritt - rechner laufen lassen und den oszillatorteil der ff-karte mit dem finger paar mal deutlich berühren
-) dann treiber nochmal manuell laden und schaun ob er sich fehlerfrei laden lässt

-> wenn das wer reproduzieren kann ist die ursache DEFINITIV der falsch dimensionierte oszillatorteil der manchmal nicht anschwingt

LG
Ferdl

P.S.: System läuft und läuft

Quote

Original von UFO
Bei Power-On ist Loop hier low, d.h. an den Kapazitätsdioden liegt high an, d.h. minimale Kapazität. Der Oszillator schwingt bei mir immer sofort an.

Das deckt sich mit der Tatsache, dass seit dem Austausch der originalen 380pF Kondensatoren auf der Nexus 2.3 durch die empfohlenen 100pF Kondensatoren bei mir kein ARM-boot fehler mehr aufgetreten ist.

Demnach sollte das Problem also eine zu hohe Startkapazität auf der Nexus 2.3 sein?!

lg
ferdl

Quote

Original von UFO
Hm? Eher umgekehrt: eine zu niedrige. Die Varicaps haben bei _hoher_ Spannung die _minimale_ Kapazität. Und die alten Karten haben ja noch die Parallelkondensatoren. Damit ist die Startkapazität doch wesentlich höher!

Andere Möglichkeit:
Du hattest einen ganz anderen Fehler (kalte Lötstelle, oder einer der Kondensatoren defekt, oder...).

mhm... blöd dass wir nicht wissen ob die dioden die gleichen sind.
noch ein faktor ist der quarz - kann ich nicht sagen ob der die gleiche lastkapazität hatte... können wir nur spekulieren

lötstellenproblem und bauteildefekt(habs durchgemessen) kann ich definitiv ausschließen - sonst müssten noch dazu alle leute hier mit dem problem den den gleichen lötfehelr haben.

werd jedenfalls weiter testen und euch auf dem laufenden halten.

LG
ferdl

nachdem inzwischen ja einige zeit vergangen ist und ich kein einziges problem mehr mit dem ARM-boot hatte ist für mich das thema erledigt.

fazit:
bei mir war das boot-problem durch änderung der kondensatorebestückung beim schwingquarz (siehe beiträge) lösbar.

ich denke das ist eine erwähnung bei vdr-wiki wert????

lg
Ferdl