Moin, Ich wollte mir die Möglichkeit offenhalten einen MACHXO2 im System updaten zu können. Mangels genügend GPIO Ports, möchte ich das Schema im Anhang (Statt TDC sollte da TCK stehen) verwenden. Ich denke wenn man während des Normalbetriebes TMS auf '1' hält kann eigntlich nichts anbrennen weil der JTAG Controller im XO2 im Resetzustand verweilt. Das Wackeln der Signale an TCK und TDI sollte doch dann nicht stören. Oder habe ich da was übersehen?
Angehängte Dateien:
-
xo2isu.png
21 KB
Hallo Thomas, als erstes: Du hast völlig Recht. Solange TMS auf '1' gehalten wird, bleibt oder kommt der TAP-Controller in den "TEST LOGIC RESET"-Zustand. In diesem Zustand können an TCK und TDI beliebige Signale anliegen ohne den TAP-Controller zu aktivieren. Auch TDO ist im Tristate-Zustand. Ich bin jetzt nicht der große MachXO2-Spezialist, aber ich meine mich zu erinnern, dass es bei diesem Type eine externe Steuerleitung zum (de-)aktivieren des TAP-Controllers gibt. Nach Deaktivierung können die 4 JTAG-Signale als ganz normale IOs verwendet werden. Das würde dir nochmals FGPA-IOs sparen. Eine weitere Möglichkeit wäre, I2C fürs Firmwareupdate zu verwenden. Bräuchte nur 2 Leitungen. Hth, Pat a Mat
Pat A Mat schrieb: > Ich bin jetzt nicht der große MachXO2-Spezialist, aber ich meine mich zu > erinnern, dass es bei diesem Type eine externe Steuerleitung zum > (de-)aktivieren des TAP-Controllers gibt. Nach Deaktivierung können die > 4 JTAG-Signale als ganz normale IOs verwendet werden. Das würde dir > nochmals FGPA-IOs sparen. Ja den Pin gibt es, aber nur wenn man JTAG in der XO2 Konfiguration disabled um die JTAG Pins selbst als IO's zu verwenden. Dann kann man mit diesem Pin die Funktion der 4 JTAG Pins zwischen IO und JTAG Mode umschalten. Allerdings sind hier offensichtlich nicht die XO2 Pins knapp, sondern die am µC. > > Eine weitere Möglichkeit wäre, I2C fürs Firmwareupdate zu verwenden. > Bräuchte nur 2 Leitungen. > Insgesamt sind trotzdem 5 Pins am µC nötig, hat aber den Vorteil dass I/O und Konfiguration unabhängig voneinander sind. Wenn man noch andere I2C Devices auf dem Board hat, spart man natürlich.
Pat A Mat schrieb: > ... Auch TDO ist im Tristate-Zustand. Da war ich mir nicht sicher, da ich noch kein Dokument gefunden habe wo das geschrieben steht. Der IEEE Standard ist mir zu teuer nur um das rauszubekommen. Aber wenn dem so ist, da kann ich ja den TDO und Data_out auch zusammenlegen und bräuchte somit nur 4 GPIO Ports am µC. Lattice User schrieb: > Allerdings sind hier offensichtlich nicht die XO2 Pins knapp, sondern > die am µC. So ist es. Gegenüber der Lösung mit I2C hätte meine vorgeschlagene Variante den Vorteil das sich damit auch ein jungfräulicher XO2 programmieren ließe.
:
Bearbeitet durch User
Thomas W. schrieb:> > > Gegenüber der Lösung mit I2C hätte meine vorgeschlagene Variante den > Vorteil das sich damit auch ein jungfräulicher XO2 programmieren ließe. Auch ein jungfräulicher XO2 kann über I2C programmiert werden. (und auch über SPI)
Lattice User schrieb: > (und auch über SPI) Genau das möchte ich machen: Ein MachXO2 über SPI von einem Atmel SAMxx aus programmieren. Ich kenne "MachXO2 Programming and Configuration Usage Guide" http://www.latticesemi.com/~/media/Documents/ApplicationNotes/MO/MachXO2ProgrammingandConfigurationUsageGuide.pdf?document_id=39085 aber ich will nicht das JEDEC-File mit in den SAMxx einbinden. Meiner Meinung nach müsste es reichen wenn man nur das kleine Bitfile über SPI lädt. Die Zusatzinformationen im JEDEC-File, z.B. Feature Row, sollten sich ja nur ganz ganz selten ändern. Hier http://www.latticesemi.com/~/media/Documents/UserManuals/MQ/ProgrammingToolsUserGuide31.pdf?document_id=50445 im Kapitel "Slave SPI embedded" ist näheres beschrieben, aber der zugehörige Code (den man in \lscc\diamond\3.4\embedded_source\spiembedded findet, liest JEDEC und erscheint mir etwas aufgeblasen. Hier: Beitrag "Lattice MachXo2 embedded programming" hat wohl schon mal einer ähnliches gefragt, aber es wurde nicht zuende gebracht. Da ich hier sicher nicht der erste bin, wollte ich mal frage ob es irgendwo schon ein kleines Stück Code gibt, welches einfach nur das (kleine) MachXO2 Bitfile nimmt und über SPI in den MachXO2 reinlädt? Ich habe die zitierten Quellen aufgrund ihres Umfangs nicht alle vollständig gelesen, allerdings gängige Suchmaschinen ausgiebig bemüht und nichts gefunden. Es kann also sein ich hab hier was übersehen, überlesen oder falsche Annahmen getroffen und bin daher auch dankbar wenn mich diesbezüglich weiterbringt. Danke, Günter
Günter (dl4mea) schrieb: > aber ich will nicht das JEDEC-File mit in den SAMxx einbinden. Meiner > Meinung nach müsste es reichen wenn man nur das kleine Bitfile über SPI > lädt. Die Zusatzinformationen im JEDEC-File, z.B. Feature Row, sollten > sich ja nur ganz ganz selten ändern. > Das vom Diamomd erzeugte Bitfile ist für einen exterenen SPI Flash gedacht. Das interne Flash muss Pageweise (je 16 Byte) programmiert werden, vielleicht erscheint es dir deswegen etwas umständlich. Jede Zeile im Jedecfile ist genau 128 Bit, d.h. eine Page. Es hindert dich niemand daran, das in ein etwas kompakteres Format zu konvertieren.
Thomas W. schrieb: > Pat A Mat schrieb: > >> ... Auch TDO ist im Tristate-Zustand. > > Da war ich mir nicht sicher, da ich noch kein Dokument gefunden habe wo > das geschrieben steht. Der IEEE Standard ist mir zu teuer nur um das > rauszubekommen. Aber wenn dem so ist, da kann ich ja den TDO und > Data_out auch zusammenlegen und bräuchte somit nur 4 GPIO Ports am µC. Das habe ich dann auch mal ausprobiert und zu meiner Überraschung festgestellt, dass an Data_out auch weiterhin aktiv Signale getrieben werden obwohl sich der XO2 im JTAG-Mode befindet (TMS ist Low). Somt ist schon die Abfrage der Device ID fehlerhaft. Ich dachte bisher, dass sich während des Programmiervorgangs alle User I/O's im Tristate Zustand befinden sollten. Oder kann man diesen Zustand irgendwie erzwingen?
Thomas W. schrieb: > Thomas W. schrieb: >> Pat A Mat schrieb: >> >>> ... Auch TDO ist im Tristate-Zustand. >> >> Da war ich mir nicht sicher, da ich noch kein Dokument gefunden habe wo >> das geschrieben steht. Der IEEE Standard ist mir zu teuer nur um das >> rauszubekommen. Aber wenn dem so ist, da kann ich ja den TDO und >> Data_out auch zusammenlegen und bräuchte somit nur 4 GPIO Ports am µC. > > Das habe ich dann auch mal ausprobiert und zu meiner Überraschung > festgestellt, dass an Data_out auch weiterhin aktiv Signale getrieben > werden obwohl sich der XO2 im JTAG-Mode befindet (TMS ist Low). Somt ist > schon die Abfrage der Device ID fehlerhaft. Ich dachte bisher, dass sich > während des Programmiervorgangs alle User I/O's im Tristate Zustand > befinden sollten. Oder kann man diesen Zustand irgendwie erzwingen? Wenn du die JTAG Pins als User I/O verwendest, wird JTAG in der Feature Row abgschaltet, das betrifft alle 4 JTAG Pins einschliesslich TMS und TCK Umschalten zwischen Usermode on JTAG-Mode tut man dann mit dem JTAGEN Pin.
Lattice User schrieb: > Wenn du die JTAG Pins als User I/O verwendest, wird JTAG in der Feature > Row > abgschaltet, das betrifft alle 4 JTAG Pins einschliesslich TMS und TCK > Umschalten zwischen Usermode on JTAG-Mode tut man dann mit dem JTAGEN > Pin. Ja das ist mir schon klar, dass man das so machen kann. Ist ja auch ein Super Feature bei diesen Bausteinen. Aber das bedingt, dass ich 5 Leitungen dafür benötige. Ich wollte aber gerne mit nur 4 auskommen und habe deshalb den JTAG Pins jeweils ein User I/O parallel geschaltet. Inzwischen habe ich auch einen Workaround für mein Problem gefunden. Der mit dem TDO verschaltete I/O muss halt initial Tristate sein. So kann die User Logic während des JTAG-Modes nicht mehr dazwischenfunken. Erst im Usermode, wenn über den dem TDI parallel geschalteten I/O "User Daten" kommen und die interne FSM synchronisiert ist, wird der Pin dann freigeschaltet. Somit läuft nun alles wie ich es wollte. Danke an allen, die mit nützlichen Tipps geholfen haben.
Thomas W. schrieb: > Lattice User schrieb: >> Wenn du die JTAG Pins als User I/O verwendest, wird JTAG in der Feature >> Row >> abgschaltet, das betrifft alle 4 JTAG Pins einschliesslich TMS und TCK >> Umschalten zwischen Usermode on JTAG-Mode tut man dann mit dem JTAGEN >> Pin. > > Ja das ist mir schon klar, dass man das so machen kann. Ist ja auch ein > Super Feature bei diesen Bausteinen. Aber das bedingt, dass ich 5 > Leitungen dafür benötige. Ich wollte aber gerne mit nur 4 auskommen und > habe deshalb den JTAG Pins jeweils ein User I/O parallel geschaltet. > Ein nicht ganz unwesentliches Detail. Der MachXO2 (und auch andere Lattice FPGA) schaltet die User Pins erst bei Empfang des ISC_ENABLE Commands auf Tri-State.
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.