Hallo, Ich habe gestern einen neuen JtagICE3 bekommen und wollte das JTAG Interface an einem ATMEGA16-16PU testen. Jedoch schaffe ich es nicht eine Verbindung mit dem µC aufzubauen. Dabei bekomme ich jedes mal folgenden Fehler, wenn ich die ID auslesen möchte: " Unable to enter programming mode. Please verify device selection, interface settings, target power and connections to the target device. " Target Power schließe ich aus, da er die 5V targetpower auch ausliest. Zu meinem System: Windows 7 ATMELSTUDIO 6 JTAGICE 3 Atmega16 auf Steckboard mit 8MHZ Quarz und 5V Verorgung Jtagice wurde über das squid cable wie folgt verbunden: 1----PC2 (TCK) 2----GND 3----PC4 (TDO) 4----+5V 5----PC3 (TMS) 6----/Reset 7----N.C. 8----N.C. 9----PC5 (TDI) 0----GND als JTAG clock versuchte ich schon einige frequenzen zwischen 32kHz und 7,5MHz. Die Signale Des JTAG-Interface zeichnete ich mit einem LA auf und sah, dass sich auf der Leitung TDO nichs tut. Weiters habe ich eine Verbindung zwischen JTAGICE3 und Atmega16 über ISP herstellen können. Somit konnte ich die Fuses einstellen. (OCDEN , JTAGEN, SPIEN) wurden Aktiviert Somit ergeben sich folgende Fuse zustände: HIGH: 0x19 LOW: 0xCF Jedoch war ich bis jetzt noch nicht im Stande das Problem zu lösen. Ich hoffe Ihr könnt mir helfen. Danke im Voraus. mfg Christoph
Habe gerade alles nochmal neu gesteckt und es funktioniertE! Als ich jedoch ein zweites mal die JTAG ID auslesen wollte hatte ich wider das gleiche Problem!! mfg Christoph
Angehängte Dateien:
-
JTAG_timing.png
65 KB
Danke für den Hinweis Habe jetzt auf ATMELstudio 6.1 upgedated und den Jtagice von Version 2.a auf 2.13 Hat jedoch nichts geholfen same problem. Auf der Leitung TDO tut sich nichts wie man im Anhang sieht. mfg Christoph
folgenden Code hatte ich im Ausgabefenster: " 03 00 19 081: pro No JTAG devices detected. Debugger command Activate physical failed. 03 00 19 082: No JTAG devices detected. Debugger command Activate physical failed. " mfg Christoph
Angehängte Dateien:
-
Fuses.png
61 KB
Im Anhang nochmal die Fuses die ich über das ISP Interface ausgelesen habe. mfg Christoph
christoph schrieb: > Auf der Leitung TDO tut sich nichts wie man im Anhang sieht. Klar, das ist ja letztlich das, was dir das JTAGICE auch sagt: da reagiert niemand. Normalerweise sind das entweder Verkabelungsprobleme oder eine gelöschte JTAGEN-Fuse. Letzteres kann man ausschließen, weil du die Fuses ja über ISP lesen kannst, und die geposteten Werte passen, da ist JTAGEN gesetzt. Blieben also noch irgendwelche Wackelkontakte oder sowas.
christoph schrieb: > Im Anhang nochmal die Fuses die ich über das ISP Interface ausgelesen > habe. Schrobst du ja weiter oben schon. Die 0x19 der high fuse ist das Entscheidende. Genauer gesagt, das Bit 6 darin, das muss 0 sein.
Hallo, danke für die schnelle Antwort. Wenn es ein Wackelkontakt sein sollte, kann dieser nur auf der TDO-Leitung sein, da alle anderen einwandfrei schalten. Jedoch schließe ich einen Wackelkontaktauf der TDO-Leitung auch aus, weil ich gerade eine Widerstandsmessung zwischen dem PC4(TDO) pin des Controllers und dem TDO Steckerpad auf der Jtagiceplatine gemacht habe. Dieser ergibt 0.7Ohm => vernachlässigbar. also kann das auch nicht das Problem sein. Leider noch immer kein Erfolg aber Danke. mfg Christoph
Was hast du denn als Verkabelung? Hoffentlich kein Steckbrett …
Verkabelt hab ich das auf einem Steckbrett mit Jumperwire. mfg
Hab jetzt auch noch die anderen Leitungen durchgemessen und alle passen. Was ich nicht verstehe ist dass es bereits 1 mal funktionierte und 10sec später nicht mehr.
christoph schrieb: > Verkabelt hab ich das auf einem Steckbrett mit Jumperwire. Steckbretter haben riesige Kapazitäten, das ist für einen schnellen Bus wie JTAG ziemlich ungünstig.
Dass die Kapazitäten auf einem Steckbrett relativ groß sind ist mit durchaus bewusst. Nur wenn ein JTAG interface mit 1MHz nicht funktioniert und ein SPI interface mit 1,8MHz schon dann glaube ich nicht, dass das Fehlverhalten vom Steckbrett kommt. Mfg Christoph
Angehängte Dateien:
-
waveform.png
8,1 KB
christoph schrieb: > Nur wenn ein JTAG interface mit 1MHz nicht > funktioniert und ein SPI interface mit 1,8MHz schon dann glaube ich > nicht, dass das Fehlverhalten vom Steckbrett kommt. Vorausgesetzt, die benutzten Leitungen haben jeweils vergleichbare Kapazitäten. Du kannst es aber drehen und wenden, wie du willst: es funktioniert bei dir nicht, sonst aber überall. Damit brauchst du die Fehler nicht woanders suchen, sondern irgendwo in deinem Aufbau. Da du ja sogar die Signale mit dem LA tracen kannst und die dort nicht antwortende TDO-Leitung beim ISP-Betrieb MISO ist (und dabei funktioniert), kannst du auch das ICE selbst als Fehlerursache ausschließen. Anbei ein LA-Trace der Initialisierungssequenz. Triggerpunkt ist die fallende Flanke von TMS. Der ATmega16 sitzt auf einem STK600, das ICE ist ebenfalls ein JTAGICE3.
Blöde Frage: Hast du an die Pullup-Widerstände gedacht?
Hab es jetzt mit Pull-Ups probiert, jodoch hat es auch nicht Funktioniert. Wie groß ist die Wahrscheinlichkeit, dass das JTAG Interface des Controllers defekt ist?
christoph schrieb: > Wie groß ist die Wahrscheinlichkeit, dass das JTAG Interface des > Controllers defekt ist? Naja, durch ESD oder dergleichen kannst du natürlich immer mal eine Padzelle killen. Da du ja ISP machen kannst, probier doch mal folgendes:
1 | #include <avr/io.h> |
2 | #define F_CPU 1E6
|
3 | #include <util/delay.h> |
4 | |
5 | int
|
6 | main(void) |
7 | {
|
8 | MCUCSR = _BV(JTD); |
9 | MCUCSR = _BV(JTD); |
10 | DDRD = 0xff; |
11 | |
12 | uint8_t i; |
13 | for (;;) { |
14 | for (i = 1; i != 0; i <<= 1) { |
15 | PORTD = i; |
16 | _delay_us(10); |
17 | }
|
18 | for (i = 1; i != 0; i <<= 1) { |
19 | PORTD = ~i; |
20 | _delay_us(10); |
21 | }
|
22 | }
|
23 | }
|
Bitte unbedingt mit Optimierung compilieren, sonst funktioniert das Setzen des JTD-Bits nicht. Das flashst du, danach misst du die Pins von Port D mit dem LA nach. Wenn da abwechselnd 1-Bits und 0-Bits durchgeschoben werden, sind die Portpins noch in Ordnung. Dass es dir gelingt, nur die JTAG-Engine zu schießen, obwohl die Pins noch funktionieren, halte ich für reichlich unwahrscheinlich.
Mal ne frage zum Programmcode. Wieso soll ich eine Shift-Operation am Port D durchführen, wenn der JTAG Controller am C Port sitzt? @Rainer Dünsch: hab ein LA und ein Analoges OSZi
1 | #include <avr/io.h> |
2 | #define F_CPU 1E6
|
3 | #include <util/delay.h> |
4 | |
5 | int
|
6 | main(void) |
7 | {
|
8 | MCUCSR = _BV(JTD); |
9 | MCUCSR = _BV(JTD); |
10 | DDRC = 0xff; |
11 | |
12 | uint8_t i; |
13 | for (;;) { |
14 | for (i = 1; i != 0; i <<= 1) { |
15 | PORTC = i; |
16 | _delay_us(10); |
17 | }
|
18 | for (i = 1; i != 0; i <<= 1) { |
19 | PORTC = ~i; |
20 | _delay_us(10); |
21 | }
|
22 | }
|
23 | }
|
Währe das nicht sinnvoller, wenn ich wissen will ob die JTAG pins funktionieren?
christoph schrieb: > Wieso soll ich eine Shift-Operation am Port D durchführen, wenn der JTAG > Controller am C Port sitzt? Weil ich wissen wollte, ob du das auch liest, was ich schreibe. :-)) Nein, ich hatte mich einfach versehen. Ja, nimm dein korrigiertes Beispiel, bitte.
christoph schrieb: > Also die Pins funtkionieren. Allerdings mit einer CPU-Frequenz von ca. 5 MHz (statt des 1 MHz, welches ich annahm). > JTAG nicht. Jetzt ist es wirklich seltsam. Gut, nach obiger Firmware funktioniert JTAG natürlich nicht (man müsste dann nSRST aktivieren, damit die Firmware nicht läuft), aber spätestens nach dem Löschen der Firmware muss es gehen. Wenn du unsere beiden LA-Traces vergleichst, dann passt das auch alles, also das JTAGICE erzählt genau das, was es soll. Allerdings kommt bei meinem Trace dann etwa in der Mitte die erste Antwort auf TDO raus. Hast du vielleicht doch mal einen zweiten Controller zum Testen? christoph schrieb: > Sollte nicht jetzt die JTAGN Fuse gelöscht sein? Nein, die Firmware schaltet das JTAG nur zur Laufzeit aus (über das JTD-Bit). Die Fuse ist davon unbeeinflusst.
Ich habe einen CPU takt von 8MHz zur Zeit nur Lose SMD Controller. Aber muss nachehr weg und da werde ich einen mitnehmen und dann mach ich mal ein Update. Ja die Traces hatte ich auch schon verglichen. mfg Christoph und Danke für die viele Hilfe
So was ist immer blöd und du kennst dich ja offensichtlich gut aus. Ich habe nur noch zwei Ideen dazu. Entweder ist der Programmer kaputt oder aber es liegt an einem Treiberproblem. Weiß jetzt nicht, ob der ICE3 auch den Jungo nimmt (ich mache (noch) nichts mit JTAG, aber vielleicht ist das noch ein Ansatz. Da es ja mal funktionierte und dein µC wohl funktioniert, denke ich eher an diese Möglichkeit. Kannst du vielleicht noch mal das Studio auf einem völlig anderen Rechner installieren und das mit dem probieren. Ich hatte auch schon mal diese Verbindungsprobleme und nachdem ich den Rechner von Hand völlig entmistet hatte, das Studio erneut installierte und somit den Jungo Treiber, dann lief es. Auch auf den schnelleren Frequenzen. Bei jeder zweiten Verbindung klappte es nicht mit dem MKII. Wichtig war dabei, dass der Jungo Treiber übers Studio installiert wurde. Eine direkte Installation erkannte zwar die Hardware, trotzdem klappte es nicht im Studio. Leider bin in noch lange nicht so weit wie ihr, aber vielleicht ist das trotzdem bedingt hilfreich. Ich wünsche dir viel Glück und Erfolg!
F. Fo schrieb: > Entweder ist der Programmer kaputt > oder aber es liegt an einem Treiberproblem. Die LA-Traces sprechen gegen beide diese Hypothesen.
Problem gelöst!!
Neuer Controller => Problem weg.
Habe jetzt 5 mal ID und Fuses Ausgelesen. Und es funktioniert sogar mit
7,5MHz am Steckbrett.
Abschließend noch mal mein Setup:
Windows 7
ATMELSTUDIO 6.1.2562
JTAGICE3
-Connection com.atmel.avrdbg.connection.jungousb
-Firmware Version 2.13
-Hardware Version 2
ATMEGA 16-16PU auf Steckbrett mit 8Mhz Quarz und +5V.
Jtagice wurde über das squid cable wie folgt verbunden:
1----PC2 (TCK)
2----GND
3----PC4 (TDO)
4----+5V
5----PC3 (TMS)
6----/Reset
7----N.C.
8----N.C.
9----PC5 (TDI)
0----GND
Keine Pullupwiderstände!
FUSES :
HIGH: 0x19
LOW: 0xCF
Danke an alle die Geholfen haben.
mfg Christoph
christoph schrieb: > Neuer Controller => Problem weg. Schön, wenngleich mehr als eigenwillig. Kannst du spaßeshalber mal obige Testapplikation ohne das Setzen des JTD-Bits in MCUCSR compilieren und auf den nicht funktionierenden Controller flashen? Es dürften ja dann (da JTAG eigentlich aktiv ist) nur PC0/1 und PC6/7 wackeln.
Jörg Wunsch schrieb: > F. Fo schrieb: >> Entweder ist der Programmer kaputt >> oder aber es liegt an einem Treiberproblem. > > Die LA-Traces sprechen gegen beide diese Hypothesen. Hallo Jörg, ich finde es nicht gut, meine Aussage so aus dem Zusammenhang zu reißen. Wenn man sich nur diesen einen Satz liest, so hört sich das wie eine sture Behauptung an und als würde ich alles wissen. Ich sehe mich noch als Anfänger und bleibe das auch sicher noch eine Weile. Wenn hier die Cracks am Werke sind, halte ich mich meistens ganz raus oder berichte nur von Erfahrungen die ich selbst gemacht habe. Das habe ich in diesem Fall getan - sehr vorsichtig, um nicht den Anschein zu erwecken, als könnte ich über Wasser laufen.
F. Fo schrieb: > Jörg Wunsch schrieb: >> F. Fo schrieb: >>> Entweder ist der Programmer kaputt >>> oder aber es liegt an einem Treiberproblem. >> >> Die LA-Traces sprechen gegen beide diese Hypothesen. > > Hallo Jörg, ich finde es nicht gut, meine Aussage so aus dem > Zusammenhang zu reißen. Nun ja, so sehr aus dem Zusammenhang war's ja nun auch nicht. Ich wollte dir auch keinesfalls damit "auf die Zehen treten", sorry. Allerdings hatten wir weiter oben bereits die LA-Traces von Christoph und mir verglichen und festgestellt, dass das JTAGICE3 in beiden Fällen die gleichen Signalfolgen erzeugt. Der Unterschied zwischen beiden Traces bestand ausschließlich darin, dass bei mir der ATmega16 in ca. der Hälfte des geposteten Bilds dann auf TDO seine Antworten generiert, während er bei Christoph stumm bleibt. Damit ist aber klar, dass das JTAGICE3 bei Christoph ordentlich funktionieren muss (zumindest bis zu diesem Zeitpunkt) und auch der Treiber (über dessen "Qualität" ich dir nicht widersprechen möchte ;-) sein Werk getan haben muss, dem ICE den entsprechenden Auftrag des Atmel Studio runterzureichen.
> > Nun ja, so sehr aus dem Zusammenhang war's ja nun auch nicht. Ich > wollte dir auch keinesfalls damit "auf die Zehen treten", sorry. > > Allerdings hatten wir weiter oben bereits die LA-Traces von Christoph > und mir verglichen und festgestellt, dass das JTAGICE3 in beiden > Fällen die gleichen Signalfolgen erzeugt. Der Unterschied zwischen > beiden Traces bestand ausschließlich darin, dass bei mir der ATmega16 > in ca. der Hälfte des geposteten Bilds dann auf TDO seine Antworten > generiert, während er bei Christoph stumm bleibt. Damit ist aber > klar, dass das JTAGICE3 bei Christoph ordentlich funktionieren muss > (zumindest bis zu diesem Zeitpunkt) und auch der Treiber (über dessen > "Qualität" ich dir nicht widersprechen möchte ;-) sein Werk getan > haben muss, dem ICE den entsprechenden Auftrag des Atmel Studio > runterzureichen. Da ich ja nicht so ein Crack wie ihr bin und auch nicht immer alles verstehe oder entsprechende Schlussfolgerungen nicht immer so herleiten kann, habe ich mich ja bewusst sehr vorsichtig ausgedrückt. Aber schon gut, Schwamm drüber.
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.