Man lernt aus Fehlern - auch aus der anderer

Martin Laabs schrieb:

Hallo,

na ja, beim nächsten Mal könnte es ja ein zu hochohmiger Pullup Widerstand sein wenn dann der Übergang von High-Z in sicherem High Zustand zu lange dauert. ;-)

Bye

Klassisch! Danke fuer die Beschreibung. Sowas aehnliches passiert uns allen mal. Bei mir war es der Farbcode auf einem Widerstand der aehnliche Effekte in der analogen Welt brachte. Blau und gruen zu unterscheiden ist ja auch verflixt nicht einfach, fuer mich zumindest nicht wenn das Licht aus Leuchtstoffroehren kommt. Tja, war dann eine Zehnerpotenz zu gross.

Hint: Ab und zu hilft es einfach mal in die Schaltung reinzutatzen, sehen ob sich dabei das Fehlerbild ein wenig aendert.

Joerg :

Ich hatte mal eine originale Rolle von Widerständen - mit 3k3 bedruckt, aber tatsächlich hatte die 330k! (War auch witzig der Anruf von Bürklin: "aber die stimmen doch?" - "Sie haben jetzt nicht mit dem Multimeter gemessen?" - "Nein, haben wir nicht, Moment..... s*it!" Seitdem messe ich Widerstände grundsätzlich und spar mir das Farbcodedekodieren (ausser die sind eingelötet...). "Pull-Up vergessen" hatte ich auch schon. Mittlerweile hab ich ne Checkliste, was ich alles nochmal überprüfe, bevor die Schaltung fertigstelle, da steht "Pullps???" an allererster Stelle (und geholfen hat es letztens trotzdem nix ;-).

M.

BTDT: wenn ein Baustein mit Bus-Hold (74LVTH16373 o.ä.) mit am Bus hängt, wird das mit 10k manchmal eng, und der Prozessor kann sein reset configuration word nicht wie gewünscht vom Bus lesen.

cu Michael

Am 28.10.2010 16:21, schrieb Martin Laabs:

Gehe mit: Datensicherung auf DAT Streamer, exakt nach 2.345.658.389 Bytes hängt die Kiste reproduzierbar. Fehler: Sicherung in der TermPWR Leitung durch, Terminator hängt in der Luft und immer bei dieser Datei mit den 16384 Nullen am Stück geht dem die Puste aus.

Butzo

Am 28.10.2010 16:21, schrieb Martin Laabs:

Als ich von den AVRs auf die AVR XMegas gewechselt hatte, hatte ich ein seltsames Phänomen: An einer Stelle redete ein XMega mit einem 485 Treiber und sollte Zeugs auf den Bus legen. Auf der anderen Seite kamen die Daten oft an, die Bitefehlerrate war aber immens hoch. Nach ewigem Rätseln und Zweifel am Code hatte ich nochmal genaustens das Datenblatt studiert: Im Gegensatz zum AVR muss man beim XMega den Treiber für TX explizit aktivieren, sonst ist er im Z. Gemacht, ging.

Warum da tatsächlich *überhaupt* Daten rauskamen ist mir allerdings ein Rätsel. Muss wohl eine sehr hochohmige Xmega-Ausgang -> 485-Eingang Strecke gewesen sein und irgendwelche Schmutzeffekte oder so ähnlich.

Vergess ich auch nicht wieder ;-)

Viele Grüße, Johannes

unterlaufen.

Oh, Datensicherung beim Kunden.

Kunde a: irgendwann werden die Bestände so groß, daß die Backup-Software nach einem neuen Tape verlangt. Der Kunde stellt fest, daß es auch funktioniert, wenn er einfach RETURN drückt.

Kunde b: macht jeden Tag Backup. Auf dasselbe Band (Schrägspurverfahren). Der Ernstfall kommt nach Jahren. Leider hat das Band mittlerweile keine Magnetbeschichtung mehr.

Klaus Butzmann schrieb:

Hallo,

na da muß man erst mal darauf kommen, da sucht man ja erst mal sonstwo, aber nicht bei der SCSI Terminierung.

Bye

David Kastrup schrieb:

Hallo,

eine andere Variante lernte ich vor 20 Jahren mal bei einem Unix System kennen. Der Kunde sicherte zwar abwechselnd auf verschiedene Bänder, aber nur wenn man länger als eine Viertelstunde sich die Protokollmeldungen der Sicherung auf dem Bildschirm ansah merkte man das danach nur noch Fehlermeldungen kamen: kann Datei xyz nicht sichern weil die maximale Pfadlänge überschritten wurde. Dummerweise war im System die maximal zulässige Pfadlänge beim normalen Betrieb um 10 Zeichen grösser als beim Datensichern, der Kunde hatte aber eine tief gestaffelte Verzeichnisstruktur mit sehr langen Verzeichnisnamen eingerichtet.

Bye

Am 29.10.2010 09:25, schrieb David Kastrup:

Vor fast 25 Jahren - mein erstes kommerzielles Stück Software:

"Also wenn Sie 50 Abrechnungen voll haben dann fordert Sie das Programm auf eine _neue_ Diskette einzulegen, die Rechnungen werden dann auf die Diskette ausgelagert..."

Nach etwa 2 Jahren:

"Übrigens, man muß gar keine neue Diskette nehmen. Wir sichern seit über einem Jahr auf die gleiche Diskette, das paßt offensichtlich locker drauf..."

=8-0

Grüße und schönes WE!

Eric.

Ein böses Ding ist mir mal vor Jahren passiert: Kollege hatte eine selbstgebaute S-Ram-Karte, Marke "Made in Eile", die ums verrecken nicht funktionieren wollte. Alles mehrfach geprüft, alles genau nach Datenblatt, trotzdem keine Funktion. Als ich mir das Teil angesehen habe, stellte ich eine ungewöhnliche Pinbelegung der Rams fest, irgendwie hatte ich die anders in Erinnerung. War aber korrekt nach Datenblatt angeschlossen. Sollte etwa...? Der langen Rede kurzer Sinn: im Datenblatt war eine Adressleitung mit Write enable vertauscht, nach dem Tausch der beiden Signale, wie im Datenblatt aller Mitbewerber, lief die Karte dann einwandfrei.

An genau so einem Setup habe ich mal Monate debugt, warum der nach dem Reset gerne mal hängt. Denn während der Flash und der Controller dank /RESET-Pin fein auf Grundstellung gehen, besteht der SDRAM darauf, beim ersten Takt nach dem Reset das Datenbyte abzuliefern, das 3 Takte vor dem Reset bei ihm bestellt wurde.

Ich bin ja inzwischen fast der Meinung, das geht nicht sauber zu lösen. Jedenfalls nicht, wenn in dem Flash das Programm ist, das dem Controller sagen würde, wie es mit dem SDRAM zu reden habe.

Stefan

Das klingt so, als würde der Controller erstmal nur mit Flash und ohne SDRAM laufen. Daher ist die offensichtlichle Lösung dann doch, den Reset Pin des SDRAMs vom Controller ansteuern zu lassen, in der Annahme, daß alle Pins des Controllers auf Tri-State sind beim und nach dem Reset und man an den Reset des SDRAMs dann noch einen Pulldown Widerstand dranhängt, oder? Und natürlich den Hersteller des SDRAMs fragen, was er denn da für einen Mist gebaut hat :-)

Genau. Der Controller redet mit den langsamstmöglichen Settings mit dem Flash, holt daraus das Programm, und das erzählt ihm dann was über den SDRAM und die Schnelligkeit des Flashs.

Der Gag ist ja gerade, dass SDRAMs keinen (mir bekannten) Reset-Pin haben. Sonst wär's ja einfach.

Stefan

Da gibt es sogar ein Patent drauf:

Würde aber darauf wetten, daß man Prior Art dazu finden kann.

Gibt aber doch auch einige Kommandos, die man an das SDRAM schicken kann, ist da nichts passendes dabei? Oder einfach ein paar Dummy-Lesezugriffe, bis alle eventuell vorherigen Lesepuffer, Bursts usw. abgearbeitet sind.

Aber einen _CS-Pin haben sie doch, oder? Was passiert wenn der beim RESET auf HIGH gezwungen und erst vom Controller programmgesteuert freigegeben wird wenn der soweit ist sich mit dem RAM zu unterhalten?

Wenn das nicht will koennte man versuchen CLK zum RAM beim RESET abzuschalten und erst wieder freigeben wenn man das RAM wieder braucht.

Gerrit

/CS auf high ist ein NOP-Befehl. Zum Lesen eines Speichers mit CL=3 sendet man einen READ-Befehl und danach drei NOP-Befehle. Beim dritten bekommt man die Daten. In anderen Worten: der SDRAM spuckt auch (oder gerade) bei /CS=high Daten aus. Das ist der Trick an SDRAM: während der die Daten ranschafft, kann man mit dem Bus was anderes tun oder sogar schon die nächsten Daten bestellen.

Beispiel:

Geht nicht, wenn das der gleiche Bus ist. Und da irgendwelche Logikgatter reinfummeln ist bei den Frequenzen auch nicht so der Bringer.

Stefan

Das liest sich im Datenblatt zum IC42S16160 aber anders:

Chip Select: CS enables (registered LOW) and disables (registered HIGH) the command decoder. All commands are masked when CS is registered HIGH. CS provides for external bank selection on systems with multiple banks. CS is considered part of the command code.

Laut dem Datenblatt ist CS auf LOW und alles andere (RAS,CAS,WE) auf HIGH der NOP, CS auf HIGH ist DESL.

Hm, die beschreiben das etwas anders... Komisch.

Dann nimm CKE, ist dafuer gedacht. Laut Datenblatt zum IC42S16160 werden bei CKE auf LOW die Outputs abgeschaltet (*). Womit das RAM tun kann was es will, auf den Leitungen nach draussen passiert nichts.

(*) Clock Enable: CKE HIGH activates, and CKE LOW deactivates internal clock signals,device input buffers and output drivers. Deactivating the clock provides PRECHARGE POWER-DOWN and SELF REFRESH operation (all banks idle), or ACTIVE POWER-DOWN (row ACTIVE in any bank).

Gerrit

Ah, sorry, nicht genug aufgepasst: bei Micron heißt DESL ebenfalls "NOP": COMMAND INHIBIT (NOP) und NO OPERATION (NOP).

Auch der IC42S16160 beschreibt z.B. auf Seite 42, wie er ohne Chipselect an den Daten rumdreht.

Ich werd's den Hardwerkern sagen, wenn sie mir mal wieder ein Board vorsetzen, wo RAM und ROM auf einem Bus hängt :-)

Stefan