Hallo, seit vielen Jahren habe ich mit meinem Atmel AVRJTAGICE mkII immer wieder mal das Problem, daß das Teil sich zwar mit dem Atmel Studio (ich verwende immer noch die Version 4.16-628 auf einem Win2000-PC - hatte noch keinen Update-Bedarf) per RS232 verbindet, aber nicht mit der Prozessor-Schaltung. Wenn diese Situation eintritt, kommt die Fehlermeldung, die Target-Spannung sei z.B. 1.666 V (in Registerkarte "HW Settings" steht dann aber z.B. 2.6V, was ja auch falsch ist - das System hat die korrekte 4.9 V, gut zu messen am ICE-Stecker). Dies geht dann einige Zeit so; ich schalte alles aus, starte das Atmel Studio neu; nach mehreren solchen Versuchen, eingeschlossen stundenlang alles ausgeschaltet zu lassen, funktioniert dann irgendwann wieder alles, tagelang. Bis es wieder auftritt. Provozieren kann ich das Problem z.B. auch damit, daß ich das JTD-Bit setze und den ICE damit "ausschließe". Wenn das mal geschehen ist, ist er "beleidigt", reagiert wie oben beschrieben und merkt sich das einige Zeit. Kennt jemand dieses Problem? Die Firmware-Version des ICE ist "Hardware Revision 0x00, Firmware Version 052c 052c". (Bitte keine Antworten der Art "Dann hol dir doch Studio 6.2!" - Meine Frage geht dahin, warum das Teil "manchmal" nicht funktioniert und nicht "immer nicht".). Günter
Günter R. schrieb: > Kennt jemand dieses Problem? So etwa einmal im Jahr, bei ständiger Benutzung, rutscht das FPC-Kabel um eine Winzigkeit aus der Fassung und es steht kaum sichtbar ein bisschen schräg. Das kann sowohl im Gerät als auch an der Adapterplatine sein. Dann treten auch die von dir beschriebenen Merkwürdigkeiten auf. Geht nicht, geht nach einiger Zeit wieder, bis es dann wieder nicht geht. Kabel lösen, wieder einstzen. Hat bei mir jedes Mal geholfen. mfg.
> Kabel lösen, wieder einstzen. Hat bei mir jedes Mal geholfen.
Kann ich bestätigen: Problem wie oben beschrieben, Massnahme wie von
Thomas beschrieben. Hilft für einen begrenzten Zeitraum. Dann
wiederholen.
Hallo, danke für eure Antworten. Ihr meint also, es sei ein simples Kontaktproblem? Könnte sein. Dagegen spricht allerdings, daß ich natürlich die Target-Spannung am Steckverbinder des ICE (ist ja sehr gut erreichbar) jeweils gemessen hatte. Wenn Atmel Studio sagte, es seien z.B. 2.6V, habe ich aber 4.9V gemessen, also die korrekte Spannung. Wie kann das ICE dann auf 2.6V kommen? Das ist mir noch nicht klar. Masseproblem? Das hatte ich allerdings nicht gemessen (Versäumnis!).
Günter R. schrieb: > Dagegen spricht allerdings, daß ich > natürlich die Target-Spannung am Steckverbinder des ICE (ist ja sehr gut > erreichbar) jeweils gemessen hatte. An welchem Steckverbinder? Aussen (am Ende des Kabels) oder innen (im Gehäuse des JTAG ICE)?
Günter R. schrieb: > Masseproblem? Das hatte ich allerdings nicht gemessen (Versäumnis!). Ich habe mir einmal eine Com-Schnittstelle teilweise geschrottet als ich einen Selbstbau-Programmer für Ponyprog verwendete. Das Netzteil für den Mikrocontroller und das des Computers waren "weit" voneinander entfernt am 220V-Netz angeschlossen. Dadurch ergab sich eine Potentialdifferenz der (sekundären) Masse zwischen PC und Mikrocontroller. Zunächst wollte die sonst gut funktionierende Programmierung nicht klappen, dann - durch weiteres Herumprobieren - verabschiedete sich die Com-Schnittstelle. Seitdem haben meine Testaufbauten und mein PC explizit eine gemeinsame Masse. Woher die Potentialdifferenz nun wirklich kam lässt sich nicht so leicht sagen. Wie so oft gilt: Your mileage may vary.
Atduinoquäler schrieb: > An welchem Steckverbinder? > > Aussen (am Ende des Kabels) oder innen (im Gehäuse des JTAG ICE)? Nicht im Gehäuse des ICE, sondern am Ende des Kabels, also da, wo der ICE-Stecker an der Prozessorplatine angesteckt ist (hier mal ein Pollin AVR Board 2.0.1). An der Oberseite des ICE-Steckers sind ja die Lötpins sehr gut mit der Multimeter-Prüfspitze zu erreichen. Aber wie gesagt: die Masse zu messen wäre gut gewesen, das habe ich versäumt.
Arduinoquäler schrieb: > Das Netzteil für den Mikrocontroller und das des Computers waren > "weit" voneinander entfernt am 220V-Netz angeschlossen. Dadurch > ergab sich eine Potentialdifferenz der (sekundären) Masse zwischen > PC und Mikrocontroller. Die Netzteile (ich gehe mal von Steckernetzteilen aus) haben doch keinen PE-Anschluß, daher verstehe ich nicht, wo bei dir da eine Potentialdifferenz von der Netzseite herkommt. Daß natürlich die Massen von Prozessorschaltung und PC verbunden sind, ist ja klar, deshalb kanns ja eigentlich keine Potentialdifferenz geben, oder?
Günter R. schrieb: > Nicht im Gehäuse des ICE, Das wäre jedoch die interessante Stelle gewesen, denn erst an dieser Stelle kannst du einen potenziellen Kabelbruch oder eben eine schlechte Klemmstelle erkennen.
Günter R. schrieb: > daher verstehe ich nicht, wo bei dir da eine > Potentialdifferenz von der Netzseite herkommt. Du gehst von einem ganz bestimmten Netzteil-Typ aus. Diese Annahme ist stark fehlerbehaftet. Eine leicht durchzuführende und vertrauensbildende Massnahme wäre, das Massepotential zwischen den verschiedenen Teilnehmern mittels Multimeter (Spannungsmessung oder auch Strommessung) nachzumessen.
Jörg Wunsch schrieb: > Das wäre jedoch die interessante Stelle gewesen, denn erst an dieser > Stelle kannst du einen potenziellen Kabelbruch oder eben eine schlechte > Klemmstelle erkennen. Okay, hast recht, mache ich beim nächsten Auftreten.
Jörg Wunsch schrieb: > Günter R. schrieb: >> Nicht im Gehäuse des ICE, > > Das wäre jedoch die interessante Stelle gewesen, denn erst an dieser > Stelle kannst du einen potenziellen Kabelbruch oder eben eine schlechte > Klemmstelle erkennen. Heute trat dieses Problem wieder auf. Nach Jörgs Vorschlag habe ich das Gehäuse des JTAGICE aufgeschraubt und sehe links vom Flachkabelanschluß 3 LEDs (ganz links grün, leuchtet und wird aber dunkler, wenn ich am Prozessorboard die Reset-Taste drücke und geht aus, wenn das Prozessorboard abgeschaltet wird; Mitte rot, leuchtet immer; rechts auch grün, leuchtet kurz auf bei Befehlen vom AVR Studio). Die Flachkabelleiter sind natürlich extrem eng, vermutlich ist auch immer noch ein GND-Leiter zur Abschirmung eingepflegt. Kennt man den Schaltplan des ICE? Oder weiß jemand, wo ich etwas komfortabel die VTarget im ICE abgreifen könnte? An der rechten Seite des ICE gibt es unbestückte Lötaugen für Pin-Header, 2*5 und 2*2, beides je zweimal. Dort liegen zumeist ca. 4,88 V an, keine VTarget des Prozessorsystems. Kann man das Flachkabel austauschen? Wo würde man ein neues herbekommen?
Günter R. schrieb: > Die Flachkabelleiter sind natürlich extrem eng, vermutlich ist auch > immer noch ein GND-Leiter zur Abschirmung eingepflegt. Ja, so ist es. > Oder weiß jemand, wo ich etwas > komfortabel die VTarget im ICE abgreifen könnte? Komfortabel ist relativ. ;-) Das orange eingekreiste Lötauge bzw. der Basisvorwiderstand für die Vtarget-Erkennung rechts daneben dürften die am besten zugängliche Stelle sein. > Dort liegen zumeist ca. 4,88 > V an, keine VTarget des Prozessorsystems. Die Schottky-Diode (schwarzes Element „B2“ unten im Bild) dürfte aus Vtarget die Referenzspannung für die drei Maxim-Pegelwandler in der Bildmitte ableiten, daher liegt diese Spannung um (100 … 200) mV unter Vtarget. > Kann man das Flachkabel austauschen? Ja. > Wo würde man ein neues herbekommen? Schwierig. Bei den neueren Chargen hat Atmel ein zweites beigelegt, aber bei den ersten gab's das noch nicht. Wenn es bei dir erwiesenermaßen kaputt ist, dann meld' dich mal per Mail bei mir (Mailadresse wirst du finden ;), und ich werde sehen, was sich da machen lässt.
:
Bearbeitet durch Moderator
dein eigentliches Problem scheint also gelöst. Da du oben aber das mit dem JTD-Bit und dem aussperren angesprochen hast, ein kleiner Tip: Man kann dieses Bit auch per Software im MCUC-Register setzen, ein umprogrammieren der Fuses ist also nicht nötig. Wenn man dann noch einen Pin frei hat, könnte man dieses beim Programmstart abfragen um es immer noch setzen zu können. Ein kleiner DIP-Schalter oder Jumper wäre hier ganz praktisch.
Thomas O. schrieb: > Wenn man dann noch einen Pin frei hat, könnte man dieses beim > Programmstart abfragen um es immer noch setzen zu können. Muss man eigentlich gar nicht. Das Setzen des Bits wird nur wirksam, wenn man es zweimal direkt hintereinander ausführt. Will man debuggen, setzt man einfach einen Breakpoint auf genau diesen Befehl und geht im Einzelschritt drüber. Damit erfüllt man die zeitliche Bedingung nicht, und JTAG bleibt weiterhin aktiv.
Günter R. schrieb: > Heute trat dieses Problem wieder auf. Hast du das ausprobiert: Thomas Eckmann schrieb: > Kabel lösen, wieder einstzen. Hat bei mir jedes Mal geholfen. Rainer B. schrieb: > Kann ich bestätigen: Problem wie oben beschrieben, Massnahme wie von > Thomas beschrieben. Oder ist dir das als Fehlerursache zu banal? mfg.
Thomas O. schrieb: > dein eigentliches Problem scheint also gelöst. Da du oben aber das mit > dem JTD-Bit und dem aussperren angesprochen hast, ein kleiner Tip: > > Man kann dieses Bit auch per Software im MCUC-Register setzen, ein > umprogrammieren der Fuses ist also nicht nötig. Wenn man dann noch einen > Pin frei hat, könnte man dieses beim Programmstart abfragen um es immer > noch setzen zu können. Ein kleiner DIP-Schalter oder Jumper wäre hier > ganz praktisch. Danke für diesen Hinweis. Bei dem betrachteten System will ich allerdings nicht debuggen, sondern nur flashen; das geht auch mit per MCUCR gesetztem JTD-Bit, denn wenn man die Reset-Taste gedrückt hält (dann ist das JTD nämlich - weil nicht gefused, sondern nur per MCU-Register gesetzt - noch nicht aktiv) und erst dann den JTAG-ICE startet, funktioniert er einwandfrei (wenn nicht gerade das hier angesprochene Problem auftritt). Dann kann man flashen.
Thomas Eckmann schrieb: > > Hast du das ausprobiert: >> Kabel lösen, wieder einstzen. Hat bei mir jedes Mal geholfen. > > Rainer B. schrieb: >> Kann ich bestätigen: Problem wie oben beschrieben, Massnahme wie von >> Thomas beschrieben. > > Oder ist dir das als Fehlerursache zu banal? Nein, überhaupt nicht. Wie kann man das Kabel lösen? Einfach herausziehen und es wieder hineinstecken? Oder muß man an den Verbindungsleisten etwas machen? Irgendwo drücken? Ist der Einführungsschlitz so gut kalibriert, daß das Kabel dann auch von alleine richtig ausgerichtet ist? Beim Pitch von 0.5 mm erscheint mir das nicht selbstverständlich.
Jörg Wunsch schrieb: > Wenn es bei dir erwiesenermaßen kaputt ist, dann meld' dich mal per > Mail bei mir (Mailadresse wirst du finden ;), und ich werde sehen, > was sich da machen lässt. Sehr herzlichen Dank, Jörg. Ich komme darauf zurück, wenn die Reinsteck-Methode nicht funktioniert.
Jörg Wunsch schrieb: > Muss man eigentlich gar nicht. Das Setzen des Bits wird nur > wirksam, wenn man es zweimal direkt hintereinander ausführt. Will > man debuggen, setzt man einfach einen Breakpoint auf genau diesen > Befehl und geht im Einzelschritt drüber. Damit erfüllt man die > zeitliche Bedingung nicht, und JTAG bleibt weiterhin aktiv. Kannst Du nicht einfach auch JTRF prüfen und die Sequenz nur dann ausführen, wenn dieses Bit nicht gesetzt ist?
Günter R. schrieb: > Wie kann man das Kabel lösen? Wie bei den meisten dieser FPC-Steckverbinder: indem man den kleinen braunen Klemmrahmen zurückzieht. Habe das im Foto mal gemacht und den Schraubendreher da liegen lassen, wo nach dem Zurückziehen ein kleiner Zwischenraum entsteht. Vielleicht verdeutlicht es das ja. Mox schrieb: > Kannst Du nicht einfach auch JTRF prüfen und die Sequenz nur dann > ausführen, wenn dieses Bit nicht gesetzt ist? Was, wenn du direkt nach einem Power-on-Reset debuggen willst?
Jörg Wunsch schrieb: > Was, wenn du direkt nach einem Power-on-Reset debuggen willst? Ohne Debug-Adapter? Dann brauchst Du JTAG nicht. Mit Debug-Adapter? Bislang hat dieser bei mir beim Verbinden mit dem Baustein auch einen Reset ausgeführt. Es kann natürlich sein, dass ich noch etwas übersehe. Also wenn Du konkrete Probleme siehst, nenne diese doch bitte direkt beim Namen. Auf Familien-Quiz habe ich eben wenig Lust.
Mox schrieb: > Bislang hat dieser bei mir beim Verbinden mit dem Baustein auch einen > Reset ausgeführt. Muss er nicht (man kann ihn auch ohne Reset aufsetzen und eine bereits laufende Firmware debuggen, auch wenn AVR/Atmel Studio das ggf. nicht unterstützt), aber du hast natürlich recht, in diesem Falle wäre dann ohnehin durch die vorher bereits gelaufene Firmware JTD gesetzt, sodass gar kein JTAG klappt. Damit klingt die Variante, das JTRF zu testen, sinnvoll.
Günter R. schrieb: > Thomas Eckmann schrieb: >> >> Hast du das ausprobiert: >>> Kabel lösen, wieder einstzen. Hat bei mir jedes Mal geholfen. >> Hab ich jetzt probiert, funktioniert perfekt, auch dank Deines Fotos, Jörg - vielen Dank! Rausziehen und zurück geht gut, hätte ich nicht gedacht.
Bitte 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.