ich habe zwei Atmel JTAG ICE mk-II. Einen mit Seriennr. A09-0041.. und einen mit Seriennr. B000.... auf dem Etikett. Also beide Hardware Rev. 1 (Hardware revision 1 supports both PDI and aWire. Serial numbers start with A09-0041 or B0...).
Ich teste sie über den JTAG-Anschluss an einem Atmel MEGA-1284P XPLAINED mit avrdude unter Linux.
Der mit Seriennr. A09-0041 funktioniert, der mit Seriennr. B000.. liefert den Fehler:
1
avrdude jtagmkII_program_enable() warning: bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID
2
avrdude jtagmkII_program_enable() warning: retrying with external reset applied
3
avrdude jtagmkII_program_enable() warning: bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID
- use -B to set lower ISP clock frequency, e.g. -B 125kHz
8
- use -F to override this check
Aus AVR067: JTAGICE mkII Communication Protocol
1
5.2.18 Illegal JTAG ID (RSP_ILLEGAL_JTAG_ID: 0xA9)
2
The master has attempted to enter programming mode but the JTAG ID does not
3
match the target device.
Diesem Beitrag nach Beitrag "Re: AVR JTAG ICE mkII" könnte das am Kabel liegen, oder? Den zweiten JTAGICE mk-II mit der Fehlermeldung habe ich gerade gebraucht gekauft. Das Flachbandkabel hat zwei bis drei leichte Knickstellen.
Ohne Fehler:
1
$ lsusb
2
Bus 001 Device 012: ID 03eb:2122 Atmel Corp. XMEGA-A1 Explained evaluation kit
3
Bus 001 Device 013: ID 03eb:2103 Atmel Corp. JTAG ICE mkII
4
5
$ avrdude -c jtag2 -p m1284p -P usb -v -n
6
7
avrdude: Version 7.1
8
Copyright the AVRDUDE authors;
9
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
10
11
System wide configuration file is /etc/avrdude.conf
12
User configuration file is /home/alesi/.avrduderc
13
User configuration file does not exist or is not a regular file, skipping
14
15
Using Port : usb
16
Using Programmer : jtag2
17
avrdude: usbdev_open(): found JTAGICE mkII, serno: 070000000...
18
JTAG ICE mkII sign-on message:
19
Communications protocol version: 1
20
M_MCU:
21
boot-loader FW version: 255
22
firmware version: 7.39
23
hardware version: 0
24
S_MCU:
25
boot-loader FW version: 255
26
firmware version: 7.39
27
hardware version: 1
28
Serial number: 07:00:00:00:...
29
Device ID: JTAGICEmkII
30
AVR Part : ATmega1284P
31
Chip Erase delay : 55000 us
32
PAGEL : PD7
33
BS2 : PA0
34
RESET disposition : possible i/o
35
RETRY pulse : SCK
36
Serial program mode : yes
37
Parallel program mode : yes
38
Timeout : 200
39
StabDelay : 100
40
CmdexeDelay : 25
41
SyncLoops : 32
42
PollIndex : 3
43
PollValue : 0x53
44
Memory Detail :
45
46
Block Poll Page Polled
47
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
Diesem Beitrag nach Beitrag "Re: AVR JTAG ICE mkII"
könnte das am Kabel liegen, oder?
Ja schon. Aber evtl. auch an unterschiedlicher Firmware-Version.
Du könntest ja mal versuchen zu updaten oder auch zu downgraden.
Auf jeden Fall beide auf gleichen Firmware-Stand bringen ...
in welcher Richtung genau muss ich den Stecker auf der Platine des JTAG-mkII abziehen? Muss ich dabei noch "Pins", die eingerastet sind, bei Seite drücken? Gibt es einen Link mit Bildern wie Stecker und Sockel einzeln aussehen?
Der schwarze Rahmen auf dem mittleren Bild muss vorsichtig in Richtung des Folienleiters gezogen werden. Dann kann man mit wenig Kraft den Folienleiter herausziehen.
Danke Harald und Jörg. Ich war mir nicht ganz sicher, ob man nur das Flachbandkabel oder auch einen Teil des Plastiks abziehen muss. Hat geklappt - siehe Bilder.
beim gerade gebraucht gekauften JTAG ICE mk-II war das komplette Zubehör dabei - nur das Ersatzflachbandkabel nicht. Ich habe aber eines von meinem anderen JTAG ICE mk-II. Das habe ich jetzt beim nicht funktionierenden JTAG ICE mk-II mit Seriennr. B000. eingesetzt. Leider kommt wieder die gleiche Fehlermeldung:
1
$ lsusb
2
Bus 001 Device 007: ID 03eb:2122 Atmel Corp. XMEGA-A1 Explained evaluation kit
3
Bus 001 Device 006: ID 03eb:2103 Atmel Corp. JTAG ICE mkII
4
5
$ avrdude -c jtag2 -p m1284p -P usb -v -n
6
7
avrdude: Version 7.1
8
Copyright the AVRDUDE authors;
9
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
10
11
System wide configuration file is /etc/avrdude.conf
12
User configuration file is /home/alesi/.avrduderc
13
User configuration file does not exist or is not a regular file, skipping
14
15
Using Port : usb
16
Using Programmer : jtag2
17
avrdude: usbdev_open(): found JTAGICE mkII, serno: 00B00000...
18
JTAG ICE mkII sign-on message:
19
Communications protocol version: 1
20
M_MCU:
21
boot-loader FW version: 255
22
firmware version: 7.39
23
hardware version: 0
24
S_MCU:
25
boot-loader FW version: 255
26
firmware version: 7.39
27
hardware version: 1
28
Serial number: 00:b0:00:00:...
29
Device ID: JTAGICEmkII
30
...
31
...
32
...
33
avrdude jtagmkII_program_enable() warning: bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID
34
avrdude jtagmkII_program_enable() warning: retrying with external reset applied
35
avrdude jtagmkII_program_enable() warning: bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID
Man könnte mal die vier JTAG-Signale mit dem Oszilloskp betrachten
ob da immer gültige Pegel daherkommen. Nachdem der JTAGICE ja
an seinem Port Pegelwandler hat könnte einer davon angeschossen
sein - er würde ja auch den Rest der Schaltung schützen sodass
die innere Schaltung des ICE nur sehr unwahrscheinlich beschädigt
ist. Also wenn die JTAG-Signale nicht ok sind (analog messen,
nicht mit Logikanalysator!) könnte man sich daran machen einen
Pegelwandler auszutauschen.
Nachdem der JTAGICE ja
an seinem Port Pegelwandler hat könnte einer davon angeschossen
sein
Ich habe da auch schon kaputte gewechselt. Vor allem in der A-Version waren die relativ ungeschützt am Ausgang und man konnte sie schon zerstören, wenn man den Stecker eine Reihe falsch eingesteckt hat. Allerdings ist es hier ja die B-Version, die nicht funktioniert. Einen Versuch, die Signale anzusehen, wäre es aber allemal wert.
Was lasse ich am besten laufen, um die Signale am Oszi zu beobachten.
Auf jeden Fall eher niedrige Taktfrequenz wählen damit man
das Ereignis länger betrachten kann. Im Fehlerfall zeigt sich
dann kein Low oder High wo eines sein sollte, oder der Low-/High-
Pegel ist nicht ausreichend innerhalb der Spezifikation.
Offensichtlichstes Beispiel ist ein "halber" High-Pegel. Dabei
muss man immer von der Betriebsspannung ausgehen die der
Vtarget Pin des ICE misst da ja die JTAG Pins (oder SPI Pins)
auf diesen Pegel einjustiert werden.
Wäre ja auch interessant bzw. wichtig zu wissen ob das Problem
bei SPI und JTAG auftritt oder nur in einem Fall.
Natürlich kann das sein (bei einem defekten Halbleiter),
soll aber nicht.
So etwa wie ich es erwartet habe. Auf der TDO Leitung
kommt für den Slave nur eine müde Dauer-Null heraus.
Mit dem zweiten funktionierenden zeigt das Oszibild an Ch 2 TDO nur zwei Pegel, 0 oder 3.3 V. Ich bin mir aber nicht sicher, dass die Triggerzeitpunkte identisch sind. Ch 4 TDI ist hier permanent auf low.
Mein altes ATmega1284-Board geht irgendwie nicht mehr, habe jetzt einen ATmega16 auf die Schnelle gefunden. Der dürfte zwar in den JTAG-Details etwas anders sein, aber das Bild im Großen und Ganzen sollte dasselbe sein.
Der erste Ausschnitt zeigt die Initialisierung des ICE, bis dahin scheint TDO zu floaten und auf low zu liegen. Ab da bleibt es dauerhaft auf Vcc (hier 5 V), bis auf die eigentliche Kommunikation. Der Anfang der Kommunikation ist auf dem zweiten Bild.
Ich könnte dir auch die komplette Salae-Mitschnitt-Datei zum Anschauen geben, aber die ist zig Megabyte groß.
Denke schon, dass es bei dir einen der Maxim-Pegelwandler geschossen hat.
Man kann die Dinger mit Heißluft problemlos wechseln. Früher war Maxim recht freigiebig damit, jedermann oder -frau von jedem IC zwei Muster in die Hand zu drücken. Ich weiß nicht, ob sie das jetzt immer noch sind, nachdem sie zu Analog Devices gehören. Aber die Pegelwandler dürfte es auch bei Mouser etc. geben.
Man kann die Dinger mit Heißluft problemlos wechseln.
Eine Heißluftstation habe ich nicht und ein IC auszutauschen ist für mich erfahrungsgemäß schwieriger als ein IC neu einzulöten.
Der Vollständigkeit halber anbei nochmal zwei Oszilloskopbilder von beiden JTAG ICE mk-II zum gleichen Zeitpunkt, getriggert auf steigende und fallende Flanke von Ch 4 TDI bei 1.85 V; 2 V/div und 20 us/div.
Das erste Bild jtag05_no_error_ser_no_07.png zeigt das Bild vom funktionierenden JTAG ICE mk-II mit Sernr. 07... und das zweite Bild jtag06_error_ser_no_B0.png zeigt das Bild vom fehlerhaften JTAG ICE mk-II mit Sernr. B0. Da zeigt Ch 2 TDO drei Pegel.
Der MAX4712 ist ein Analogschalter. Ist natürlich auch nicht auszuschließen, dass es den getroffen hat, da habe ich leider keine da. Die kamen erst in der B-Version dazu, ich habe damals nur die A-Versionen reparieren müssen.
Die Pegelwandler sind die MAX3379, 3391 und 3392 in der Reihe darüber.
Was mich jetzt etwas stutzig gemacht hat: TDO sind ja die Daten, die vomAVR zum ICE kommen. So gehen sie zu Pin 11 des MAX4712, dessen Gegenstück ist Pin 10, und das geht zu Pin 5 des MAX3392, welches ein Eingang ist.
Das spräche natürlich dann schon dafür, dass so ein MAX4712 kaputt ist, oder aber dieses SP720ABG TVS-Dioden-Array.
Im Prinzip müsste man diese MAX4712 auch weglassen können (wie bei der A-Version), zumindest erstmal für einen Test die entsprechenden Pins überbrücken. Die sind offenbar eingefügt worden zur Verbesserung der Robustheit, um das ICE von der Schaltung abzutrennen, wenn es gerade nicht aktiv ist.
Auf dem Bild https://www.mikrocontroller.net/attachment/630547/jtag06_error_ser_no_B0.png sieht man, dass TDO durchaus auf einen korrekten High Pegel kommt (kurz, am Anfang). Wäre der Treiber defekt, wäre das nicht möglich. Für mich riecht der Fehler stark nach defekter / unpassender Firmware und nicht nach einem Hardware Problem.
Das sieht mir eher so aus, als würde jemand den High-Pegel (der
möglicherweise nur von einem Pullup erstmal kommt) auf 0,7 V herunter
ziehen.
Richtig. Aber eine defekte Hardware zieht immer und nicht nur ab und an. Ein Widerstand (1k als Vorschlag) in der Verbindung vom AVR zum ICE und schon kann man messen, welche Seite für das halbseidene Signal verantwortlich ist.
Aber eine defekte Hardware zieht immer und nicht nur ab und an.
Hängt davon ab, was defekt ist. Wenn es dieser Schalter ist, dann kann es schon sein, dass der plötzlich in Abhängigkeit von seinem Ansteuersignal Strom zieht oder nicht, statt das Signal nur durch zu leiten, wie es gedacht ist.
Dahinter ist ja nur der Eingang eines Pegelwandlers, den kann man auch nicht durch eine kaputte Firmware zum Ausgang konfigurieren oder sowas.
TDO sind ja die Daten, die
vom AVR zum ICE kommen. So gehen sie zu Pin 11 des MAX4712, dessen
Gegenstück ist Pin 10, und das geht zu Pin 5 des MAX3392, welches ein
Eingang ist.
Sowohl MAX4712 als auch MAX3392 sind von Haus aus bidirektional. Da kann der JTAGICE schon im Fehlerfall das Signal kurzschliessen. Messen heisst Wissen :-)
Sowohl MAX4712 als auch MAX3392 sind von Haus aus bidirektional.
MAX4712 ist ja nur ein Schalter, und den hätte ich jetzt auch in Verdacht.
Bezüglich MAX3392 liegst du jedoch falsch. TDO geht im ICE an Pin 5, und das ist ein dedizierter Eingang. MAX33xx kennt auch bidirektionale Treiber, aber 3392 ist dediziert.
Die Pegelwandler sind die MAX3379, 3391 und 3392 in der Reihe darüber.
Eine direkte niederohmige Verbindung von JTAG Pin 3 TDO (Litze 13 von links) messe ich nur zum MAX4712 und zum SP720ABG (Pins siehe Bild). Zu den Pins der Pegelwandler sind es meistens 500 oder 600 Ohm.
Eine direkte niederohmige Verbindung von JTAG Pin 3 TDO (Litze 13 von
links) messe ich nur zum MAX4712 und zum SP720ABG (Pins siehe Bild).
Ja klar. Das Prinzip (bei der B-Version) ist:
Der Pin geht an das TVS-Dioden-Array (SP720ABG) und von da zu einem der Anschlüsse der Analogschalter (MAX4712). Nur, wenn die Firmware den Analogschalter aktiviert, wird dann der MAX4712 durchgeschaltet, und ab da kommt das Signal weiter zu den Pegelwandlern.
Im Falle von TDO ist das Pin 10 des rechten MAX4712, der mit Pin 5 des MAX3392 verbunden ist (zumindest habe ich das auf meiner B-Version so „ausgeklingelt“).
Bei der A-Version war gingen die MAX33xx direkt auf die JTAG-Pins, was offenbar sehr häufig im praktischen Betrieb dann einen der Maxe das Leben gekostet hat, daher haben sie bei der B-Version in Richtung Robustheit nachgebessert.
Die einzig logische Erklärung für diese seltsam anmutenden Pegel auf TDO bei dir wäre daher ein Defekt im MAX4712, der dazu führt, dass abhängig von der Ansteuerung durch die Firmware eine unterschiedliche Last am TDO-Pin anliegt. (Wenn der MAX4712 ganz und der MAX3392 kaputt ist, dann sollte im nicht angesteuerten Zustand an TDO ein "high" von irgendeinem Pullup zu sehen sein.)
