Hallo zusammen, bin leider ein Neuling was Softcore µCs auf FPGAs angeht. Deshalb habe ich mich dazu entschieden, das LatticeMico32 Tutorial für Diamond 3.1 zu absolvieren. Verwende dafür wie auch im Tutorial das LatticeECP3 Versa Board mit dem ECP3 LFE3-35EA FPGA. Bin soweit recht gut zurecht gekommen. Konnte erfolgreich den ersten Bitstream per JTAG 1532 Mode als Fast Programm direkt auf den FPGA laden und per Debugging Oberfläche der LatticeMico32 C/C++ SPE Software den C Code laufen lassen. Nun komme ich aber zu dem Punkt in dem der C-Code und der FPGA-Bitstream zum Deployment auf den SPI Flash auf dem Versa Board vorbereitet wird. Nach durchführen dieser Schritte, dem Zusammenführen von C-Code und FPGA-Bitstream zu einem SPI Flash Image und dem Aufspielen dieses Image auf dem SPI Flash scheint es jedoch, also könnte sich der FPGA nicht vollständig initialisieren zu können und daher kann er auch nicht den C-Code zum laufen bringen. Ich habe sämtliche Schritte exakt durchgefüht und das nicht nur einmal. Ich habe bereits auch nochmal das gesamte Tutorial durchgeführt, in der Vermutung, ich hätte bereits zu Beginn einen Fehler gemacht. Ich habe auch den gleichen Bitstream und C-Code auf einem eigens entwickeltem Board auf den SPI Flash aufgespielt und da scheint sich zumindest der FPGA initialiesieren zu könnten, jedoch fängt der C-Code nicht an zu laufen, bzw. der Bootlaoder schafft es nicht den C-Code in den Flüchtigen Speicher zu laden. Bin mir da nicht sicher, wo der Fehler genau liegt. Habe bereits auch den Software Developers User Guide zur Hilfe herangezogen mit dem Kapitel SPI Flash Deployement, das konnte mir leider aber auch nicht weiterhelfen. Bin mittlerweile am Ende meiner Ideen was ich noch unternehmen könnte, bzw. wo der Fehler liegt. Habe nun gehofft, dass hier vielleicht einer Erfahrung mit dem SPI Flash Deployment hat, oder noch besser jemand bereits das Tutorial erfolgreich durchgeführt hat und dabei vielleicht auch auf diesem Fehler gestoßen ist und eine Lösung dafür hat.
Rene Lusseni schrieb: > Bin mir da nicht sicher, wo der Fehler > genau liegt. Dann muß man das Problem teilen und sicherstellen, daß die Teile funktionieren: 1. Kannst Du den SPI-Flash ohne Softcore auslesen und prüfen, ob das richtige drinsteht? 2. Steht im SPI-Flash nur der Programmcode, oder auch die FPGA-Konfiguration? 3. Wo steht der Bootloader? Kannst Du im Bootloader Testcode unterbringen? 4. Hast Du Zugriff auf Reveal? Kannst Du damit prüfen ob vom Bootloader die richtigen Daten aus dem Flash gelesen werden? 5. Welche Art RAM hast Du? SDRAM oder internen Block-RAM (EBR)? 6. Falls SDRAM im Spiel ist: Funtioniert der richtig? Das wären die Punkte, die ich erstmal prüfen würde. Duke
Erstmal danke für die raschen Antworten. Duke Scarring schrieb: > 1. Kannst Du den SPI-Flash ohne Softcore auslesen und prüfen, ob das > richtige drinsteht? Habe nach dem aufspielen auf den SPI Flash eine Read and Save Operation ausgeführt und dann das SPIFlash Image mit der ausgelesenen Datei verglichen. Es ergab keine Unterschiede > 2. Steht im SPI-Flash nur der Programmcode, oder auch die > FPGA-Konfiguration? Beides. Die FPGA-Konfiguration wird mit dem Programmcode in ein SPIFlash Image gemerged und dann aufgespielt > 3. Wo steht der Bootloader? Kannst Du im Bootloader Testcode > unterbringen? Der Bootloader wird soweit ich das aus dem Tutorial herauslesen + kann von dem LatticeMico System beinhaltetem Tool namens "Software Deployement Tool" automatisch hinzugefügt. Laut dem Tutorial wird der Bootloader direkt an die EBA gesetzt, damit wenn der FPGA initialisiert ist, als erstes den Bootloader startet und dieser dann den Programmcode ins EBR und Data_IM lädt. > 4. Hast Du Zugriff auf Reveal? Kannst Du damit prüfen ob vom Bootloader > die richtigen Daten aus dem Flash gelesen werden? Der Reveal wird nicht funktionieren, da sich ja nicht einmal der FPGA richtig initialisiert. > 5. Welche Art RAM hast Du? SDRAM oder internen Block-RAM (EBR)? EBR Lattice User schrieb: > Passt das erzeugte Image zum Bootmode des FPGAs (SPI, bzw SPIm)? Der FPGA holt automatisch nach Power-On etc. seine Konfiguration aus dem SPIFlash Gruß Rene
:
Bearbeitet durch User
Rene Lusseni schrieb: > > Lattice User schrieb: >> Passt das erzeugte Image zum Bootmode des FPGAs (SPI, bzw SPIm)? > Der FPGA holt automatisch nach Power-On etc. seine Konfiguration aus dem > SPIFlash > Der FPGA kennt genau dafür 2 Modi: SPI und SPIm, wird über ConfigPins eingestellt. Wenn du ein Flash Image für SPI erstellst und der FPGA auf SPIm konfiguriert ist, funktioniert es nicht. Andersherum auch nicht.
Lattice User schrieb: > Der FPGA kennt genau dafür 2 Modi: SPI und SPIm, wird über ConfigPins > eingestellt. Wenn du ein Flash Image für SPI erstellst und der FPGA auf > SPIm konfiguriert ist, funktioniert es nicht. Andersherum auch nicht. Also die ConfigPins (CFG[2:0]) sind auf dem Versa DevBoard alle fest mit GND verdrahtet. Also alle auf 0 und somit der SPI Mode. Wie kann ich denn erkennen oder herausfinden für welchen der beiden Modi das Image erstellt wurde?
:
Bearbeitet durch User
In welchem Format liegt das Image vor? Als .bit oder als PROM File?
Lattice User schrieb: > In welchem Format liegt das Image vor? > Als .bit oder als PROM File? .mcs File
:
Bearbeitet durch User
Rene Lusseni schrieb: > > .mcs File Ok, das ist im Prinzip Intel Hex Format, mache dich damit vertraut (z.B. Wikipedia) Kontrolliere ob das FPGA Bitpattern ab Addresse 0x000000 im .mcs File steht.
Lattice User schrieb: > Kontrolliere ob das FPGA Bitpattern ab Addresse 0x000000 im .mcs File > steht. So weit ich das beurteilen kann, passt alles. die Startcodes sind da, die Daten beginnen bei Adresse 0x000..., Datenlängen stimmen mit mit Byte Count überein, stichprobenartig passen auch die Prüfsummen und der "End of File" Command zum Schluss ist auch da.
Rene Lusseni schrieb: > So weit ich das beurteilen kann, passt alles. Funktioniert es denn ein anderes Design aus dem Flash zu laden? Vielleicht eines, welches nicht gleich einen Softcore enthält? Duke
Rene Lusseni schrieb: > Lattice User schrieb: >> Kontrolliere ob das FPGA Bitpattern ab Addresse 0x000000 im .mcs File >> steht. > > So weit ich das beurteilen kann, passt alles. die Startcodes sind da, > die Daten beginnen bei Adresse 0x000..., Datenlängen stimmen mit mit > Byte Count überein, stichprobenartig passen auch die Prüfsummen und der > "End of File" Command zum Schluss ist auch da. Poste mal die ersten 20 Zeilen, als Anhang oder in code Tags.
Duke Scarring schrieb: > Funktioniert es denn ein anderes Design aus dem Flash zu laden? > Vielleicht eines, welches nicht gleich einen Softcore enthält? Andere Images funktionier. Die vermutung das am Flash was nicht passt hatte ich nämlich auch schon ;-)
Rene Lusseni schrieb: > > Andere Images funktionier. Die vermutung das am Flash was nicht passt > hatte ich nämlich auch schon ;-) Die anderen Images sind auch .mcs oder etwa .bit Files? Der Diamond Programmer muss für beides unterschiedlich eingestellt werden, denkbar wäre ist, dass du veresehntlich einfach die .mcs als Text in den Flash schreibst, und der FPGA interpretiert natürlich kein Intel Hex.
> Die anderen Images sind auch .mcs oder etwa .bit Files? > > Der Diamond Programmer muss für beides unterschiedlich eingestellt > werden, denkbar wäre ist, dass du veresehntlich einfach die .mcs als > Text in den Flash schreibst, und der FPGA interpretiert natürlich kein > Intel Hex. Ich kann ohne Probleme die anderen Images entweder als .mcs oder als .bit aufspielen. Funktioniert beides
Rene Lusseni schrieb: > Funktioniert beides Gut. Dann der nächste Schritt. Kannst Du ein LED-Blinky und Dein Prozessorsystem in ein Design packen? Damit könntest Du sicherstellen, das Dein Prozessor(+Blinky) Design richtig geladen wird. Duke
Lattice User schrieb: > Poste mal die ersten 20 Zeilen, als Anhang oder in code Tags.
1 | :10000000FF0032862E2E96C6A604CAA6B696C6F65F |
2 | :100010007626AEC62EF64E04C2F64E0EF64E862E4E |
3 | :1000200096F6760442962ECE2E4EA686B6006AA688 |
4 | :100030004ECE96F6765C0404040404040404042200 |
5 | :100040009686B6F67626046AA64ECE96F67604CC4A |
6 | :10005000748C740C749C6C0042962ECE2E4EA68628 |
7 | :10006000B604CA2E862EAECE5C0462967686360420 |
8 | :100070006AA64ECE96F676048C74CC9C0022A6CE50 |
9 | :1000800096E676047686B6A65C040E36862E66F66E |
10 | :100090004EB64CFA0E36862E66F64EB64C7476C6C2 |
11 | :1000A0002600824EC616962EA6C62EAE4EA65C041E |
12 | :1000B000A60EACC60C0C000A864E2E5C043262A260 |
13 | :1000C000CCB4CCACA282B41C620A42E2822C1C2CBE |
14 | :1000D0000022862EA65C042AAEA604B2869E040CDC |
15 | :1000E0006C048C2C5CAC9C5C2C4C044C0C8C2C005C |
16 | :1000F0004AF6EECE5C044C0C6CEC00C2F636CE5CDC |
17 | :1001000004CC2C8C4C0042962ECE5C04EC0CAC4CF7 |
18 | :100110006C0C2C004AA686264686C6D65C040404CF |
19 | :100120000404F2666600CAA6C6AE4E962E9E5C0415 |
20 | :1001300004040404F266660042962ECE2E4EA68675 |
Habe das Problem gefunden!!!!!!!! Es war ein Clock Problem. Im Tutorial wird der SPI Flash mit dem FPGA Pin B22 (MCLK) verbunden. Dies ist auch so auf der Hardware. Soweit also in Ordnung. Jedoch wird per SYSCONFIG vom FPGA die Frequenz beim StartUp auf 21MHz und im laufenden Betrieb auf 26MHz gesetzt. Die maximale Frequenz die jedoch der der SPIFlash auf dem VersaBoard im DataRead verträgt ist 20MHz. Kann ja also nicht funktionieren. Auf jeden Fall noch ein großes Dankeschön an euch beide für eure Hilfe und Unterstützung. Gruß Rene
Rene Lusseni schrieb: > Habe das Problem gefunden! Super. Und Danke auch für die Rückmeldung. Da braucht der Nächste vielleicht etwas weniger Zeit für die Fehlersuche. Duke
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.