BIOS chip LPC/FWH ansteuern

Hi dse!

Ich schicke meinem Mikrokontroller ueber die serielle Schnittstelle Kommandos, dass er einzelne Leitungen umschaltet (Pegel, I/O). So wollte ich sehen, ob ich das Protokoll richtig verstanden habe, bevor ich es in den uC programmiere. Aber sowohl ein LPC [1], als auch ein FWH [2] reagieren nicht. Der LPC war der Grund fuer die Aktion, denn bei ihm ist das BIOS upgrade schief gegangen. Ich hab ihn dann als defekt eingestuft, weil CE# einen Kurzschluss nach Masse hatte. Aber auch der FWH schaltet nach dem TAR (bus turn around) die Busleitungen nicht auf

0000. Die Signale sind instabil und wenn ich die pull ups vom uC (ATmega168) aktiviere, bekomme ich 1111.

Kann das vielleicht daran liegen, dass ich zu langsam bin? Ich schaue zwischen den Taktzyklen z.B. im Datenblatt nach, damit ich weiss, was ich als naechstes anlegen soll. Normal rennen die ja mit 33 MHz Takt. Fuer CLK Cycle Time ist nur 30 ns Minimum angegeben, kein Maximum.

lg, Bernhard

[1] SST40LF040B,
formatting link

[2] SST49LF004A,

formatting link

Reply to
Bernhard Kuemel
Loading thread data ...

Die Taktleitung der Chips ist sehr schnell und kritisch. Allerdings unterstützt der Treiber nur einen chip. Ob der Quellcode noch verfügbar ist weiß ich nicht denn das ganze Projekt war auf eine Spielkonsole ausgerichtet.

formatting link

--
MFG Gernot
Reply to
Gernot Fink

Hmm, ich habe jetzt die Taktleitung "direkt" an den uC gehaengt, und damit eine von 2 Steckschienen und die Verbindung ueber ein 2 pin langes Stueck Lochstreifen einer Lochstreifenplatine eliminiert:

formatting link

Sollte die Leitungskapazitaet und -induktivitaet reduzieren. Das Ding reagiert aber noch immer nicht.

Ich haette hier noch einen SMD Inverter mit Schmitt trigger [1]. Soll ich den vielleicht vor den Takt Eingang schalten?

Der hat output transition time: (GND = 0 V; tf = tf = 6 ns [2]; CL = 50 pF)

19 ns (typ, Vcc=2V) 7 ns (typ, 4,5V) 75 ns (max, 2V) 15 ns (max, 4,5V)

Der SST49LF004A will aber: CLK Slew Rate (peak-to-peak) 1(min) 4(max) V/ns

Macht fuer 3V 3 ns max. transition time. Geht sich nicht aus, mit dem

74HC14D. Muss ich mir da echt noch was schnelleres suchen, damit der die Taktflanken erkennt?

Hmm, aber der SST49LF004A hat ja nicht 50 pF Eingangskapazitaet [3], sondern 12 pF. Naja, ich probier's mal ...

lg, Bernhard

[1] 74HT14D
formatting link
[2] Was heisst "tf = tf = 6 ns" im Datenblatt? Is das ein Tippfehler? [3] C(I/O) I/O Pin Capacitance 12 pF C(in) Input Capacitance 12 pF

Sind C(I/O) und C(in) Kapazitaeten verschiedener Pins? Die Busleitungen sind I/O, Takt ist nur Eingang. Oder verschiedene Kapazitaeten am selben Pin und ich muesste die addieren? Aber mit 24 pF waere ich immer noch unter 50 pF.

Reply to
Bernhard Kuemel

Ein kleines Stueckchen Leitung kommt aber auch noch dazu ...

Reply to
Bernhard Kuemel

Bei mir funktioniert ein 74lvx14 als Takttreiber der ca. 1.5 cm vom FWH entfernt ist.

Ich würde das Signal danach sicher nicht mehr über ein Sreckbrett führen und auch den VCC-Abblockkondensator an den Sockel löten.

Einen funtionierenden Quellcode für den Linuxtreiber findet man mit google wenn man nach "lmilk-0.20" sucht und den zweiten treffer verwendet.

Wichtig ist aber die richtige Basisaddresse des FWH zu verwenden da der Chip sonst nicht reagiert.

--
MFG Gernot
Reply to
Gernot Fink

So habe ich das mit meinem Inverter auch gemacht. Geht leider noch immer nicht.

Ich hab mal die Versorgungsleisten des Steckbretts mit weiteren 22 nF Kondensatoren gepflastert. Wenn das nichts reicht, muss ich wohl sehen, wie ich Kondensatoren naeher an die Fassung kriege.

Compiliert leider nicht und Doku hab ich auch keine gefunden. Vielleicht such ich im Quelltext, ob ich was brauchbares zum Protokoll finde.

Ja, da bin ich auch etwas unsicher. Die ID Pins lasse ich von den internen pull downs auf 0 ziehen und habe das Feld IDSEL auf 0000b.

IMADDR: Der SST40LF004A dekodiert nur die niedrigen Felder, also habe ich die ersten 2 auf 0000b, mit Ausnahme von a22, um den flash Speicher zuwaehlen. Laut Speicherkarte ist der Adressbereich FFF8 0000h-FFFF FFFFh, also nehme ich 8 0000h, zusammen 048 0000h. FFFF FFFFh hat eben auch nicht gefunkt.

Ich kann mal ein komplettes Protokoll einer Transaktion posten, aber ich will nicht zu viel fordern. Ich sollte wohl eher zuerst div. Quellcodes studieren.

Bernhard

Reply to
Bernhard Kuemel

Hier mal ein Protokoll eines Pm49LF004. Die Meldung "SST 49LF040 (4Mbit)" kommt von der Quellcodemodifikation.

CHEAPLPC on printer port at 0x378 wr fff85555 aa wr fff82aaa 55 wr fff85555 90 rd fff80000 9d rd fff80001 6e wr fff85555 aa wr fff82aaa 55 wr fff85555 f0 Flash at address FFF80000 reports device ID man=9D dev=6E SST 49LF040 (4Mbit) READING from FFF80000 -> FFFFFFFF to tmp FFF80000 rd fff80000 2f rd fff80001 2a rd fff80002 2a rd fff80003 2a rd fff80004 2a rd fff80005 2a rd fff80006 2a rd fff80007 2a

Der Quellcode ist ja alt und unterstützt den Chip nicht ohne Änderung. Ein übersetzten könnte mit einer älteren Linux distribution eher klappen. Ich denk da an die DSL.Livecd bei der man den gcc aus dem Netz nachladen kann.

Gernot

--
MFG Gernot
Reply to
Gernot Fink

Yeah yeah, mein BIOS chip (SST 49LF040) hat erstmals geantwortet. Zwar noch etwas verstuemmelt, aber eindeutig eine von der Adresse abhaengige Antwort.

Ich weiss nicht, was bisher genau das Problem war, weil es da mehrere definitive und moegliche Ursachen gab.

Jetzt habe ich ...

  • Taktleitung ueber 2 Inverter mit Schmitttrigger eines 74HC14D. Die uebrigen Eingaenge auf Masse. 100 nF SMD Kondensator am Vdd Pin zu Masse.
  • 100 nF SMD Kondensatoren an den Vdd Leitungen zu Masse
  • 10 uF Elko an einem Vdd Anschluss
  • schnelle, ausprogrammierte Abfragesequenz mit einem ATMega168 mit
18,432 MHz (ermoeglicht auch 115,2 kpbs serielle Datenuebertragung zum PC).
  • Weitere 100 nF und Elkos an den Steckbrett Stromschienen und am uC.
  • 3.3 V aus einem ATX Netzteil. Sollte zwar etwas mehr sein fuer 18,432 MHz, aber geht.

lg, Bernhard

Reply to
Bernhard Kuemel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.