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!!
