FPGA + CoreRam kein ctBasic/VGA

[Hilstrom]

Ach Ihr lieben Leute, es will nicht gelingen!
Das von Segor gelieferte Komplettset aus FPGA-Board und CoreRam war schnell gelötet und mit aktuelle Firmware geflasht. Dem DCG-Modul das Panel entwendet und den Ersttest: 'LEDblink' erfolgreich bestanden. Da ich primär mein 'Lab' pcunabhängig betreiben möchte, ist mir das ctBasic wichtig. Doch ich komme nur bis zur ASCII-Darstellung, danach rührt sich nichts. Nach Abarbeitung des bereits erstellten Beitrags (http://thoralt.ehecht.com/phpbb/viewtop ... f=24&t=307), sowie gründlichster Säuberungsaktion der Platinen,( ich gab den Lötstellen alphabetisch sortierte Namen), fällt mir nur noch ein defektes RAM oder FPGA ein.
Zur genaueren Diagnose habe ich alles über SD geladen, was auf dem Markt erhältlich ist:
BounceBall, VGA_Test ergeben ein gute Monitordarstellung, die Test-LED auf dem Board blinkt dazu; Pacman = schwarzer Bildschirm bei blinkender Test-LED; ctBasic = ASCII; QVGA = wildes,buntes Muster; Frequenz = erfolgreiche Verbindung mit dem Vi, aber kein Messerfolg bei der Rückkopplung von N100-P99, die Test_LED leuchtet dabei deutlich schwächer und permanent.
Bevor ich mir bei Segor ein neues RAM kaufe wüsste ich gerne, ob es die nächstliegende Fehlerquelle ist.
Ich würde mich besonders über ermutigende Antworten freuen.
Vielen Dank im voraus.
Hilmar

[Mars09]

Hallo Hilmar,

genau dasselbe hatte ich auch schon. Bei mir lag es an einer merkwürdig reagierenden SD-Card. Von dieser Karte konnten zwar einige Dateien gelesen und ausgeführt werden, andere wiederum nicht. Nach langer vergeblicher Fehlersuche blieb nur noch die SD-Card als Fehlerquelle übrig. Nach Austausch der SD-Card funktionierte alles wie gewünscht. Das RAM wird übrigens nur beim ctbasic und PACMAN genutzt.

Ich hoffe, ich konnte helfen.

Gruß Marcus

[VGOE]

Ich habe exakt die selben Probleme wie Hilstrom (nur das DCG habe ich nicht). Invaders läuft, VGA Test läuft, Led-Blink ist auch kein Problem, aber BASIC, PAC-Man und Co ergeben entweder eine sauber Darstellung des ASCII Zeichensatzes (BASIC) auf weissem Grund, oder ein schwarzes Bild. Insgesamt habe ich 4 versch. SD Karten ausprobiert (16MB, 64MB, 128MB und 1GB) alle wurden vorher auf FAT mit Standardzuordnungsgrössen formatiert.
Natürlich wurde die Platinen ordentlich nach dem Löten gesäubert, wo bei ich aber sagen muss, das selbst die TEK Transputerkarten nach fast 20 Jahren immer noch einwandfrei trotz Flussmittelrückständen laufen. Lediglich per Frequenzen jenseits der 1GHz oder Spannungen im nV Bereich denke ich, dass sich Flussmittelrückstände bemerkbar machen.
Welche SD Karten wurden denn bisher erfolgreich eingesetzt?

[psclab38]

Ich habe exakt die selben Probleme wie Hilstrom (nur das DCG habe ich nicht). Invaders läuft, VGA Test läuft, Led-Blink ist auch kein Problem, aber BASIC, PAC-Man und Co ergeben entweder eine sauber Darstellung des ASCII Zeichensatzes (BASIC) auf weissem Grund, oder ein schwarzes Bild. Insgesamt habe ich 4 versch. SD Karten ausprobiert (16MB, 64MB, 128MB und 1GB) alle wurden vorher auf FAT mit Standardzuordnungsgrössen formatiert.
Natürlich wurde die Platinen ordentlich nach dem Löten gesäubert, wo bei ich aber sagen muss, das selbst die TEK Transputerkarten nach fast 20 Jahren immer noch einwandfrei trotz Flussmittelrückständen laufen. Lediglich per Frequenzen jenseits der 1GHz oder Spannungen im nV Bereich denke ich, dass sich Flussmittelrückstände bemerkbar machen.
Welche SD Karten wurden denn bisher erfolgreich eingesetzt?

Invaders läuft, VGA Test läuft, Led-Blink ist auch kein Problem,

Also alles, was IMHO kein RAM braucht. Schon mal gut, weil das FPGA dann intern ok ist.

Ich nehme mal an, daß die CoreRAM-Karte die einzige Steckkarte ist? Richtig?

Ich glaube mich zu errinnern, daß der Effekt des ASCII-Zeichensatzes im Display daher kommt, daß der Datenbus die acht niederwertigsten Adressbits "sieht", daher das "geordnete Bild. D. h. das RAM wird gar nicht angesprochen.
Unter Vorbehalt (ich hab die Unterlagen grade nicht greifbar): Müßte eigentlich identisch mit der Situation sein, in der die Karte gar nicht gesteckt ist. Schon mal probiert, ob sich da was ändert?

Was sagen denn die /WR und /OE-Leitungen? Bewegen die sich?

Zum Flußmittel: Das Flußmittel, das als Seele im Lötdraht enthalten ist, ist normalerweise komplett unbedenklich und kann bleiben. Wenn man aber zusätzliches Flußmittel, meist flüssig oder aus einem "Textmarker" verwendet, muß man schon SEHR sparsam sein, um nicht reinigen zu müssen. Eine halbe Stunde im Klimaschrank beim Test "Feuchte Wärme 50°" und dann werden schnell mal Übergangswiderstände bis in den zweistelligen Ohmbereich erreicht, die man nach meiner Erfahrung ohne Reinigung nicht mehr wegbringt.

Viel Erfolg beim Fehlersuchen
Paul

[VGOE]

Hallo psclab38,
ja, die Core-RAM-Karte ist die einzige Karte (ok, Panel hängt noch drann, aber das wird ja nicht vom FPGA verwaltet, ebenso der Opt-Bus).
Natürlich habe ich kein zusätzliches Flussmittel genutzt. Die Platinen wurden anschließend mit Alkohol gereinigt, abgewischt und 48 Stunden zum trockenen an die Seite gelegt (OK, 7 Tage bei mir ). Ich denke auch, dass die FPGA Platine einwandfrei läuft. Die einzelnen Leitungen zum RAM schaue ich mir am WE mit dem Oskar und LA mal genauer an. Meine Module sind erst gestern fertig geworden und die Tests wurden eigentlich zur Inbetriebnahme durchgeführt. Ichwerde weiter berichten ....

[psclab38]

Ich denke auch, dass die FPGA Platine einwandfrei läuft. Die einzelnen Leitungen zum RAM schaue ich mir am WE mit dem Oskar und LA mal genauer an. Meine Module sind erst gestern fertig geworden und die Tests wurden eigentlich zur Inbetriebnahme durchgeführt. Ichwerde weiter berichten ....

Ich hab grade mal den erwähnten Test gemacht: Basic geladen (ist default), mit abgezogener CoreRAM und siehe da: die ASCII-Tabelle. Da wird aus irgendwelchen Gründen das RAM nicht richtig angesteuert.

Manchmal ist's ein ganz simpler Fehler, z. B. einfach eine Lötstelle übersehen. Einfach alles nochmal mit der Lupe kontrollieren. Ist mir mit der CoreRam auch passiert: einen Pin an der VGA-Buchse hatte ich übersehen. ) Kein Bild...

Viele Grüße
Paul

[VGOE]

So,
nach dem alle Lötstellen noch mal genau geprüft wurden und keine Fehler erkenn- und messbar sind (hätte mich gewundert, da ich Löten beruflich gelernt habe) habe ich mir die Signale am RAM mit dem Oskar angesehen. Sauber Rechtecksignale mit einer Amplitude von genau 3V. Kein Signal ist "vermatscht" oder sonst auffällig. Die Flankensteilheit ist ebenfalls OK und die Überschwinger sind innerhalb der Toleranz. Trotzdem wird das RAM nicht erkannt.
Ein 1000uF Elko am SD Slot sollte jetzt auch evtl. SD-Karten Probleme aus der Welt geschafft haben.
Hat noch jemand Ideen?
Danke schon mal für Eure Mühen!!

[VGOE]

So,
beim BASIC habe ich auf B14 der Leiste (/OE am RAM) habe ich einen Sinus von 12,5MHz. Hat jemand eine Erklärung dafür?
PACMAN hat ein sauberes Signal auf B14.

Wie gesagt, Invaders läuft.

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.

[HSiebrecht]

Hallo Hilmar und VGOE,

so wie es aussieht habt Ihr die CoreRam Karten ja fast zur selben Zeit erhalten, welche Bezeichnung hat denn Euer RAM. Ich habe ausschliesslich BSI BS62LV4006PIP55 im Einsatz und mit dem RAM auf keiner der Karten jemals Probleme gehabt. Alle RAM's sind von Segor.

EIne mögliche Fehlerquelle : Die VG Leiste auf der CoreRam, da diese ja senkrecht montiert ist sieht man nicht wenn durch zuviel Lötzinn eine Brücke entstanden ist. RAM aus der Fassung nehmen und mit Ohmmeter auf die Fehlersuche gehen.

Ihr benutzt ja wohl nicht VG Connector 3 ?

So,
beim BASIC habe ich auf B14 der Leiste (/OE am RAM) habe ich einen Sinus von 12,5MHz. Hat jemand eine Erklärung dafür?
PACMAN hat ein sauberes Signal auf B14.

Wie gesagt, Invaders läuft.

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.

Habe mal bei mir B14 gemessen, bei ct-Basic habe ich auch die 12,5 MHz, dies ist der Takt des T65Cores ( 6502 CPU ), nur habe ich da keinen Sinus sondern ein Rechteck mit Überschwingern beim Pegelwechsel.

Wie schon vorher geschrieben wurde, Invaders benötigt kein RAM, Pacman reichen 32 KB, ct-Basic braucht den 512 KB Chip.

[VGOE]

Hallo HSiebrecht,
ich habe genau das selbe RAM von Segor im Einsatz. Sämtliche Verbindungen wurden auf Kurzschluss und offene Verbindungen vom RAM bis hin zum FPGA durchgemessen. Es liegen keine Kurzschlüsse vor und auch keine Unterbrechungen.
Der "Sinus" ist als Rechteck zu interpretieren, wenn man die zur Bildung notwendigen Oberwellen nach spätestens der 2ten vernachlässigt Die Signale bei PACMAN sind wirklich saubere Rechtecke mit einem sehr geringen Überschwingen.
Ich werde noch ein Testprogramm fü den FPGA schreiben und mit die Signale dann noch mal ohne CORERAM ansehen.
Entweder ist der RAM Baustein knapp an seinen Toleranzen oder der FPGA hat Probleme. Auf jeden Fall ist mir ein so harter "Hund" in 20 Jahren Hardwareentwicklung noch nicht uner gekommen

[Mars09]

Hallo VGOE,

dasselbe Problem hatte ich auch schon, allerdings mit der DACRAM Karte. Ich habe auch alles durchgemessen und keinen Fehler feststellen können. Ich habe sogar zusätzlich eine CORERAM Karte aufgebaut und es ging immer noch nicht. Bis ich schließlich mit Hilfe des IFP über die serielle Schnittstelle vom PC aus die Befehle der BASIC.INI Datei einzeln eingegeben habe. Es funktionierte alles bis zu dem Punkt wo die Datei EHBASIC.DAT geladen werden sollte. Hier gab es eine Fehlermeldung, die auf die SD Card hindeutete. Auch mehrfaches Neuformatieren der zuerst eingesetzten Lexar 128 MB SD Card half nichts. Erst als ich eine SANDISK 256 MB SD Card ausprobiert habe funktionierte es auf einmal mit der DACRAM- und CORERAM Karte.

Gruß Marcus

[VGOE]

Na dann besteht ja noch Hoffnung

Versuche ich mal, aber vorher schreibe ich noch den FPGA Test.

[Hilstrom]

Einen herzlichen Gruß an diejenigen, die sich so hilfsbereit des Themas angenommen haben. Ich bin allen Lösungsansätzen, so weit mich mein Horizont trug, nachgegangen. Alle zehn aufzutreibende SD-Karten ergaben die gleichen, hinreichend beschriebenen Ergebnisse. Ich habe bei Segor komplett bestellt und so auch das gleiche RAM. Da ich kein hinreichend funktionierendes Oszi habe, kann ich zu Spannungsverläufen keine Stellung nehmen.
Da ich beim flashen des Mega644 zuerst Probleme hatte, die ISP-Taktrate war zu gering, habe ich heute alles erneut aufgespielt. Das Ergebnis ist eine deutliche Musterverschiebung bei dem QVGA-Test und zur ASCII-Darstellung in den oberen Zeilen beim Basic, gesellten sich über den ganzen Bildschirm verteilte, einzelne Buchstaben in grün. Das sieht zwar nach mehr aus, macht mich aber nicht wirklich glücklich!
Liegt das Problem eventuell zwischen FPGA und Mc?
Kann ich als Normaldummer das FPGA testen?
Vielen Dank!
Hilmar

[HSiebrecht]

Uuupppsss, da ist ja jemand auch noch spaet unterwegs.

@ Unsere ct-Basic "Problemkinder".

Schreibt doch mal bitte aus welcher Ecke / Land, vieleicht sogar Stadt Ihr kommt.

Eventuell kommt es dann zu einem Treffen mit einem Forumsteilnehmer, der funktionsfähiges Equipment hat und damit die Fehlersuche für Euch extrem vereinfacht.

OK, OK, ich habe auch nur einen "Teil" meines Bundeslandes angegeben, aber meine Heimatstadt Dortmund soll nun auch kein Geheimnis sein.

Ich könnte mir auch vorstellen Euch meine "CoreRam-Fädeltechnik", die durch mehrere Umbauten nicht mehr sonderlich professionell aussieht, aber funktioniert, zur Funktionskontrolle zur Verfügung zu stellen. An einer funktionierenden 512 MB SD-Card sollte es auch nicht scheitern. Sorry, aber eine von den zwei FPGA Karten rücke ich zum Versand nicht heraus.

Zu Hardware von Segor : Alle meine verbauten Bauteilsätze, Platinen und einzeln bestellten Bauteile für das ct-Lab habe ich über Segor bezogen. Ich hatte bis heute nicht ein defektes Bauteil, deshalb sollten wir davon ausgehen, das es bei Euch auch so ist.

@Hilmar Neu geflashed und nun ein "anderes Fehlerbild", das ist nicht gut. Womit flashed Du denn, Hardware und welches Programm ? Fuse Bits nach Anleitung gesetzt und auch mal kontrolliert ?

Keine Panic, es wird schon.

[PatHoff]

Hallo Hilmar, Hallo VGOE,

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.

Ich hatte auch ein massives Problem mit meiner FPGA-Grundplatine. Und zwar hatte ich nach dem Aufbau die Spannungen nachgemessen und musste auf der 1,2V-Schiene (VccInt) 2,45V feststellen. Zuerst dachte ich, der U5 (LM317) funktioniert nicht, aber dann fiel mir die Ähnlichkeit mit den 2,5V von VccAux auf. Und dann habe ich nach einem Kurzschluss gesucht und ihn schließlich an den Lötstellen des FPGA gefunden. Und zwar zwischen Pin 48 (VccAux) und Pin 49 (VccInt). Das konnte man eigentlich nicht mehr richtig sehen. Es sah nur etwas unsauber aus. (Segor verwendet wohl Lötpaste zum Auflösten des FPGA !??) Außerdem sitzt mein FPGA da nicht ganz genau fluchtend auf den Lötpads auf, s.d. der Zwischenraum zusätzlich noch schmaler wurde (die Pins haben ja eh nur 0,5mm Abstand, von Mitte zu Mitte !) Ich habe deswegen auf Verdacht hin da mit einer Zahnbürste (!!!) geschrubbt. Und siehe da ! Jetzt habe ich auch 1,2V an der der VccInt-Schiene. Glücklicher Weise hat der FPGA diese Überspannung an VccInt nicht übel genommen und läuft seitdem. Allerdings habe ich gerade erst die DACRAM-Karte fertig gestellt und kann nicht Testen ob auch der RAM läuft, weil das c't-Wiki gerade nicht funktioniert.

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. Also vielleicht hilft euch ja auch das "FPGA-Schrubben". Wie gesagt: Richtig gesehen habe ich den Kurzschluss auch nicht, aber der Effekt war bei mir eindeutig, weil es zufällig 2 spannungsführende Pins betraf.

Viele Erfolg bei der Fehlersuche !
Patrick