Forum: Mikrocontroller und Digitale Elektronik JTAG ICE keine Verbindung zum Target


von Bodo.H (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,
vorab mein Kenntnisstand zu Atmel.
Bisher habe ich immer fertige .hex-file in die AVR Controller per 
Pony-Prog geschoben. Als Programmierboard benutze ich das Atmel 
Evaluationsboard Ver. 2.0 von Pollin.

Das reicht mir inzwischen nicht mehr. Ich möchte auch selber Programme 
schreiben. Als Programmiersprache habe ich "C" ausgewählt. Im nächsten 
Schritt habe ich mir WINAVR und AVR-Studio installiert.
Mit AVR-Dude habe ich auch dann den ersten selbst kompilierten Code in 
einen Atmel erfolgreich geschoben.

Da mußte jetzt auch ein JTAG ICE her. Um später auch ein debuggen zu 
ermöglichen.
Ich habe mir dann den JTAG ICE von Frank Erdrich ( 
http://www.uc-projects.com/ ) mit dem Atmega16 nachgebaut. Nachdem ich 
hier das richtige boot-hexfile gefunden habe, hat es mit dem Update über 
AVRstudio geklappt.

AVRStudio stellt auch einen Kontakt zum JTAG ICE her. Aber das Target 
wird nicht erkannt. Als Target benutze ich das oben genannte Pollinboard 
mit einem ATmega 16, oder32 oder 8535. Bei allen das gleiche Fehlerbild 
wie im Dateianhang zu sehen.
Auch wenn ich den PIN 32 (AREF)des Ziel-Atmega mit VCC verbinde,das 
gleiche Fehlerbild.

An welcher Stelle muss ich weiter suchen? Meine suche hier im Board hat 
mich durch zig Beiträge gelotst, aber ich bin nicht schlau raus 
geworden.
MfG

Bodo

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bodo.H wrote:

> An welcher Stelle muss ich weiter suchen?

Steht doch im Prinzip da: an der Verbindung zwischen ICE und dem
Ziel-Controller ("target").  Ein Oszilloskop kann da hilfreiche
Dienste leisten, wenn du selbst keins hast (einfache Analogteile
kosten nicht mehr viel bei ebäh), vielleicht kennst du ja jemanden,
der eins hat.

Bitte Bildformate beachten.

von Analog (Gast)


Lesenswert?

Sieht aber stark danach aus, als ob das Target keinen Power hat.
Kontrolliere mal, ob GND verbunden ist. Das Pollinboard muss eine 
eingeschaltete Versorgung haben.

So.

GND
VCC
TDI
TDO
TMS
TCLK
Reset

>Auch wenn ich den PIN 32 (AREF)des Ziel-Atmega mit VCC verbinde,das
>gleiche Fehlerbild.

Also AREF von ATmega auf dem JTAG muss an VCC vom Pollinboard

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Analog wrote:

> Also AREF von ATmega auf dem JTAG muss an VCC vom Pollinboard

Das dürfte aber hier nicht das Problem sein.  Wenn er keine Vtarget
erkennt, dann sieht meines Wissens die Fehlermeldung anders aus
und AVR Studio weigert sich, überhaupt weiter zu machen.  An dieser
Stelle hat es die JTAG-Kontaktaufnahme bereits probiert, aber die
JTAG ID wurde (typischerweise, AVR Studio zeigt das nicht an) als
0xFFFF eingelesen.

von Analog (Gast)


Lesenswert?

Ok. Habs nicht mehr so im Kopf. Wenn das Jtag also solches aber vom 
Studio erkannt wird. Dann bleiben ja nur noch folgende Möglichkeiten 
übrig:

- Leitungen vertauscht
- Irgendeine Leitung fehlt


Meines Wissens werden die JTAG-Clones mit einem 7.38MHz Quarz getaktet. 
Vielleicht ist die Fuse des Mega16 auf dem JTAG auf "interner 
Oszillator" gestellt und es wird vielleicht trotzdem erkannt, wenn auch 
mit der falschen Baudrate. Aber das ist unwahrscheinlich.

von Analog (Gast)


Lesenswert?

Achja vielleicht nochmal mit Ponyprog und ISP mal prüfen, ob die Targets 
JTAGENabled sind.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Analog wrote:

> Meines Wissens werden die JTAG-Clones mit einem 7.38MHz Quarz getaktet.
> Vielleicht ist die Fuse des Mega16 auf dem JTAG auf "interner
> Oszillator" gestellt ...

Dadurch würde lediglich die UART-Kommunikation ausfallen.  Das
JTAG-Target wird aus dem JTAG-Interface getaktet, das stört überhaupt
nicht, wenn das langsamer erfolgt (es dauert halt nur länger).

von Analog (Gast)


Lesenswert?

>Dadurch würde lediglich die UART-Kommunikation ausfallen.  Das
>JTAG-Target wird aus dem JTAG-Interface getaktet, das stört überhaupt
>nicht, wenn das langsamer erfolgt (es dauert halt nur länger).

Ok. Aber das JTAG erhält die Kommandos vom Studio über den Uart oder 
nicht? Damit wäre ja mal klar das es, daran nicht liegen kann. Sonst 
würde das Studio das JTAG ja gar nicht erkennen.

von Bodo.H (Gast)


Lesenswert?

@ Jörg Wunsch
>Bitte Bildformate beachten.

es hätte PNG sein sollen. ok
Ein Oszi habe ich hier. Worauf soll ich achten?

@ analog
>Sieht aber stark danach aus, als ob das Target keinen Power hat.
>Kontrolliere mal, ob GND verbunden ist. Das Pollinboard muss eine
>eingeschaltete Versorgung haben.

Das JTAG ICE bekommt seine Versorgungsspannung über das Target( hier 
Pollinboard) Das sehe ich auch daran, das die Power LED auf dem JTAG ICE 
leuchtet. Es muss auch eine kurzen Datenaustausch geben, da die 2 LED 
für JTAG Aktivitäten dann aus geht.
Das JTAG ICE ist vom Schaltbild her gleich wie das Evertool light.

>So.

>GND
>VCC
>TDI
>TDO
>TMS
>TCLK
>Reset

>>Auch wenn ich den PIN 32 (AREF)des Ziel-Atmega mit VCC verbinde,das
>>gleiche Fehlerbild.

>Also AREF von ATmega auf dem JTAG muss an VCC vom Pollinboard
Habe ich im Schaltbild kontrolliert. Sind miteinander verbunden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bodo.H wrote:

> Ein Oszi habe ich hier. Worauf soll ich achten?

Dass an allen vier JTAG-Leitungen ,,was passiert''.  Dabei werden
TMS, TCK und TDI vom ICE getrieben, TDO wird vom Target getrieben.

von Bodo.H (Gast)


Angehängte Dateien:

Lesenswert?

@ analog

>Achja vielleicht nochmal mit Ponyprog und ISP mal prüfen, ob die Targets
>JTAGENabled sind.

Da habe ich drauf geachtet. Die Probleme mit den Fuse sind mir bekannt.
Im Anhang habe ich das Fusebild des Atmaega 16 auf dem JTAG ICE.

Es ist ein 7.38Mhz Quarz verbaut.

von Bodo.H (Gast)


Lesenswert?

@ Jörg Wunsch
>> Ein Oszi habe ich hier. Worauf soll ich achten?

>Dass an allen vier JTAG-Leitungen ,,was passiert''.  Dabei werden
>TMS, TCK und TDI vom ICE getrieben, TDO wird vom Target getrieben.

Werde ich jetzt prüfen. Dauert aber ein wenig. Melde mich gleich mit 
Ergebnissen.
Frage: Wie kann ich hier zitieren? Ich sehe nur den Antwort-Button.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Wie kann ich hier zitieren?

Das ist eine der wenigen Funktionen, die nur angemeldeten Benutzern
zur Verfügung stehen.

von Bodo.H (Gast)


Lesenswert?

@ Jörg

>>Dass an allen vier JTAG-Leitungen ,,was passiert''.  Dabei werden
>>TMS, TCK und TDI vom ICE getrieben, TDO wird vom Target getrieben.

>Werde ich jetzt prüfen. Dauert aber ein wenig. Melde mich gleich mit
>Ergebnissen.

so ,bin mit dem messen durch. Einen Fehler habe ich gefunden. Ein 10 
pol. Stecker war um 180° falsch gecrimpt. Somit waren die geraden Pin 
2,4,..
mit den ungeraden Pins 1,3,... verbunden.
Das korrigiert. Aber leider bleibt der Fehler.
Auf den Leitungen TMS, TCK und TDI und TDO passiert nichts.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Bodo.H wrote:

> Auf den Leitungen TMS, TCK und TDI und TDO passiert nichts.

Hmm, dein ATmega16 ist aber in Ordnung?

Hier mal das Bild, das ich bekomme, wenn ich einmal durch den
JTAG-Programmierzyklus laufe (ohne was zu programmieren).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jörg Wunsch wrote:

> Hier mal das Bild, das ich bekomme, wenn ich einmal durch den
> JTAG-Programmierzyklus laufe (ohne was zu programmieren).

War schon bisschen spät gestern abend.  Das Bild ist mit einem JTAG
ICE mkII gemacht, aber die grundsätzlichen Signale sollten beim mkI
ja ähnlich sein.  Die Bezeichnungen sind ein wenig abgeschnitten,
ganz oben ist TCK, dann TDO, TMS und schließlich TDI (das ist in
der Reihenfolge am Stecker).

U. U. wirst du mit einem Oszi nicht alle Signale gleichzeitig
aufzeichnen können, aber es sollte dir zumindest möglich sein,
da überhaupt was zu finden.

von Bodo.H (Gast)


Angehängte Dateien:

Lesenswert?

>Bodo.H wrote:

>> Auf den Leitungen TMS, TCK und TDI und TDO passiert nichts.

>Hmm, dein ATmega16 ist aber in Ordnung?

der Gedanke kam mir nach diesem Ergebnis auch. Ich habe vorhin noch 
einmal eine ISP-Verbindung angelötet. Dann konnte ich mit PonyProg die 
Fusebits und das hexfile auslesen. Also werden die obigen Ports duurch 
den verdrehten Stecker nicht gelitten haben.

>Hier mal das Bild, das ich bekomme, wenn ich einmal durch den
>JTAG-Programmierzyklus laufe (ohne was zu programmieren).

Danke für die Mühe. So etwas gab es nicht zu sehen. Die Nullinie hat 
höchsten einmal gezuckt.
Die Ergebnisse deuten auf ein falsches Hexfile hin. Meiner Meinung nach.
Ich habe das Originalfile von  der http://www.uc-projects.com/ Seite 
nicht zum laufen bekommen. Programmiert mit Ponyprog schon ,nur beim 
Update mit AVRStudio zeigte es mir immer ATmega 163 an,den ich ja nicht 
habe.Obwohl es das Atmega16 File sein sollte. Testweise das Atmega163 
file geladen,gleicher Fehler.
Daher habe ich dann hier gesucht und das angehängte File gefunden. 
Programmiert klappt, Update mit AVR Studio klappt auch.

Aber vielleicht passt das File nicht zur Schaltung? Evtl. wird irgendein 
Signal wo erwartet?
Harwaremäßig scheint ja alles ok zu sein. Oder hast du noch eine Idee?
Ich muss jetzt gleich weg, werde aber danach die Signale noch einmal 
prüfen. Vielleicht gestern falsch gemessen. Kontrolle ist besser.
Ach ja, beim Evertool light gibt es einen Brückenstecker, der in dieser 
schaltung fehlt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bodo.H wrote:

> Die Ergebnisse deuten auf ein falsches Hexfile hin.

Das Hexfile lässt du dir ja aber durch deinen Bootloader von Atmel
klauen, d. h. es ist das originale, das auch Atmel für sein (nunmehr
altes) JTAG ICE benutzt hat.

> ...,nur beim
> Update mit AVRStudio zeigte es mir immer ATmega 163 an,den ich ja nicht
> habe.Obwohl es das Atmega16 File sein sollte.

Die Unterschiede zwischen dem ATmega163 und dem ATmega16 sind in
dieser Anwendung hier marginal.  Daher hat ja Atmel auch für all
ihre JTAG ICE mkI nur eine einzige Version der Firmware gehabt.

Wird wohl darauf hinaus laufen, dass dein Bootloader lediglich
den AVR910-Devicecode für einen ATmega163 statt eines ATmega16
vermeldet hat.

> Aber vielleicht passt das File nicht zur Schaltung?

Der Bootloader muss ja nur insofern zur Schaltung passen, dass er
auf dem gewünschten Kommunikationskanal (also der UART) die Daten
entgegen nehmen kann.  Das funktioniert ja ganz offensichtlich.
Mehr entscheidet der Bootloader dann nicht, den Rest macht die
Firmware.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ingrid meint:

> Die Unterschiede zwischen dem ATmega163 und dem ATmega16 sind in
> dieser Anwendung hier marginal.

Ich korrigiere mich: die Programmieralgorithmen für den Bootloader
sind geringfügig verschieden, daher braucht man den zum Controller
passenden Bootloader.  Nur das Firmware-File dann ist das gleiche.

von Analog (Gast)


Lesenswert?

Mal ne doofe Frage : Wer ist Ingrid?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Analog wrote:
> Mal ne doofe Frage : Wer ist Ingrid?

http://de.wikipedia.org/wiki/Ingrid#Sonstiges

von Bodo.H (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Jörg,

ich bin überglücklich :-)). Die Schaltung funktioniert jetzt.
Toll das du mir geholfen hast. So habe ich einen roten Faden gehabt um 
zu suchen. Was habe ich gemacht?

>Die Ergebnisse deuten auf ein falsches Hexfile hin. Meiner Meinung nach.
>Ich habe das Originalfile von  der http://www.uc-projects.com/ Seite
>nicht zum laufen bekommen. Programmiert mit Ponyprog schon ,nur beim
>Update mit AVRStudio zeigte es mir immer ATmega 163 an,den ich ja nicht
>habe.Obwohl es das Atmega16 File sein sollte.
Hier habe ich neu angefangen. Der erste Fehler war ja der verdrehte 
Stecker. Kommt übrigens dadurch, weil ich einen90°Gewinkelten eingesetzt 
habe. Das passt dann aber nur zu 50% mit der Markierung überein, je nach 
Einbaulage. Wieder dazugelernt.
Ich habe noch einmal das Originalfile von der 
http://www.uc-projects.com/ Seite eingelesen und die Atmega163 Anzeige 
unten ignoriert.
Update mit AVR Studio gemacht und klappt auch. Flash wird eingelesen. 
Dann die Fehlermeldung:
Address 0x0000; Expected: 0x940c, Received: 0xffff auch ignoriert.

Danach alles neu gestartet, aber es kamm die Fehlermeldung wie Eingangs 
im diesen Tread. Also beim Zieldevice nachgeschaut und siehe da, JTAGEN 
war nicht programmiert. Habe ich bei meinen vielen Test mal 
geändert.NeuStart von der Schaltung und siehe da ich bin auf der 
Targetschaltung drauf.
Herrlich :-) juhuu...

Ich habe auch die Signale auf den Leitungen erneut gemessen. Aber es ist 
außer einem kurzem Zucken der Nullinie nichts zu erkennen. Verschiedene 
Einstellungen Amplitude/ Time ausprobiert.

Zur Motivation für alle Nachbauer ein Bild des fertig aufgebauten JTAG 
im Gehäuse. Ich hoffe das dieser Tread anderen Nachbauern bei der 
Fehlersuche hilft.
Eine Frage noch zur "C"-Programmierung. Ich finde nur Onlinetexte zum 
Lernen,  worin "C" Programme für den PC als Beispiele und Übungen drin 
sind. Gibt es Bücher oder Onlinetexte wo sich das "C" erlernen speziell 
mit Controllern ,am besten von AVR, erklärt wird?

Noch einmal Danke an alle und besonders Jörg, die sich mit meinen 
Problem befasst haben.
MfG
Bodo

von Pete K. (pete77)


Lesenswert?

Das WinAVR GCC Manual kennst Du ?

Ansonsten sind hier in der Codesammlung sehr viele Bespiele zum Lernen 
:-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bodo.H wrote:

> ich bin überglücklich :-)). Die Schaltung funktioniert jetzt.

Das freut mich.

> Ich habe auch die Signale auf den Leitungen erneut gemessen. Aber es ist
> außer einem kurzem Zucken der Nullinie nichts zu erkennen. Verschiedene
> Einstellungen Amplitude/ Time ausprobiert.

Naja, wenn du ein klassisches Analog-Oszilloskop hast, wird da wohl
in der Tat nicht viel zu sehen zu sein, da die Signale relativ
kurz sind.  Am ehesten wirst du was erkennen können, wenn du auf
TCK triggerst (Flanke wird egal sein), während du beispielsweise
den Flash eines etwas größeren Controllers programmierst.

von Bodo.H (Gast)


Lesenswert?

@ Pete
>Das WinAVR GCC Manual kennst Du ?

>Ansonsten sind hier in der Codesammlung sehr viele Bespiele zum Lernen
>:-)
ja ,ist mir bekannt. Ich habe mir unter anderem auch das 
AVR-GCC-Tutorial auch ausgedruckt. Ja, jetzt heist es üben, üben, üben. 
Mein Prof. hätte damals mehr Bezug auf Controller nehmen sollen. Dann 
hätte ich bestimmt besser aufgepasst. Aber seine geliebte UNIx-Anlage 
war für mich nie ein Anreiz zum "C" lernen. lang ist her. Hätte nicht 
gedacht, das ich damit freiwillig anfange.

@Jörg,

>aja, wenn du ein klassisches Analog-Oszilloskop hast, wird da wohl
>in der Tat nicht viel zu sehen zu sein, da die Signale relativ
>kurz sind.  Am ehesten wirst du was erkennen können, wenn du auf
>TCK triggerst (Flanke wird egal sein), während du beispielsweise
>den Flash eines etwas größeren Controllers programmierst.
Es ist ein altes Oszi von Advance ca. 30 Jahre alt. 2Kanal. Mit Trigger 
auf TCK werde ich mal probieren.
Dein Programm "mfile" habe ich auch schon genutzt. Für einen Anfänger 
wie mich eine feine Sache um mit WINAVR klar zu kommen.

Ichsehe gerade das file ist sehr groß. Ich habe hier eins mit ca 100k. 
Kann man das austauschen? Soll ich es hochladen?

MfG
Bodo

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bodo.H wrote:

> Ichsehe gerade das file ist sehr groß.

Du meinst das Bild?  Ja, hier wäre JPEG natürlich besser gewesen,
ist ja ein Foto...

> Kann man das austauschen?

Geht meines Wissens nicht.  Lass es einfach jetzt, wie es ist.

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
Noch kein Account? Hier anmelden.