Hallo Zusammen, ich habe eine vorhandene Hardware auf Ihr ist ein µC (Infinion) und ein FPGA (Lattice) installiert. Beide liegen in einer JTAG Chain. Ich würde nun gerne, da die Hardware verbaut ist, das FPGA über den µC neu Programmieren, ist dies möglich? Wenn ja wie? Über tips, tricks oder fertige Projekte wäre ich dankbar. Mfg Gruß, FloKath
Normalerweise macht man das doch so, dass der Mikrocontroller an den JTAG-Pins wackelt und damit dann den FPGA programmiert. Du brauchst also ein Stück Software, das zum Beispiel eine (X)SVF-Datei "abspielen" kann. Such also mal nach SVF-Player oder ähnlichem. In deinem FPGA-Tool musst du dann statt direkt an die JTAG-Chain zu gehen eine SVF-Datei erstellen. Gruß Marius
FloKath schrieb: > Hallo Zusammen, > ich habe eine vorhandene Hardware auf Ihr ist ein µC (Infinion) und ein > FPGA (Lattice) installiert. Beide liegen in einer JTAG Chain. > Ich würde nun gerne, da die Hardware verbaut ist, das FPGA über den µC > neu Programmieren, ist dies möglich? Wenn ja wie? Über tips, tricks oder > fertige Projekte wäre ich dankbar. > Mfg > Gruß, > FloKath Über JTAG hast du da wohl keine Chance, das dürfte schon am µC scheitern. Ansonsten hängt es da die HW schon fertig ist und wie ich annehme nicht mehr geändert werden soll davon ab welcher Lattice FPGA und wie deine Schnittstelle µC - FPGA realisiert ist.
FloKath schrieb: > µC (Infinion) Welchen? (BTW: hier das fehlende e für Infineon: 'e'. Du bekommst es aber nur, wenn du mir das übrige 'i' dafür gibst) > und ein FPGA (Lattice) installiert. Welches? > das FPGA über den µC neu Programmieren, ist dies möglich? Das vermutlich schon... > Wenn ja wie? ...aber nicht über die verbundenen JTAG-Pins. Es sei denn, du kannst vom uC aus an den JTAG-Pins herumwackeln.
Angehängte Dateien:
-
Schematic_JTAG_Chain.png
5,4 KB
Hallo Zusammen, es sieht also so aus... Der Infineon ist ein TriCore und die Idee ist, dass man entweder den FPGA durch die 4 Physikalischen Pins über JTAG oder durch einen Multiplexer umgeschalten eine JTAG verbindung zwischen µC und dem FPGA aufbauen kann, so dass der Prozessor die Programmierung übernimmt. Wenn das so wird wie wir das wollen. Erschwerend kommt jedoch hinzu, dass die JTAG Chain, noch 2 CPLDs beinhaltet.. siehe Bild. Ich hoffe ich finde hier ein paar nützliche Tipps wie ich dieses Projekt lösen kann. Da im Verbauten zustand an die harten Pins nicht mehr zu kommen ist.
Auch wenn Du das Hardwarekonzept noch nicht fertig hast, hier ein Link zur passenden Software von Lattice (ispVM Embedded): http://www.latticesemi.com/products/designsoftware/ispvmsystem/ispvmembedded.cfm
Hi, Hardware ist schon fertig. Das bei Lattice hab ich auch schon gesehen, damit kann man das JTAG File umkonfertieren, mir fehlt aber noch der Brückenschlag damit ich weiß, was ich für Methoden im µC brauche, um dann schließlich auch das erzeugte File ins FPGA zu bringen. Aber schonmal danke
FloKath schrieb: > Hardware ist schon fertig. Also ist der MUX schon verbaut? > Das bei Lattice hab ich auch schon gesehen, > damit kann man das JTAG File umkonfertieren, mir fehlt aber noch der > Brückenschlag damit ich weiß, was ich für Methoden im µC brauche, um > dann schließlich auch das erzeugte File ins FPGA zu bringen. Dann hast du das zwar gesehen, aber nicht genau hingeschaut. Bei ispVM Embedded sind C-Sourcen dabei! Man muss nur die Funktionen um an den JTAG Pins zu wackeln hinzufügen. Geht das überhaupt mit dem Tricore? Um zielführender helfen zu können, müsste man aber wissen um welchen FPGA es denn eigentlich geht.
Ja der Multiplexer ist schon verbaut... Es geht um ein XP2-5E bzw XP2-17E und der TriCore ist ein 1796 ich hoffe es geht mit diesem TriCore... ?! Wie sehen dann diese Funktionen aus, dass ist ja mehr als Wackeln, da müssen ja Daten laufen, oder? Ich bin jetzt nicht no der Embedded Programmierer, hoffe aber dass ich es trotzdem schaffe. Danke Gruß
Hi Nur Kurz... wie kommen deine Daten auf den TriCore, bzw Streamen oder Buffern... Wir reden hier von einigen MB die irgendwie "am stück" da runter müssen... Gruß
Tja es wird wohl über ein CAN Interface geschickt, wobei die Zeit nicht so kritisch ist, wenn es mal ne halbe Stunde dauert...ist das o.k. es geht hautsächlich um die Machbarkeit ohne die Hardware auszubauen. Die Nachricht enthält dann immer die Nutzdaten, die dann halt wieder zusammengesetzt werden müssen. Gruß
Mach dich als erstes damit vertraut wie JTAG funktioniert. Danach versuche die Sourcen unter C:\lscc\diamond\1.4\embedded_source\vmembedded in deiner Diamondinstallation zu verstehen. Das sind die bei denen du das Gewackle der JTAG Pins ergänzen musst. Allerdings, an was für Pins des Tricores habt ihr den JTAG angeschlossen? Wenn es GPIOs sind alles in Butter, wenn es der JTAG Debugport des Tricore ist habt ihr euch vermutlich ins Knie geschossen.
Der JTAG-Port geht intern auf einen TAP-Controller (Statemachine), an dem der normale µC-Kern nicht wackeln kann. Du kannst normalerweise nur mit externen Tools auf den JTAG-Port zugreifen.
Lattice User schrieb: > Wenn es GPIOs sind alles in Butter Alles in Butter es sind GPIOs ;-) Also jetzt nur noch den Code verstehen und wie JTAG geht, sehe ich das soweit richtig? Ist das für jemanden ohne großes Wissen im Embedded Bereich zu lösen? Oder kämpfe ich hier auf verlassenem Posten? BoundaryScan schrieb: > Der JTAG-Port geht intern auf einen TAP-Controller (Statemachine), an > dem der normale µC-Kern nicht wackeln kann. Was meinst du damit? Gruß
Der JTAG-Port besteht normalerweise aus den 4 Pins TDI, TDO, TMS und TCK, wobei TDI der Dateneingang ist und TDO der Ausgang. TDO vom ersten Baustein in der Kette ist mit TDI vom nächsten Baustein verbunden usw. TMS und TCK werden parallel an alle Bausteine der Kette geführt. Die 4 Signale werden mit einer externen Hardware verbunden, zum Debuggen, Programmieren oder Testen, was der eigentliche Sinn dieses Ports ist. Das heißt, völlig unbeeinflußt vom CPU-Kern kann die externe Hardware, gesteuert von entsprechender Software, die Anschlüsse des Controllers testen. Wenn diese Signale (also TDI, TDO usw) auf normalen GPIOs liegen, sind sie für BoundaryScan-Anwendungen nutzlos und die Kette kann auch nicht funktionieren.
achso... die MUX ist ziemlich für die Katz... einfach die Pins am µC tristaten langt. Gruß
BoundaryScan schrieb: > Wenn diese Signale (also TDI, TDO usw) auf normalen GPIOs liegen, sind > sie für BoundaryScan-Anwendungen nutzlos und die Kette kann auch nicht Daher hat er ja den Mux drin. Somit kann er offenbar die JTAG Kette entweder auf den externen Programmierstecker oder aber auf die GPIOs legen. Und die volle Funktionalität bleibt erhalten. Auf jeden Fall sollte es so gehen, Bei Xilinx würde das auch klappen, die XAPP058 ist da das passende Software-Stück.
>Daher hat er ja den Mux drin. Somit kann er offenbar die JTAG Kette >entweder auf den externen Programmierstecker oder aber auf die GPIOs >legen Es langt die IO am uC zu tristaten, dann die vier JTAG Signal parallel auf JEDEC Stecker und GPIOs führen. Hab ich schon einige mal gemacht, auch auch FPGA Pins damit sich der FPGA selber neu programieren kann (nur sollte man da nie vergessen, den Pull-Up abzuschalten...) Die GPIOs würd ich eher nicht für andere Funktionen weiterverwenden.. Gruß
Moin Zusammen! Freut mich zu sehen, dass so heftig diskutiert wird, aber um auf mein ursprüngliches Problem zurück zu kommen. Hat schon jemand dieses Projekt umgesetzt? Vielleicht mit einem der Beiden oder beiden Bausteinen? Über Tips, Tricks, QuellCode Beispiele zum nachvollziehen wäre ich dankbar.
Ja das ist klar, aber er schrieb ja dass das Board schojn fertig ist. Funktionieren sollte es auf jeden Fall auch so.
Hi, also ich finde jetzt erst mal Butter bei die Fische. Für ordentliches helfen musst du selber auch ein bisschen was tun. Lies mal die Datenblätter vom Tricore und poste evtl. mal den Schaltplan bzw. nenne die Pins an die das beim Tricore angeschlossen ist. Irgendwer hat was von nem Mux erzählt....Gibt es den in HW und wenn ja wie ist das realisiert?? Fakten bitte, dann helfe ich auch ein bisschen. Rumraten usw. bringt hier nicht viel weiter. Ich selbst habe mal mit einer ispVM Embedded ähnlichen Software von Lattice rumprobiert, wollte es auf einem atMEGA (8-bitter) laufen lassen, was nicht funktioniert hat. Diese Software hiess leicht anders und ist für den Slave SPI-Port vom Lattice XP2 gedacht. Die Lösung war dann: Ich habe auf dem atMEGA selber eine Software geschrieben die den SSPI-Port vom XP2 bedient und den FPGA auf diesem Wege beschickt. Funktioniert auch relativ gut.
Angehängte Dateien:
-
MUX_JTAG.png
75 KB
So dann mal Butter bei die Fische, also der Mux ist in ein Baustein auf der Platine, der durch anlegen einer Bootstrap Spannung entweder auf auf physikalische Pins schaltet, dann kann das FPGA durch einen Programmer geflasht werden, klappt aber nur, wenn die Platine nicht verbaut ist. Wenn die Platine Verbaut ist, wird durch anlegen der Bootstrap spannung der Mux umgeschaltet und die TriCore Pins bedienen dann die JTAG Schnittstelle der FPGAs (so soll es werden). Die Hardware ist schon komplett fertig, Bisher haben wir die mühe, dass die Platine jedesmal beim neu flashen ausgebaut werden muss, dann geflasht, isolationstest und wieder verbaut. Soll sich aber ja durch das Projekt ändern. Zu den TriCore Pins die Signale sind folgenden Pins zugewiesen... TDI -> P7.0 TDO -> P7.1 TCK -> P7.2 TMS -> P7.3 So ich hoffe, ich bin Bernds ansprüchen gerecht geworden. Ich komme selber mehr aus der Hardware / FPGA Schiene, bin also Embedded nicht so bewandert, würde es aber trotzdem gerne schaffen. Grüße und schon mal Danke und frohe Ostern!
FloKath schrieb: > Ich komme selber mehr aus der Hardware / FPGA Schiene, bin also Embedded > nicht so bewandert, würde es aber trotzdem gerne schaffen. Ich habe das Gefühl du lässt dich durch da Buzzwort Embedded zu sehr ins Bockshorn jagen. Jede noch so kleine ATiny Anwendung fällt unter diesen Begriff. In dem oben von mir genannten Verzeichnis findest du die Variante der Software für den JTAG Port und nicht die Variante für den von Bernd erwähnten SSPI Port. Anzupassen ist hardware.c Da ihr in der gleichen Chain auch 2 weitere PLDs habt, muss das im svf File berücksichtigt werden. Wenn der Platz im tricore nicht mehr reicht, könnt ihr auch einen ganz simplen Player implememtieren, einfach über CAN ein Datenpacket empfangen und Byte für Byte auf den GPIOs für den JTAG ausgeben. Der Aufwand liegt dann auf der anderen Seite um einen passenden Stream bzw File zu erzeugen. Dazu muss man sich aber etws genauer mit JTAG befassen. Hat ausserdem den Nachteil dass Fehlererkennung nicht mehr einfach ist.
Hi, nen Schaltplan hab ich jetzt zwar noch nicht gesehen, habe aber jetzt verstanden, dass die Pins vom Tricore ordentlich angesteuert werden können. Die von LatticeUser genannte Lattice-Software solltest du dir jetzt mal vornehmen und in die (bereits vorhandene?) Tricore-Software einbinden. Ich bin mir (fast) sicher, dass Lattice sehr gut beschreibt wo überall Änderungen vorgenommen werden müssen, LatticeUser hat ja auch schon gesagt wo man was machen muss. Compiliert dat Dingens ordentlich? Habt ihr evtl. die Möglichkeit in-circuit zu debuggen? Single-Step usw. kann sehr nützlich sein. Außerdem brauchst du nun ein SVF oder embedded SVF-File. Da ihr eh Lattice benutzt bietet es sich an ein solches File mit dem ispVM-Programm vom Lattice zu erstellen. Habe gehört es gibt nun auch noch ein neueres Programmierprogramm von Lattice, kenne dieses persönlich aber noch nicht. In ispVM benötigst du BSDL-Files von allen Devices die zwar in der JTAG-Chain sind, die du aber NICHT ansprechen möchtest. Mit diesen BSDL-Files und dem zu programmierenden FPGA Bitfile (JEDEC-format) solltest du (habs selber noch nicht bei ispVM ausprobiert) ispVM mittteilen können wie die JTAG-Chain aussieht. Dann SVF-File erstellen. Und dieses SVF muss jetzt auch noch in dein Device kommen. Du wolltest das ja über CAN machen. In die Tricode-Software muss also noch ein entsprechender Puffer rein der das SVF-File aufnimmt. Wenn es nicht ganz rein passt, dann ein Ringpuffer, der immer nur einen Teil aufnimmt und dann Stück für Stück Teile nachlädt. Vielleicht kannst du das in einer SD-Card ablegen? Ist eure HW schon komplett fertig?
> Ich komme selber mehr aus der Hardware / FPGA Schiene, bin also Embedded > nicht so bewandert, würde es aber trotzdem gerne schaffen. Selbiges hier, allerdings "geschafft" :-). Ich habe auf meinem Board hier einen ATmega128, samt SRAM + SDcard, und eine MachXO2 dran. Auf dem laeuft seit letzter Woche das ispVMembedded von Lattice, aus Diamond 2.0. Sourcecode findest du dort, nimm am besten das ispvme_eprom. Anzupassen sind insbesondere hardware.c (Zugriffe auf die Portpins), sowie der Teil, der Speicher zuweist. Empfehlung: nimm fixe Buffer, 1.5kB reichen AFAIk fuer die meisten Bausteine. Dann musst du nur noch dafuer sorgen, dass deine VME Datei korrekt eingelesen wird (Funktion GetByte()), und der ganze Muell mit den globalen Variablen richtig tut, sowie dein Compiler mit dem DOS-Krempel (unsigned char, unsigned short etc) richtig hinkommt. Rechne mal ne Woche fuer Code Cleanup ein. Vorsicht: irgend ein unbekanntes Genie liest in dem Code ein uint8_t ein, castet das auf int8_t und macht spaeter einen Test auf <0. Ziemlich kranke Methode, um das MSB auf 1 zu testen.... das war AFAIK in der Routine, in der die Opcodes eingelesen werden (die haben immer MSB = 0). Getestet ist es bei mir bisher mit MachXO2 und XP2, ispM4A3 wuerde ich gerne, darf ich aber nicht, weil Lattice da erst mal eine Lizenz zur Nutzung von "mature devices" verkaufen moechte. Xilinx - keine Ahnung, eventuell teste ich das noch. Noch was: die UES wird wohl bei VME-Dateien immer geprueft, und liefert dir Verification Errors... geht aber trotzdem. Du musst fuer deine JTAG-Kette latuernich entsprechende XCF-Dateien anlegen, und die CPLDs in bypass schalten lassen! Wenn du Probleme hast, mail mir einfach (mboehmer <AT> e3b.de). Michael
Addendum: die Verify Errors kommen vom Busy Polling des Flashs. Werde wohl eine Fallunterscheidung in ispVMRead() einbauen - ein Bit lesen => polling, keine Fehlermeldung, beim Ruecklesen > 1bit normale Fehlerbehandlung. Nachdem das ganze im Bereich des "Verify UES" passiert, und das als neues Features im Release drinnen ist, ist das wohl mit heisser Nadel gestrickt... Ansonsten scheint die ispVME Software gut zu funktionieren. Lattice CPLDs muss man uebrigens ueber den Umweg JEDEC -> SVF -> VME einbinden, das neue Diamond 2.0 kann mit CPLDs leider nichts mehr anfangen.
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.