Hallo zusammen, ich arbeite gerade an einer Schaltung und würde gerne einen Serial Flash (M25P16), welcher per SPI an einen FPGA (Altera EP4CE6C22C8N) angeschlossen ist, zusätzlich mittels einem XMega 192A3 auslesen und beschreiben können. MSEL0/1/2 ist dabei auf 3,3V GND 3,3V geschaltet (AS standard POR). Jetzt habe ich aktuell MISO/MOSI/SCK/NCS per Löt-Jumper jeweils einzeln für den XMega und den FPGA trennbar gestaltet, so dass ich "umstellen" kann. Eine komfortable Lösung ist das jedoch nicht.0 Da ich den Flash aber gerne im laufenden Betrieb, vom AVR aus, bedienen würde stellt sich mir die Frage ob dies überhaupt möglich ist. Ich habe diverse Steuerleitungen des FPGA (NCS, NSTATUS, CONF_DONE, NCONFIG) bereits mit meinem AVR verbunden um hier ggfls. eingreifen zu können. Dem Datenblatt der FPGA-Familie, dem Altera Cyclone Handbuch und dem CycloneIV Pin Connection Guideline kann ich so erst mal nicht (ist für mich nicht offensichtlich) entnehmen ob ich den FPGA in einen Zustand bringen kann, in dem ich von meinem AVR aus auf den Flash zugreifen können würde. Vielleicht hat jemand von Euch ja Erfahrung oder eine Idee dazu... Vielen Dank! Kai
Kai Lauterbach schrieb: > einen FPGA Der Array oder das Array? > ob ich den FPGA in einen Zustand bringen kann, in dem ich von meinem > AVR aus auf den Flash zugreifen können würde. Hast du Zugriff auf das Design im FPGA? Dann könntest du einfach per Steuersignal die Leitungen hochohmig schalten und das FPGA könnte tortzdem "weiterlaufen"... Wenn nicht:
1 | To begin configuration, nCONFIG and nSTATUS must be at a logic high level. |
2 | You can delay configuration by holding the nCONFIG low. |
Aus http://www.altera.com/literature/hb/cfg/cfg_cf51001.pdf Aber beachten: während der Konfiguration sind die IO-Pins hochohmig. Auch die, die du nicht brauchst...
:
Bearbeitet durch Moderator
Vielen Dank für die schnelle Antwort! Da ich Zugriff auf das Design im FPGA habe, habe ich nun Deinen Vorschlag getestet. Die Leitungen MISO/MOSI/SCK und NCS habe ich hochohmig geschaltet. Leider meckert der Build-Prozess dabei, dass eine doppelte Verwendung der Pins nicht möglich ist. In den "Device and pin options", welche in den projektspezifischen Einstellungen unter "Device" zu finden sind, kann man jedoch die Funktionalität für diverse Pins anpassen. Unter anderem auch die DATA0-/DATA1-/DCLK- und NCSO-Leitungen. Hier sind in meinem Design bereits alle Pins, bis auf DCLK, auf "input tri-state" gestellt. Bei der DCLK-Leitung ist jedoch "programming" konfiguriert und ein Hinweis dazu angegeben, dass man diese Einstellung nur auf der gerade genannten Einstellung oder "compiler specific" stellen sollte. Sofern der FPGA-Chip im "AS"-Modus arbeitet (siehe erste Nachricht). Da ich nun aber mit meine SCK-Leitung - des AVR - auch am Flash benötige ist hier die Frage dies damit ein K.O.-Kriterium ist für mein Vorhaben. Schließlich möchte ich den DCLK-Pin des FPGA weder elektrisch "zerstören" noch mir die Möglichkeit nehmen per JTAG weiterhin auf den FPGA-Chip zugreifen zu können. Wenn ich die Dokumentation zum Thema der dual-purpose-pins korrekt verstanden habe muss ich mich wohl für eine Variante entscheiden, oder siehst du das anders? Vielen Dank! Kai
Kai Lauterbach schrieb: > Leider meckert der Build-Prozess dabei, dass eine doppelte Verwendung > der Pins nicht möglich ist. Ja, wie denn doppelt? Kai Lauterbach schrieb: > ich arbeite gerade an einer Schaltung und würde gerne einen Serial Flash > (M25P16), welcher per SPI an einen FPGA (Altera EP4CE6C22C8N) > angeschlossen ist .. auslesen und beschreiben ... Ist das dein Config-Flash?
Lothar Miller schrieb: > Ja, wie denn doppelt? Wenn ich mich nicht irre war es der folgende Fehler, und das für jeden der verwendeten Konfigurations-Pins einzeln: Error (176310): Can't place multiple pins assigned to pin location <pin_number> (<pin_name>) Verwendet hatte ich diese zuvor in meinem Design nicht. Wenn notwendig werde ich später noch eine weitere Antwort mit der exakten Fehlermeldung und einem Beispiel meines Designs posten. Lothar Miller schrieb: > Ist das dein Config-Flash? Korrekt,das ist mein Config-Flash. Sorry, diese Info hatte ich in meiner ersten Frage unterschlagen... ;)
Da du in deinem Design das EPCS 'manuell verdrahtest' also ueber toplevel und Pin Assignment, dann solltest du die entsprechenden Pins in den Device Options -> 'Dual-Purpose Pins' auf 'Use as regular I/O' setzen. Falls dein AVR auf das FLASH zugreifen muss wenn das FPGA noch nicht konfiguriert ist (was wohl der Sinn der Sache ist) solltest du nCE des FPGA auf high und nCONFIG auf low halten. Nur dann ist der AS bus tri-stated. Cheers, Roger
Angehängte Dateien:
-
messungen.PNG
12 KB
Zunächst danke nochmal für die Hilfe und die Antworten! Roger Steiner schrieb: > Falls dein AVR auf das FLASH zugreifen muss wenn das FPGA noch nicht > konfiguriert ist (was wohl der Sinn der Sache ist) solltest du nCE des > FPGA auf high und nCONFIG auf low halten. Nur dann ist der AS bus > tri-stated. Ich habe genau dies nun ausprobiert. Also nCE auf High gesetzt und nConfig auf LOW gehalten. Darauf hin konfiguriere ich die SPi-Schnittstelle per SPI driver von ATmel - App. Note: AVR1309; Rev. 764. Leider ist kein Zugriff per SPI möglich. Im Anhang habe ich meine Spannungs-Messungen abgebildet. Es wurde während den Messungen keine Daten (versucht) übertragen. Hat noch jemand ein Idee dazu? Ich bin mir an dieser Stelle nicht sicher ob es sich um ein elektrisches oder software-Problem handelt. Ich werde versuchen in den kommenden Tagen mit einem Oszi die Pins zu messen.
Ich wuerde in einem leeren design ein Signal-Tap auf die EPCS pins plazieren und aufzeichnen was der uC denn so auf dem SPI bus treibt. Cheers, Roger
Ich habe mir das ganze mit einem Oszi angesehen und der AVR ist an dieser Stelle offenbar das Problem. Ich werde berichten sobald dieser unter Kontrolle ist... Danke für die vielen Anregungen und Tipps!
Mit einer "manuellen" implementierung von SPI funktioniert der Zugriff vom AVR auf den SPI Flash des FPGA einwandfrei! Das SPI-"Modul" in meinem XMega scheint "defekt" zu sein, denn mit diesem ist keinerlei Aktivität auf MOSI oder SCK zu messen. Ich habe drei verschiedene Implementierungen ausprobiert siehe http://www.avrfreaks.net/forum/xmega-spi-code-problem-0. Danke für die Hilfe!!!
Kai Lauterbach schrieb: > Das SPI-"Modul" in meinem XMega scheint "defekt" zu sein, denn mit > diesem ist keinerlei Aktivität auf MOSI oder SCK zu messen. Wenn dem so wäre, hätte Atmel ein echtes Problem. Möglicherweise wurde bei der Konfiguration der SPI-Peripherie etwas übersehen. > Mit einer "manuellen" implementierung von SPI funktioniert der Zugriff > vom AVR auf den SPI Flash des FPGA einwandfrei! Wenn Dir die Geschwindigkeit ausreicht, ist das eine zufriedenstellende Lösung. Duke
Naja zufriedenstellend ist etwas anderes, aber es ist so wenigsten der Beweis, dass die elektrische Verbindung korrekt ist. Damit ist das Ziel auf dieser Seite erreicht! Vielen Dank nochmals für die Unterstützung! Wenn ich nicht von Beginn an den spi driver von Atmel zur Kommunikation verwendet hätte, dann wäre ich mittlerweile der Meinung das es an meiner Implementierung liegt. Ich habe jedoch noch 2 weitere Implementierung testen können, welche auch die SPI Peripherie verwendet, und keine davon lieferte ein anderes Ergebnis.
Kai Lauterbach schrieb: > Ich habe jedoch noch 2 weitere Implementierung testen können, welche > auch die SPI Peripherie verwendet, und keine davon lieferte ein anderes > Ergebnis. Ich habe mit den Xmegas noch nicht zu tun gehabt. Aber die weiteren Implementierungen (aus dem verlinken Forumsbeitrag?) haben ja bei anderen höchstwahrscheinlich auch funktioniert. Vielleicht muß das SPI-Modul aus dem Powerdown geholt werden? Oder der Multiplexer, der die Pinzuordnung bestimmt ist noch nicht richtig konfiguriert? Evtl. spielt auch die DMA/Event-Konfiguration mit rein? 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.