JTAGICE3 Atmega16-16 keine Verbindung via JTAG

christoph schrieb:
> ATMELSTUDIO 6

Mach mal das Update und den Programmer gleich auch updaten.

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.

Was hast du denn als Verkabelung?  Hoffentlich kein Steckbrett …

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.

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.

Rainer Dünsch schrieb:
> Blöde Frage: Hast du an die Pullup-Widerstände gedacht?

Braucht man keine.

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.

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.

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.

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.