[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


  • 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

  • also wenn ein oszillator net anschwingt würd ich als erstes den quarz erneuern !meistens handelt es sich um sogenannte keramik-was weiss ich was...
    die sind gegen mechanische einwirkungen sehr empfindlich!
    manchmal kann man sogar ein rappeln hören wenn man dagegen schnippt!
    ooldman

    software : gen2vdr V2.0
    Activy 300 celeron 800 256mb ram dvd r/w tt-ff card ci-adapter
    fb : kwr 3020/00 keyboard : kw 1133/00fb
    ECS K7A5 amd 1250 512 mb ddr nexus-s 40gb maxtor quite nt

  • Zitat

    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.

    Ich erlaube mir mal einen Link dahin zu setzen.


    Beim Basteln hatte ich letztens zufällig auch mit einem ähnlichen Problem zu tun:
    Ich hatte mal bei einem Atmel-AVR-Mikrocontroller vergessen das Fuse-Bit für die Kondensatoren zu setzen. Der Oszillator ist zwar auch ohne die Kondensatoren angelaufen, dafür aber mit einem vielfachen der Quarzfrequenz (ich glaube es war das 4-fache).
    Der AVR ist zwar auch mit dem höheren Takt zurechtgekommen, war aber immer zu schnell. (Es hat eine ganze Weile gedauert, bis ich rausgefungen hatte woran es lag.)
    Beim ARM bezweifele ich, dass er mit dem doppelten oder noch höherem Takt laufen wird.

    Gruss
    SHF


  • Zitat

    Original von SHF


    Ich hatte mal bei einem Atmel-AVR-Mikrocontroller vergessen das Fuse-Bit für die Kondensatoren zu setzen. Der Oszillator ist zwar auch ohne die Kondensatoren angelaufen, dafür aber mit einem vielfachen der Quarzfrequenz (ich glaube es war das 4-fache).


    Ich benutze immer externe C's. Bei welchem Atmel-AVR können C's über die Fuse-Bits programmiert werden?


    Gruß
    e9hack

  • OT: Eigentlich bei allen Atmegas.


    AVRprog zeigt hier bei den fuses: internal RC, external RC, Xtal low-frequency, Xtal mid frequency, Xtal high frequency und noch ein paar.

    Software: VDR 1.4.3, mp3, osdpip, streamdev-server, femon, wapd, X11, Wireless Keyboard Kernel: 2.6.18
    Hardware: 1x DVB-S v 1.3, 1x Skystar 2, Celeron@2GHz, 256 MB RAM, 4 HDs Raid1/5, Total: 600 GB, Asus P4S533 cmi8738 & LAN on board 6 PCI
    40" Sammelbestellungs-LCD an ATI Radeon 9550 DVI-Out + tvtime, 70 cm TV an J2-RGB-Out
    Organisator der ersten und zweiten VDR-Sanitizer Sammelbestellung.
    In progress: POV-ION 330 - MediaPointer MP-S2 - vdr 1.7.9 - vdr-xine(vdpau)

  • Zitat

    Original von e9hack
    Bei welchem Atmel-AVR können C's über die Fuse-Bits programmiert werden?

    Bei mir war es ein Mega8 mit einem Uhrenquarz.
    Näheres im Datenblatt unter "Low-frequency Crystal Oscillator" (S. 26).

    Gruss
    SHF


  • Zitat

    Original von pram
    OT: Eigentlich bei allen Atmegas.


    AVRprog zeigt hier bei den fuses: internal RC, external RC, Xtal low-frequency, Xtal mid frequency, Xtal high frequency und noch ein paar.


    Das hat aber nichts mit den C's vom Oszi zu tun. Über die Frequenzbereiche wird nur festgelegt, wieviel Strom vom Oszi-Ausgang getrieben werden kann (viel Strom -> kurze Ladezeiten der C's -> hohe Frequenz). Man kann bei falscher Frequenzwahl den Oszi auf einer Oberwelle vom Quarz zum Schwingen bekommen. Das ist vermutlich bei SHF passiert.


    Gruß
    e9hack


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


    lg
    Ferdl

  • Zitat

    Original von Ferdl


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


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


    Zitat


    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?


    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.


    Sollte mal jemand testen, der das Problem hat.


    CU
    Oliver

  • Zitat

    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 ;)


    Zitat


    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 :)

  • Zitat

    Original von Ferdl


    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 ;)


    Imho braucht man es, um die MPEG-Wiedergabe auf den Takt des Senders bei Live-TV aufzusynchronisieren. Wenn man dies lahmlegt, müßte es zu einem Buffer-Overflow/Underflow führen.


    Zitat


    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?


    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.


    CU
    Oliver

  • Zitat

    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

  • Zitat

    Original von Ferdl


    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?!


    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...).


    CU
    Oliver

  • Zitat

    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

  • also ich kann der sache nur beipflichten...


    ich habe meine karte durch einen bekannten nach den erwähnten umbaumaßnahmen in diesem thread umbauen lassen und ich habe seitdem keinerlei probs mehr mit der karte (load_dram failed).


    ich kann nur sagen: meinen allerhöchsten respekt und DANKE!

    Client 1 Hardware : MSI Z87-G43, I5-4570, 4 GB Ram (oversized aber war über :) ),Zotac NVidia GT630 (25 Watt),Thermaltake DH202 mit iMon-LCD ( 0038 ) und vdr-plugin-imon
    Software : yaVDR 0.6,sofhhddevice @ 1920x1080@50Hz
    Server Hardware : MSI Z87-G43, I7-4790, 16 GB RAM, 5x3 TB WD Red, Digibit-R1 (2 Devices)
    Software : Ubuntu 16.04 LTS mit yavdr-Paketen,virtualbox,diverse VM's


    Yoda: Dunkel die andere Seite ist...sehr dunkel!
    Obi-Wan: Mecker nicht, sondern iss endlich dein Toast ...


  • Na dann rein damit. :)


    CU
    Oliver

  • Hoi,


    Habe hier zwei 2.3er. Einmal eine Hauppauge,
    Sereinnummer 4053273405012780,
    und dann noch eine TT "modded" aus dem DVB-Shop,
    Sereinnummer 4070800807050480.


    Die Hauppauge läuft fehlerfrei, die TT hat manchmal den beschriebenen Fehler.


    Habe mir mal die Bestückung angeguckt. Bin mit dem Erkennen von SMD-Bauteilen bisher nicht konfrontiert wordern, daher beschreibe ich einfach mal, was mir so auffällt.



    Im folgenden immer zuerst die Hauppauge, dann die TT:


    # Der Oszillator (wenn das die kleine Blechbox rechts neben dem AV7110 ist) ist anders.
    Aufschrift:
    27.000
    ----------
    JY27M0644



    # Der IC rechts neben dem Oszillator (ca. 4x4mm groß).
    <geschwungenes "F">P53AB
    LCX04
    ----------
    LVC04A
    BA48001
    Un606
    35D



    # Der IC unten rechts neben dem SAA1764.
    LVC00A
    AR132
    Un605
    17D
    ----------
    <geschwungenes "F">PG5S8
    LCX00



    #Der IC links vom Oszillator über dem AV7110
    HT14
    45K
    ETKO
    ----------
    HCT14
    BA83017
    Un606
    28F



    #Der Chip rechts vom 2MB-Samsung, selbe Größe
    HYUNDAI
    GM71V18163CT5
    0051 AG7 KOREA
    ----------
    <Mitsubishi-Logo>M5M4V18165DTP
    JAPAN 90774801-6



    #Das runde Ding unter dem Schriftzug "DVB-S Rev.: 2.3" (ganz oben)
    SM
    4001
    ----------
    100



    #Tuner
    -kommt aus Japan
    ----------
    -kommt aus China




    Soo. Jetzt hätt' ich noch ein paar Fragen:
    Was sind das für Dinger rechts neben dem Oszi? Schwarz mit rotem Kasten an der Stirnseite, im schwarzen steht ein "S".
    Die kleinen schwarzen Dinger mit den silbernen Enden sind Widerstände. Wenn da ein Kasten drauf ist, sind das dann Brücken (0 Ohm)?
    Die kleinen braunen Dinger mit den Silbernen Enden sind Kondensatoren? Die Wertigkeit ist nicht aufgedruckt?
    Der Audio-Chip der TT soll ja ein anderer sein als bei der Hauppauge (obwohl mein Hauppauge auch einen J2 hat, den sie laut Wiki nicht haben sollte). Welcher Chip ist das?
    Und wofür sind die anderen ICs da, die abweichen?


    Gruß, Bartho

    "Our function is to contribute in a positive way to the world in which we live." Lt. Cmdr. Data in Star Trek: TNG - The Offspring


    PVR1: Activy 300, TT S-2300, TT S-1500, RGB-out, Mahlzeit 4beta2
    PVR2: P3 1GHz, 2*TT S-2300, RGB-out, Mahlzeit 4beta2
    PVR3: Streamingserver, P3 1GHz, TT S-1500, TT S-1401, Lenny+eTobi
    FF-Karten: 4MB-Mod, Full-TS-Mod, einmal Oszillator-Mod.

  • Zitat

    Original von Bartholomew
    Und wofür sind die anderen ICs da, die abweichen?

    Ferdl hatte im ersten Thread mal ein Bild dazu angehängt.

    Gruss
    SHF


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!