FPGA + CoreRam kein ctBasic/VGA

[VGOE]

Erstmal vielen Dank für die vielen Antworten!
Nach dem ich jetzt so ziemlich alle SD Karten aus meiner Nähe im Einsatz hatte (insgesamt so 15 Stück mit Kapazitäten zwischen 16MB und 4GB sowie allen namenhaften Herstellern) glaube ich nicht, dass es unbedingt an den SD Karten liegt. Festgestellt habe ich allerdings, dass die Hintergrundfarbe inzwischen von weiss auf schwarz gewechselt hat und einige Konfigurationen zusätzliche Zeichen (grün, blinkend usw.) produzieren. Die Lötstellen wurden alle samt mit einer Lupe kontrolliert, auch die des FPGA. Ebenso wurde die "Zahnbürste" schon längst genutzt, leider ohne Erfolg. Da auch alle Leitungen des RAMS auf Kurzschlüsse und Durchgängigkeit bis um FPGA getestet wurden tippe ich inzwischen entweder auf das RAM selber oder den FPGA. Liegen bei euch Signale an den höchstwertigen 3 Adressleitungen des RAM an?
Mit meinem Testprogramm für das FPGA bin ich schon ein Stück weiter (VHDL steht), jetzt kämpfe ich mit der Entwicklungsumgebung von Xilinx bzgl. den Constrains. Da ist die CPLD Umgebung von Lattice deutlich Entwickler freundlicher

[Hilstrom]

Hallo Patrick,
Du hast ja lustige Ideen, als ob ich nicht schon genug geputzt hätte, alles unter einer (5 dpt) Lupe betrachtet und mit einer feinen Tastnadel umfahren hätte. Ich habe nachgelötet und mit einer feinen Dremelkupferbürste kunstgleiche Objekte geschaffen. Ich habe gemessen und ich habe mich gewundert. Und ich habe gelesen, was dies Forum auch immer schrieb : Patrick: "Also vielleicht hilft euch ja auch das 'FPGA-Schrubben'".
Hätte er mir dazu beschwörende Formeln und eine alberne Körperhaltung auferlegt, so hätte ich auch dies genau befolgt.
Mittels Borstenpinsel, Zellstoff und Waschbenzin bin ich dem FPGA zu Leibe gerückt und habe es geschrubbt.
Fertig! Wo war das Problem? Alles funktioniert. Ich habe die Uhr gestellt, und mir bunte Grafen zeichnen lassen.

Zwischen den Beinchen des FPGA habe ich eine Paste ausgewaschen. Danke Patrick !

Und nun noch aus Kruckel, dem schönsten süd-westlichen Stadtzipfel Dortmunds, einen westfälischen Gruß an Helmut. Ich wäre Dir weinend mit dem Board auf die Bude gerückt.
Hilmar

[HSiebrecht]

Hallo zusammen,

@ Hilmar, toll das es jetzt bei Dir funktioniert, versuchst Du dich auch noch an der IOCORE ? Habe da massive Probleme, werde aber auch mal das FPGA schrubben versuchen. Viele Grüße aus dem östlichen Brackel.

@ VGOE

Liegen bei euch Signale an den höchstwertigen 3 Adressleitungen des RAM an?

Unterstelle mal Du willst ct-Basic laden, im Normalfall kommst Du mit 64 KB aus, also A0 - A15. Die höherwertigen Bits A16 - A18 kommen nur zum tragen wenn Du das Bank-Switching ( Bank 1 - Bank 7 mit je etwas weniger als 48 KB ) des ct-Basic benutzt, leider kommst Du ja noch nicht so weit. Somit sollten A16 - A18 bei Dir Low-Pegel haben.

[VGOE]

Grrrrrrr,
jetzt habe ich die gesamte Platine mit einem Spezialreiniger gewaschen und alle Lötstellen per Lupe kontrolliert. Null Effekt.
Die Adressleitungen oberhalb 64K sind wie erwartet LOW. Die restlichen Signale sauber.
Nach meinem Verständnis hat entweder das RAM einen Schlag (glaube ich nicht so recht), oder die Konfiguration wird nicht sauber von der SD-Karte gelesen. Für Letzteres spricht der Umstand, dass das Bild auf dem Monitor teilweise mehrere schwarze, ein Zeichen große Blöcke hat, je nach verwendeter SD-Karte. Insgesamt habe ich jetzt mehr als 8 verschiedene Karten zwischen 64 MB und 4GB (keine HS Karten) probiert.
Welche Karten funktionieren denn fehlerfrei?

[HSiebrecht]

Hallo VGOE

Grrrrrrr,
jetzt habe ich die gesamte Platine mit einem Spezialreiniger gewaschen und alle Lötstellen per Lupe kontrolliert. Null Effekt.
Die Adressleitungen oberhalb 64K sind wie erwartet LOW. Die restlichen Signale sauber.

Auch die Datenleitungen ?

Nach meinem Verständnis hat entweder das RAM einen Schlag (glaube ich nicht so recht), oder die Konfiguration wird nicht sauber von der SD-Karte gelesen. Für Letzteres spricht der Umstand, dass das Bild auf dem Monitor teilweise mehrere schwarze, ein Zeichen große Blöcke hat, je nach verwendeter SD-Karte..

Ein Bild sagt manchmal mehr als ...... Kannst Du mal ein Bild hochladen.

Insgesamt habe ich jetzt mehr als 8 verschiedene Karten zwischen 64 MB und 4GB (keine HS Karten) probiert
Welche Karten funktionieren denn fehlerfrei?.

Habe eine 512 MB Card von meinem PDA im Einsatz, Type kann ich leider nichts zu sagen, müßte dann eventuell mal Linux befragen.
Als zweite habe ich eine "CORSAIR 60x , SD , 1 GB , SD FLASH MEDIA CARD" im Einsatz.

[PatHoff]

Du hast ja lustige Ideen, als ob ich nicht schon genug geputzt hätte, alles unter einer (5 dpt) Lupe betrachtet und mit einer feinen Tastnadel umfahren hätte.

Ach, auch die FPGA-Kontaktbeinchen ? Oder nur Deine eigenen Lötstellen ? Weil: Wenn Du vorher schon mit einer Testnadel herum gefahren bist, dann sollte mich wundern, dass das zusätzliche Schrubben geholfen hat. Aber vielleicht bekommt man anders diese Lötpaste da nicht runter ... ?

... oder die Konfiguration wird nicht sauber von der SD-Karte gelesen. Für Letzteres spricht der Umstand, dass das Bild auf dem Monitor teilweise mehrere schwarze, ein Zeichen große Blöcke hat, je nach verwendeter SD-Karte.

Ist das reproduzierbar ? Ich meine: Ein und dieselbe SD-Karte ergibt die gleichen schwarzen Blöcke an den gleichen Stellen ? Oder variiert das, selbst wenn Du die gleiche SD-Karte nimmst und immer wieder neu lädst ?
Gegen einen SD-Karten-Defekt spricht aber auch, dass andere Programme (Invaders) laufen, die kein RAM brauchen.
Alternativ bliebe nur die Möglichkeit, sich mal gegenseitig die Karten zuzuschicken (meine DACRAM-Karte konnte ich inzwischen erfolgreich testen. Das ct-Lab-Wiki geht ja wieder !)

Gruß !
Patrick

[VGOE]

Hiho,
es ist nicht reproduzierbar. Die Blöcke variieren ständig.
Was mich, wie gesagt, noch stutzig macht, ist der 12,5MHz Takt auf B14 d.h. /OE am RAM. Nach meiner Meinung sollte dort kein fester Takt anliegen, sondern nur bei Lesezugriffen ein LOW zu finden sein.
Langsam wirds echt peinlich, und ich verrate mal lieber doch nicht, was ich von Beruf bin

[PatHoff]

Was mich, wie gesagt, noch stutzig macht, ist der 12,5MHz Takt auf B14 d.h. /OE am RAM. Nach meiner Meinung sollte dort kein fester Takt anliegen, sondern nur bei Lesezugriffen ein LOW zu finden sein.

Ich hab' mich noch nicht so mit den Internas der Realisierung der Grafik beschäftigt, aber liegt nicht der Grafikspeicher im RAM ? D.h. allein schon zur VGA-Anzeige müsste dauernd lesend auf den RAM zugegriffen werden. Ich weiß nicht, wie die Bildwiederholrate ist, aber da müssten schon eine ganze Menge Lesezyklen pro Sekunde auftreten, s.d. mich die 12,5MHz an /OE nicht wundern würden. Leider hab' ich kein Oszilloskop zu Hause, um das mal an meiner funktionierenden RAMDAC-Karte zu testen.

Wie sind denn die Takte an den Addressleitungen ? Bei sequenziellen Lesezugriffen auf einen Speicherbereich (wie er z.B. beim ständigen Auslesen des Video-RAMs geschieht) würde ich ja einen jeweils halbierten Takt für steigende Addressleitungen erwarten. An A0 müssten wieder die 12,5MHz anliegen, an A1 6,25MHz, an A2 3,125MHz, usw.

Gruß !
Patrick

[Hilstrom]

Hallo Patrick,
ja ich habe, was man eventuell gar nicht darf, mit Waschbenzin und Borstenpinsel den Chip zwischen den Beinchen geschrubbt, ein wenig gewartet und ausprobiert. Es läuft immer noch mit allen SD-Karten, u.a. Scandisk 512MB oder auch einer 1G HAMA.
Wenn Helmut möchte, biete ich ihm meinen Aufbau zur vergleichenden Diagnose an, denn ich bin nur ein technisch laienhafter, aber nun stolzer Besitzer einer vorgefertigten Platine (FPGA und CoreRam).
Hilmar

[Klaus_Phi]

Hallo VGOE,

die aufgetretenen Fehler konnte ich nachvollziehen.

Mein Testaufbau sieht wie folgt aus:

IFP, CORERAM, DACRAM, RAM+RS232 handverdrahtet.

Mit IFP und CORERAM laufen BASIC, PACMAN und SPACE-INVADER ohne Probleme. Mit IFP und DACRAM gab es jedoch Probleme. Der schon erwähnte ASCII Zeichensatz wurde angezeigt. BASIC ließ sich einfach nicht starten.
Dann testete ich die handverdrahtete RAM Baugruppe und mußte feststellen, daß SPACE-INVADER lief und PACMAN wirre Muster lieferte, BASIC lief auch nicht.
Bei der DACRAM Karte stürzte sogar der ATMEGA ab. Da die DACRAM Baugruppe mit anderen FPGA Designs lief, war ich sehr verwundert.
Dann hatte ich die Stromversorgung durch das IFP-Modul untersucht und festgestellt, daß alles im Grenzbereich arbeitet.
Wenn ich mit der DACRAM Karte arbeite und BASIC starte sinkt die Spannung des 7805 Spannungsreglers auf der IFP Baugruppe unter 7V.
Die Messung wurde bei 233V Netzspannung durchgeführt. Bei niedrigeren Netzspannungen tritt der Fehler stärker auf.
Aber das ist nur ein Problem. Es scheint auch noch ein Timing Problem an dem SRAM zu geben.
Wenn ich die 5V satt von der IFP Baugruppe von einem externen Netzteil einspeise müßten alle Probleme gelöst sein. Dem ist leider nicht so.
In der Datei main.ucf kann man die maximalen Ströme der Pins einstellen. Wenn nichts angegeben wird, wählt das ISE Programm 12 mA.
19 Adreßleitungen, 8 Datenleitungen, WE, OE ergeben 29 Leitungen. 29 mal 12mA ergeben 348 mA für die Treiberleistung zum RAM. Dies ist nur ein theoretischer Maximalwert. Er soll nur zeigen mit welchen Größen wir arbeiten.

Welche Optionen haben wir?

Die Netzspannung ändern. (Zu aufwendig).
Die Stromaufnahme des FPGA ändern. (Das geht schnell).

Ändere in allen Zeilen der UCF-Datei die das VRAM betreffen wie folgt:

NET "VRAM_D(0)" LOC = "P20" | IOSTANDARD = LVTTL;
NET "VRAM_D(0)" LOC = "P20" | IOSTANDARD = LVTTL | DRIVE = 2; # 2mA

Übersetze das Design und kopiere die erzeugte main.bit Datei auf die SD-Card.

Alles bisher Vorgeschlagene war in Ordnung und wurde überprüft.
Wir gehen nun in die End-Phase der Fehlersuche.

Scheibe mir einfach, was nach Deinen Versuchen passiert ist.

Mit freundlichen Grüßen

Klaus Philipp

[Klaus_Phi]

Hallo VGOE,

ich habe noch einige Messungen durchgeführt. Dann habe ich mich entschlossen, den Kondensator auf der IFP Baugruppe zu ersetzen. Der vorhandene 470µF Kondensator C11 wurde durch 1500 µF ersetzt. Die Spannung am Eingang des Spannungsreglers U3 7805 sinkt beim Start von Basic.ini nur noch auf 8.5V. Damit sollte Dein Problem behoben sein.
Meine vermuteten Timingfehler sind auf unsachgemäße Einstellungen des ISE VHDL Compilers zurückzuführen.
Meine drei Baugruppen funktionieren nun mit allen Basic Programmen.

Mit freundlichen Grüßen

Klaus Philipp

[VGOE]

Vielen Dank für die Antworten!!
Als Energieversorgung habe ich nicht das IFP Modul im Einsatz, sondern ein seit Jahren bewährtes 19Zoll Netzteil der Firma Vero mit 5V/6A und +/- 12-15V /1A (Trivolt PK60). Die Spannung ist exakt auf 5,00V eingestellt. Evtl. werde ich mal die Sense-Leitungen direkt an den Spannungsregler der FPGA Platine legen.
Das Timing ist auch nach meiner Ansicht das Hauptproblem. Wie gesagt, alle Signale sind sauber auf dem Oskar zu beobachten und auch die Versorgungsspannungen sind sauber. Im Moment schreibe ich gerade ein Testprogramm für den FPGA ohne die CoreRam Baugruppe. Leider ist das Xilinx-ISE nicht so ganz mein Fall und im Vergleich zu den bisher von mir eingesetzten Lattice Tools gewöhnungsbedürftig
Ich berichte weiter über meine Ergebnisse ....

[cm]

Nach dem ich alle Lötstellen genausten inspiziert habe und nochmal nachgelötet habe, denke ich, das der RAM Baustein auf der CORERAM Platine doch wohl nicht so richtig mit 3V3 zusammen arbeiten will.

Sollte es aber bei anderen FPGA's auch Kurzschlüsse zwischen den Pins geben, und die sind bei irgend welchen I/O-Pins, dann stellt man das wohl am ehesten beim RAM fest, weil der am meisten I/O-Leitung braucht.

Das ist leider auch bei meiner ersten von Segor gelieferten Platine so gewesen, hier allerdings bei anderen Pins. Mein selbstgelöteter Prototyp lief dagegen auf Anhieb. Ich tippe extrem auf schlecht gelötetes FPGA, da sich der Fehler nur bei RAM-Anwendungen bemerkbar macht. Eigentlich ein Reklamationsgrund...

Das Timing bei ct-BASIC ist völlig unkritisch (80 ns Zykluszeit), selbst Uralt-SRAMs mit 100ns und 5V liefen bei mir noch (natürlich außerhalb der Spezifikationen).

Im Zweifelsfall alle FPGA-Pins nachlöten: Satt mit 0,5er Lötzinn drüber, bis alle Pins einer Seite miteinander verbunden sind, dann mit Lötsauglitze alles wieder absaugen und mit 10x-Lupe kontrollieren. Mit bloßem Auge erkennt man nix, selbst eine Lupenleuchte vergrößert nicht stark genug! Hartnäckige Brücken kann man mit einem Cuttermesser freibekommen. Pastöses SMD-Flussmittel aus der Tube sollte, falls angewendet, tatsächlich entfernt werden, das aus dem Lötzinnseele ist nur bei der DIV-Platine störend.

Und ja, wenn das RAM nicht geht, läuft natürlich auch der "6502" nicht an. Dann bleibt der initiale Testdaten-Inhalt der FPGA-internen BlockRAMs auf dem Bildschirm (die ASCII-Zeichen), weil sie niemals überschrieben werden. An sich schon mal ein gutes Zeichen, weil die FPGA-Konfiguration dann einwandfrei geklappt hat.

1000µ/10V Low ESR auf der 3,3V-Leitung ist unbedingt empfehlenswert, zusätzlich kann man noch den 100n-SMD direkt am Kartenslot durch einen 4µ7 oder 10µ SMD-Keramischen ersetzen (zuhauf auf ausgemusterten PC-Mainboards nahe der CPU zu finden), dann sollten auch "unfähige" SD-Karten laufen. Und wenn man schon mal dabei ist: Ein paar davon statt der 100n-SMDs unter dem FPGA (Lötseite) schaden auch nicht. Da war ich wohl mit der Abblockkapazität etwas geizig. Das ist aber nicht der Grund für ein nicht laufendes ct-BASIC!

[cm]

Ach ja, noch ein Tipp:

Einfach mal nach Laden von ehbasic.dat die Datei wieder auslesen und abspeichern lassen (mit dem BSV-BlockSave-Befehl), etwa mit dem folgendem INI-Script:

Code: Alles auswählen

//BASIC-Konfiguration laden
CFG=main.bit
AIW=1
AIS=0
AIR=128
// Start ROMs bei $C000 = 49152
AIM=49152
CFG=ehbasic.dat
// Reset manuell
VAL 129=0
// auslesen und in Datei speichern
AIM=49152
AIE=65535
BSV=test.dat

Dann SD-Karte entnehmen und die Dateien test.dat und ehbasic.dat mit Hex-Editor vergleichen. Da sollte man dann sehen, welches Bit klemmt (und ob überhaupt etwas angekommen ist). Ggf. mit anderen Start- und Endadressen oder einer eigens angelegten Testdatei wiederholen, etwa mit

Code: Alles auswählen

//BASIC-Konfiguration laden
CFG=main.bit
AIW=1
AIS=0
AIR=128
AIM=0
BLD=mytest.dat
// auslesen und in Datei speichern
AIM=0
AIE=65535
BSV=gelesen.dat

Die Testdatei mytest.dat (etwa ein Zufallsmuster) sei hier 65536 Bytes lang (AIE=65535), damit kann man dann alle Adressierungsfehler im 64K-Bereich entlarven. Hier habe ich übrigens BLD statt CFG genommen, was für .DATs gleichwertig ist.

Wenn hier wenige (!) einzelne Bytes nicht übereinstimmen, hat der 6502 allerdings versucht, die Testdatei auszuführen und evt. an verschiedenen Stellen überschrieben; das ist dann kein Grund zur Sorge. Das darf im "ROM"-Bereich ab 49152 nicht passieren, dieser Bereich ist für die CPU im FPGA "schreibgeschützt".

Hope that helps...

[cm]

Hiho,
es ist nicht reproduzierbar. Die Blöcke variieren ständig.
Was mich, wie gesagt, noch stutzig macht, ist der 12,5MHz Takt auf B14 d.h. /OE am RAM. Nach meiner Meinung sollte dort kein fester Takt anliegen, sondern nur bei Lesezugriffen ein LOW zu finden sein.
Langsam wirds echt peinlich, und ich verrate mal lieber doch nicht, was ich von Beruf bin

Tja, da wird der arme 6502 wohl ein korrumpiertes Programm vorgefunden haben, warum auch immer, und läuft amok. 12,5 MHz auf /OE ist OK, das geht einmal im 6502-Taktzyklus auf low, nur dann nicht, wenn ins RAM geschrieben wird. Da die CPU die meiste Zeit Befehle holt, misst man hier 12,5 MHz.