Hallo, Ich habe hier Probleme damit einen XC9572XL zu programmieren. Am "Anfang" des Designs ging das noch problemlos. Aber sobald das Design jetzt größer wurde*, schlagen längere Befehle, wie Erase, Program, Verify oder Readback im iMPACT fehl. "Get Device Id" funktioniert hingegen problemlos. Als Programmierkabel kommt ein USB-JTAG Programming Cable von Digilent zum Einsatz. Die Kabellänge beträgt ca. 5cm. Das Problem äußert sich wie folgt: Klicke ich auf "Erase", dann versucht iMPACT den CPLD zu löschen, hängt sich dabei aber auf. Auch nach einem Klick auf "Abort" will es unbedingt die Operation abschließen. Nur ein Neustart und Neu-Einstecken des USB Kabels hilft. Mein Design hat eine 33kHz Taktquelle, die mit einem 74HC14 als Relaxation Oscillator ausgeführt ist. Die Versorgungsspannung direkt am CPLD mit Ground Spring sieht exzellent aus. Mit AC-Kopplung sehe ich ein Ringing im 33kHz Takt von ca +/- 20mV im Betrieb. Daraufhin fand ich folgendes in einer Xilinx Appnote: ---- In some cases, XC9500/XL/XV designs appear to experience erase time or programming time extension as the design progresses — particularly for long chains. This extension is probably due to the fact that parts being reprogrammed have a large number of switching signals arriving at its inputs, which differs from the initial case where a blank part is being programmed. [...] • If free running clocks are delivered into the ISP CPLD, it might be necessary to disconnect or disable the clocks in order to avoid clock noise during CPLD programming. ---- Und tatsächlich, sobald ich den 74HC14 mal aus der Fassung herausnehme, funktioniert das Programmieren wieder. Der CPLD steuert insgesamt 4 IR2110 Halbbrückentreiber, die mit 15V versorgt werden. Hinter den Treibern sind MOSFET Brücken, an die aber keinerlei Last angeschlossen ist. Während des Betriebs bricht die 15V Versorgungsspannung ungefähr um +40mV/-180mV ein (kommt aus einem Schaltregler). Ein Test ohne Halbbrückentreiber (MOSFETs haben Pulldown am Gate) ergab, dass sich das Gerät ebenfalls wieder programmieren lässt. Jetzt stellt sich mir die Frage, warum der CPLD sich nicht mehr "gescheit" programmieren lässt. Die Versorgungsspannung ist nach wie vor sehr ripple-frei. Hat jemand Erfahrung mit solchen Problemen? Wie siehts aus mit externen JTAG Pull-Up/Down Widerständen? Muss man hier was optimieren? Vielen Dank schon mal. Auch in der Erwartung, dass da wohl so niemand was zu sagen kann ;-) Nachtrag: Das verwendete WebPack ist 13.1. Aber auch mit dem iMPACT aus 14.1. erhalte ich die gleichen Symptome. Ich habe auch einen IDCODE-Looping Test ausgeführt. Dabei gibt es keinerlei Problem: '1': IDCODE loop completed successfully 10000 times. PROGRESS_END - End Operation. Elapsed time = 5 sec. * 41/72 Macrocells Used 147/360 Pterms Used 25/72 Registers Used 26/34 Pins Used 56/216 Function Block Inputs Used
Habe ich versucht und es gibt teilweise eine subjektive Verbesserung. Aber bei voll bestückten Gate-Treibern bringt auch 750kHz (Minimum Takt?) das oben genannte Verhalten.
Wie sieht denn Deine Versorgungsspannung waehrend dem Programmieren aus?
Versuch bei dem 74hc14 doch die Oszillation durch das TMS Signal zu sperren (z.B. durch zusätzlichen Transistor der von TMS gesteuert wird).
Ernst Gemeint schrieb: > Wie sieht denn Deine Versorgungsspannung waehrend dem Programmieren aus? Muss ich mal versuchen zu messen. Da der Löschvorgang ja (zumindest laut iMPACT) nicht fortschreitet, fragt sich, wie ich das messen soll. Hm. Uwe schrieb: > Versuch bei dem 74hc14 doch die Oszillation durch das TMS Signal zu > sperren (z.B. durch zusätzlichen Transistor der von TMS gesteuert wird). Auf so "krude" Methoden wollte ich erst mal verzichten. Möglicherweise befindet sich ja tatsächlich irgendwo noch ein Problem auf dem Layout. Ich weiß nur nicht so recht, wo ich anfangen soll zu suchen. Komisch finde ich, dass Xilinx den IDCODE-Loop Test vorschlägt um herauszufinden, wie viel System Noise so vorhanden ist. Selbst mit 100.000 Iterationen (Knapp 53 Sekunden) ist der Test erfolgreich. Also vermute ich mal nicht, dass hier das Problem liegt. Möglicherweise ist das USB Programming Cable von Digilent da etwas anfällig gegen Störungen? Oder vielleicht der USB vom PC zum Gerät.
This extension is probably due to the fact that parts being reprogrammed have a large number of switching signals arriving at its inputs, which differs from the initial case where a blank part is being programmed. [...] • If free running clocks are delivered into the ISP CPLD, it might be necessary to disconnect or disable the clocks in order to avoid clock noise during CPLD programming. Sagt doch alles oder : frei Übersetzt: Dies kommt warscheinlich daher, daß der Takt auf zu viele interne inputs geht. Das gleichzeitige Umschalten dieser scheint den Konfigurationsprozes zu stören. Wenn frei laufende Takte ins ISP CPLD gehen, könnte es erforderlich sein diese zu deaktivieren oder zu entfernen um Takt Störungen zu verhindern wärend der Programmierung.
Man könnte eventuell ein "Clock enable" im internen Clock tree einbauen (also direkt nach dem 74hc14), der alle clock inputs vom Pin trennt. Dann braucht man nichts im Layout zu verändern.
Uwe schrieb: > Dies kommt warscheinlich daher, daß der Takt auf zu viele interne inputs > geht. Das gleichzeitige Umschalten dieser scheint den > Konfigurationsprozes zu stören. Hmm, okay. Also exakt so habe ich es noch nicht gesehen. Daher halte ich deine Lösung: Uwe schrieb: > Man könnte eventuell ein "Clock enable" im internen Clock tree einbauen > (also direkt nach dem 74hc14), der alle clock inputs vom Pin trennt. > Dann braucht man nichts im Layout zu verändern. ... für praktikabel. Das werde ich mal testen. Ein ENABLE Pin hat mein Layout sowieso Aber ich finde es schon komisch, dass der JTAG Reset nicht sowieso alle Eingänge von der internen Logik trennt. Einen Mikrocontroller kann ich doch auch im RESET halten, damit er sich programmieren lässt. Deshalb auch meine Frage: Gibts Leute, die das Problem schon mal hatten?
Also funktionieren tut der Hack mit dem internen Clock-Gating. Aber ich finde es trotzdem irgendwie sehr unschön. Komisch ist, dass ich im Netz überhaupt nichts zu dem Problem gefunden habe, außer eben diese AppNote. Woran das wohl liegt? Vielleicht kann jemand noch etwas Licht ins Dunkle bringen?
Versuch doch mal, dir ein grottenaltes "Parallelkabel-3" zu bauen und zu benutzen. Ist im Prinzip nur ein simpler Bustreiber und funktioniert zumindest bis zur ISE Version 10 problemlos. Welche ISE Version hast du denn? Mit so einem Ding (an ner Netmos-Multi-IO Karte) werkele ich und hab bislang noch nie damit Probleme gehabt. Kabellänge vom Bustreiber zur Leiterplatte so etwas 20..25 cm und dort nochmal ca. 5..10 cm Leiterzüge. Allerdings werkeln die XC95..XL bei meinen Anwendungen mit Takten im Bereich von 10..50 MHz. Ach nochwas: Die Netmos-Karten arbeiten auf 3.3Volt. Also sollte man dem Bustreiber aka "Parallelkabel" auch nur so viel als Vcc geben. W.S.
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.