Hallo zusammen, ich habe mich heute beim Debuggen meines AT90CAN128 mit dem JTAGICE mkII offensichtlich durch die Verwendung einer zu langen Programmierleitung dauerhaft aus dem Controller ausgesperrt, d.h. während sein "letztes" Programm weiterhin und fehlerfrei ablief, konnte ich weder per JTAG, noch per ISP auf ihn zugreifen. Da ich mich nicht zu tief mit der Materie auseinandergesetzt habe (und dies auch gar nicht möchte ;) ), mir aber sicher bin, dass es hier schon jemand getan hat, möchte ich meine Frage gern an euch weiterreichen: Welche Schritte werden im Rahmen einer JTAG-Übertragung durchgeführt (Setzen von Lockbits, ...), die bei aus der Verwendung z.B. zu langen Programmierkabels resultierenden Ausbleibens notwendiger Folgeschritte zum genannten Fehlverhalten führen können? BTW: Ich habe anschließend noch einmal versucht, den Fall zu reproduzieren, es war zwar hin und wieder keine Verbindung möglich, das dauerhafte Aussperren trat allerdings nicht mehr auf. Jemand irgendwelche Ideen?
Es kann passieren ! Ich habe per ISP auch schon einge Atmel ins Nirvana geschickt. Meine Theorie dazu ist irgendwie so: Durch störungen im Gefüge der Takte wird die Adresse nicht korrekt übertragen und das Programm landet mitten im Fusesbereich. Irgendwann bau ich dann den HV Resetter. Gruss Klaus de Lisson
Hi, Developer0815, > Welche Schritte werden im Rahmen einer JTAG-Übertragung durchgeführt > (Setzen von Lockbits, ...), die bei aus der Verwendung z.B. zu langen > Programmierkabels resultierenden Ausbleibens notwendiger Folgeschritte > zum genannten Fehlverhalten führen können? Keine. Das Setzen der Fuse- und Lockbits erfordert eigene Befehle, die in den JTAG-Anwendungen wie Flashen oder Debuggen nicht vorkommen. Auch nicht vorkommen dürfen. Aber - die JTAG/ICE-Verbindung zum uP ist Open Collector, also anfälliger auf Einstreuungen als eine Totem-Pole-Verbindung. Damit steigt die Wahrscheinlichkeit eines Übertragungsfehlers im Kommando. Wäre der Abstand groß zwischen uP und uC, dann doch bitte eine lange RS-232 oder USB zum JTAG/ICE. Bevor Du Deine Baugruppe in die Werkstatt bringst zu den Künstlern, die einen neuen Chip reinsetzen, probiert Dein JTAG/ICE doch erst mal an einem STK500 oder ähnlich. Mit Einstreuungen hatte ich keinen Ärger, wohl aber mit Problemen zwischen Atmel Studio und JTAG/ICE. Ciao Wolfgang Horn
Hi, dankesehr schonmal..! Also Austauschen kann ich den µC zum Glück vor Ort selber, mit dem neuen geht´s dann auch wieder. Interessanterweise habe ich mich grad nochmal mit nem Kollegen unterhalten, der sich ebenfalls durch zu lange Programmierleitung mal einen µC zergrützt hat, allerdings in einem schleichenden Prozess, wo es immer öfter zu Störungen kam und der µC dann irgendwann hinüber war. Nun ist mir ja klar, das JTAG da deutlich anfälliger als zB allein schon ISP, und vor allem habe ich ja daraus gelernt, da eben KEINE zu langen leitungen mehr zu verwenden, trotzdem: Kannst Du (oder jemand anders) sich wirklich kein Szenario denken, wie es genau zu dem Fehler gekommen sein könnte? Wie gesagt: Dass eine Verbindung TEMPORÄR nicht funktioniert kann ich mir noch erklären, aber DAUERHAFT (zumal der µC ja ansonsten einwandfrei lief, also nicht wirklich "geschrottet" war)...
Sag mal Developer0815, bin ich irgendwie unsichtbar ? war dir meine Erklärung zu wage ? Ich schrieb doch , dass durch lange Kabel der Takt aus dem Takt kommen kann und dadurch die internen Zieladressen nicht mehr stimmen. Dadurch gelangt Programmcode (nicht dafür bestimmt) mitten auf den Speicherbereich für die Fuses. Seit einigen Jahren kann ich z.B. 5m Flachbandkabel nehmen und trotzdem sicher über ISP proggen. Ich habe hier allerdings Optokoppler für Hin- und Rückweg drinne. Vor einigen Jahren habe ich sogar mal Testweise durch eine 50m Rolle Kabel programmieren können. Allerdings hatte ich da an beiden Enden RS485 Treier eingebaut k.
Hi, Developer0815, > Kannst Du (oder jemand anders) sich wirklich kein Szenario denken, wie > es genau zu dem Fehler gekommen sein könnte? Also ausführlicher. Im Datenblatt zu den Atmegas ist zu lesen, wie Atmel Studio über JTAG/ICE eine bestimmte Kommandofolge sendet zum Setzen der Fuses und Lock-Bits. Sollte irgendeine Einstreuung ein anderes Kommando so verändern, dass der uP es als Lockbit-Kommando liest - Pech gehabt. Das ist mir aber noch nie passiert. Nimm einen Tastkopf und prüfe die Umgebung um Deinen Aufbau. Könnte vielleicht ein Markt sein für einen Monitoring-Empfänger, der störende Pulse empfängt und mit Zeitstempel loggt? Ciao Wolfgang Horn
Klaus De lisson schrieb: > Sag mal Developer0815, > bin ich irgendwie unsichtbar ? > war dir meine Erklärung zu wage ? Hoppla, irgendwie habe ich deine Antwort tatsächlich einfach übersehen.. Wird halt Zeit fürs Wochenende :)... Danke jedenfalls auch Dir für die Antworten, alles in allem deckt sich das ja sehr mit meinen Vermutungen... Schönes WE!!
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.