mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik JTAG-Port von LPC2292 funktioniert nicht ?


Autor: mmvisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Bei meinem LPC2292 funktioniert der JTAG Port nicht.

Ich habe folgendes getestet:
- Bei Reset P1.26 auf LOW  >> CPU aktiviert JTAG
- PINSEL2 |= 0x04 >> CPU aktiviert JTAG

Also "CPU aktiviert JTAG" erkenne ich daran dass der Ausgang P1.26 
(TRCK) vom Status TriState auf High wechselt. Wenn ich diese beiden 
Optionen nicht setze, dann bleibt P1.26 auf TriState.

Doch warum wechselt der Ausgang P1.27 (TDO) nicht auf Ausgang?
Der bleibt auf TriState.

Wenn ich folgendes einprogrammiere:
IODIR1 |= (1<<27);  // define P1.27 as Out
while (1)
{
  IOCLR1=(1<<27);    // set all outputs in mask to 0
  delay();
  IOSET1=(1<<27);    // set all outputs in mask to 1
  delay();
}
Dann sollte der Ausgang eigentlich blinken?
Tut er aber nicht, bei P1.28 klappts.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei JTAG so wie ich es verstehen, kannst du TDO nicht willkürlich in 
dieser Weise manipulieren. Ob was und was an TDO erscheint, ist von TDI, 
über TMS vom dem TAP Controller im µC und der TCK abhängig.

http://www.inaccessnetworks.com/projects/ianjtag/j...

Oftmals sind Portpins an µC einer von mehreren exklusiven Funktionen 
zugeordnet. Wenn du TDO nicht brauchst sondern stattdessen den P1.27 
Output-Port (GPIO), musst du das Test/Debug-Interface abschalten.

Autor: MmVisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Andtwort!

Ich vermute, dass der Pin P1.27 defekt ist.

Wenn der PINSEL2 nicht aktiv ist dann ist JTAG auch nicht aktiv und ich 
müsste also den Ausgang blinken lassen können.
Der Ausgang JTAG P1.26 ist ja auch hochohmig, der wird HI wenn ich JTAG 
aktiviere.

MfG MM

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist durchaus in Ordnung, wenn TDO High-Z ist, während keine Daten 
geshifted werden, also der TAP weder in Shift-DR noch in Shift-IR ist.
Da du den Pin aber scheinbar auch nicht als GPIO verwenden kannst, 
liegst du mit deinem vermuteten Defekt aber wohl richtig.

Gruss,

Dominic

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was willst du machen?

P1.27 als GPIO nutzen wie in deinem Codeschnippsel?

Dann würde ich entweder den Debugport definiert per Software abschalten 
(Bit2 von PINSEL2 auf 0 setzen) oder gleiches per Hardware machen, d.h. 
P1.26 über einen Pullup-Widerstand auf HIGH legen (setzt bei Reset 
ebenfalls Bit2 von PINSEL2 auf 0 ==> Debugport = AUS).

Den Debugport nutzen?

Dann würde ich meinen JTAG-Adapter an den Port anschliessen und dafür 
sorgen, dass der bei Reset den P1.26 auf LOW zieht und dadurch PINSEL2 
Bit2 auf 1 geht, d.h. Debugport aktiv. Und dann muss aber die Debug/JTAG 
Software vom Host aus entsprechend den TAP-Controller bedienen. TDO 
(ex-P1.27) ist dann nicht mehr unter deiner Programmkontrolle.

Ich bevorzuge dabei die Hardware-Lösungen und ich würde ggf. einen 
Jumper P1.26 => Vcc/GND einbauen, bevor ich mir per Endlosläufer 
softwaremäßig den JTAG-Ast absäge ;-)

Autor: mmvisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dominic:
Ich habe mit einem Oszi TCK und TDO aufgezeichnet. Clk kommt und TDO 
bleibt still.

@Stefan:
ich möchte den Port schon gerne zum Debuggen nutzen. Dazu habe ich einen 
4K7 Widerstand von P1.26 zu GND gelegt (wie im UM beschrieben).
Ich habe mir ein JTAG Wiggler aufgebaut und wollte ihn mit der H-Jtag 
Software die bei WinARM mit dabei ist nutzen.
Ich habe noch nie ein JTAG Interface benutzt daher habe ich keine 
Erfahrung.

Daher die Frage: Kann es eventuell sein dass H-Jtag nicht mit dem 
LPC2292 zusammen spielen will?

Gruß Markus

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H-Jtag und Wiggler habe ich nie zum Laufen bekommen, bzw. ich habe 
keinen Debugger gefunden, den ich an H-Jtag anklinken konnte.

Ich verwende mit meinem Selbstbau-Wiggler das OcdRemote aus dem Gnu 
Tools  (HWSupport) Paket von Macraigor. Als Debugger nehme ich Insight 
aus dem GnuARM Paket. Alles läuft unter Windows98SE mit Cygwin.

Im Prinzip ist das so wie von Martin Thomas auf 
http://gandalf.arubi.uni-kl.de/avr_projects/arm_pr... 
beschrieben.

Wenn "Ende Oktober" ;-) endlich mein ewig im Shop bestellter ARM USB 
JTAG Adapter kommt, will ich endlich mal zu OpenOCD umschwenken.

Autor: mmvisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe versucht diese Konfiguration zum laufen zu bringen, aber leider 
bisher ohne Erfolg.

Also ich möchte damit nicht so viel Zeit verlieren und habe daher 
folgende Frage:

Konnte sich der H-Jtag mit dem AMR Prozessor überhaupt verbinden ?

Dass sich ein Debugger nicht ordentlich mit dem H-Jtag zusammen spielen 
möchte ist eine andere Sache. Bisher ist mir noch nicht klar ob der TDO 
Pin überhaupt funktioniert.

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Seltsam, hatte gestern einen relativ langen Beitrag fuer diesen Thread 
eingetippt, aber wohl "absenden" vergessen. Nochmal in Kurzform:)

Habe H-JTAG erfolgreich getestet. Hardware: LPC2138 auf MCB2130 
eval.-board, Wiggler-Clone von Olimex. Habe es zum Flash-Programmieren 
mittels Keil uVision genutzt. Programmeinstellungen fuer Reset mussten 
etwas angepasst werden. 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

H-JTAG bietet ein RDI-Interface. Viele kommerzielle 
Entwicklungswerkzeuge koennen mit RDI-Debuggern umgehen (z.B. IAR EW, 
Keil uVision/MDK-ARM). Irgendwo auf arm.com gibt es sogar eine kleine 
Anleitung fuer "uVision+H-JTAG+Wiggler"-debuggen. Einen gdb-Server 
bietet es meines Wissens nicht. Dafuer bietet sich OpenOCD an (zur Not 
ocdremote).

Es gibt seit ein paar Tagen auch einen neue Version von H-JTAG (selbst 
bisher nicht ausprobiert).
http://twentyone.bokee.com/inc/20061015.wma (in rar umbenennen)

Falls in H-JTAG alles richtig eingestellt ist (SRST/TRST) und alle JTAG- 
und Reset-Leitungen am Controller richtig angeschlossen sind, ist das 
Problem am ehesten im Selbstbau-Wiggler zu suchen. Habe bisher keinen 
Wiggler-Clone selbst gebaut aber einer nach dem Schaltplan des 
H-JTAG-Entwicklers wird wohl auch mit H-JTAG funktionieren: 
http://twentyone.bokee.com/inc/WIGGLER2.rar

Auch auf Printer-Port Mode-Einstellung im BIOS achten.

Martin Thomas



Autor: mmvisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für Ihre zusätzlichen Hinweise.

Da ich den Pin P1.27 (TDO-Pin) als GPIO Ausgang programmiert habe und 
der Ausgang dann nicht funktionierte gehe ich von einem Defekt des Chips 
aus. Auf jeden Fall habe ich gestern bei Farnell einen neunen LPC2292 
gekauft, der heute ankommen wird. Dann baue ich eine zweite Platine auf, 
damit habe ich in jedem Fall eine Refferenz habe und den Fehler weiter 
eingrenzen kann.
Bei der Nutzung von H-JTAG kann man eigentlich nichts falsch machen, der 
stellt sich automatich ein, dann Verbinden und es sollte schon eine 
OK-Meldung erscheinen?

Die Keil Tools nutze ich nicht.

Ich habe WinArm installiert. Mit dem "Programmer's Notepad" kann man 
wirklich klasse Programmieren der ist fast wie eine IDE. Den aktuellen 
H-JTAG habe ich bereits geladen, mit dem gleichen Ergebnis.

Der "JLinkGDBServer.exe" sagt mir auch beim Debuggen mit Insight 
"arm-elf-insight.exe" dass er keine Kommunikation herstellen kann.

In jedem Fall muss der LPC2292 auf dem TDO Pin antworten, denn JTAG ist 
definitiv aktiv und TCLK und TDI kommen Clock und Daten an. Im Wiggler 
Schaltplan vom H-Jtag ist der Anschluss TRST nicht benutzt, nur SRST. 
Daher habe ich den auch nicht verdrahtet. Braucht es den Pin bei H-JTAG 
?

Im Atachment ein Foto der CPU-Platine und meines JTAG-Adaptern, der 
nicht nur JTAG sondern auch TTL/V24 Wandler für den Programmieranschluss 
und USB hat. Die CPU Platine hat 1MB RAM, 2MB Dataflash, USB2.0 HiSpeed, 
1,8V Versorgung und 50-Poliger Port-Stecker. Da die Platine so super 
klein (und 4-Lagig) ist, muss der JTAG-Anschluss im Raster von 1,27mm 
klein sein. (Leider gibt es für diese grösse ein Flachbandkabel-Stecker 
mit 16 oder 18 Polen.)

Gruß Markus

Autor: mmvisual (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Bild...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja warten wir mal ab.

Das Debuggen über JTAG ist ja ein Mix aus mehreren Komponenten.

Von der Hardwareseite her kommunizieren Host (PC) und Target (µC) über 
ein Zwischenhardware, das sog. JTAG-Device. Die Anbindung des 
JTAG-Devices zum Host kann über den Parallelport (Wiggler) oder über 
serielle Schnittstellen (USB JTAG for ARM...) laufen. Weitere wichtige 
Leitungen sind die Spannungsversorgung und eine Resetleitung, um vom 
Host aus den µC unter JTAG Kontrolle zu zwingen.

Die Software zum Debuggen besteht ebenfalls aus mehreren Komponenten.

Einmal natürlich der bereits vorhandene TAP-Controller in dem µC. Dieses 
"Programm" (state machine) wird über eine Clock und Eingabeleitungen 
über die JTAG Schnittstelle gefüttert und gibt dort auch wieder 
Meldungen zurück. Dann auf der PC Seite natürlich der Debugger, der für 
Targetarchitektur angepasst ist.

Dazwischen befindet sich eine weitere essentielle Software: der 
Debugger-Server. Dessen Aufgabe ist es die Kommandos (RESET, START, 
STOP...) des Debuggers sowie das zu debuggende Programm über das 
JTAG-Device in Signale auf der JTAG-Schnittstelle umzusetzen und dem µC 
zu übergeben. Und eine weitere Aufgabe ist es, Signale auf der 
JTAG-Schnittstelle in Datenform (Speicherinhalte, Registerinhalte) 
zurück an den Debugger zu liefern. Für die geregelte Kommunikation 
zwischen Debugger und Debugger-Server gibt es mehrere Protokolle.

Für ein funktionierendes System sind also notwendig:

1/ Debugger (kann Debugger-Server enthalten)
2/ Debugger-Server (kann teilweise im intelligenten JTAG-Device stecken)
3/ Debugger und Debugger-Server haben ein gemeinsames Protokoll
4/ JTAG-Device
5/ Debugger-Server kommt mit dem JTAG-Device klar
6/ Der Debugger-Server kommt mit dem µC klar (Speicherlayout...)
7/ JTAG-Device kommt mit dem µC klar. Spannungsversorgung und 
Resetleitung(en) "passen". Und Debugger-Server kennt die Leitungen 
(Konfiguration)

In deinem Fall von Debugger=GDB/Insight und Debugger-Server=H-JTAG sehe 
ich Probleme mit dem Punkt 3. H-JTAG unterstützt das RDI Protokoll und 
GDB unterstützt das nicht.

In deinem Fall von Debugger-Server=Jlink-GDBServer und 
JTAG-Hardware=Wiggler sehe ich Probleme mit dem Punkt 5, allein schon 
wg. der Hardware. JLink ist ein USB JTAG-Device von Segger 
(http://www.segger.com/hardware.html) und ein Wiggler wird am 
Parallelport angeschlossen.

Problematisch könnte eine generelle Inkompatibilität von H-JTAG mit 
LPC2xxx µC (auf Olimex-Boards?) sein 
(http://www.at91.com/www/phpBB2_mirror/viewtopic.ph...). 
Ist allerdings nur ein Bericht. Du solltest die LPC Gruppe auf Yahoo 
scannen, ob das dort bestätigt wird.

Und zum Schluss: Wiggler ist nicht gleich Wiggler. Als ich, als blutiger 
Anfänger, meinen aufgebaut habe, habe ich soviele verschiedene Designs 
gefunden, dass mir der Kopf geraucht hat. Ein Wunder, dass das Ding 
jetzt so gut funktioniert ;-)

Autor: mmvisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der neue Chip funktioniert ! Der Alte war tatsächlich defekt.

Ich kann jetzt mit dem Programm H-JTAG eine Verbindung mit dem Prozessor 
herstellen.

Das Programm OCDRemote.exe erkennt auch den Wiggler und kann mit dem 
LPC2292 kommunizieren.
Ich habe den mit folgenden Parametern gestartet:
"ocdremote.exe -c ARM7TDMI-S -p 8888 -d WIGGLER -a 1 -s 4"
Damit kann er in jedem Fall die Verbindung mit meinem JTAG-Adaper 
herstellen.

Nun zu meinem nächsten Problem:
Das Tool "arm-elf-insight.exe" kann sich über den Port 8888 auf 
localhost mit dem "OCDRemote" verbinden.
Immer wenn ich das Projekt debugen möchte und Break-Points setze dann 
meldet OCDRemote "SW Breakpoint at 0x190: unable to write breakpoint: 
Target Bus Error"

Das Tool "arm-elf-insight.exe" würde ich schon gerne benutzen, aber 
warum spielt es nicht so richtig mit dem OCDRemote zusammen?
Und warum hät die CPU an einem Punkt an, an dem gar kein Breakpoint ist?
Warum macht der einen SW Breakpoint un keinen HW Breakpoint, ich nutze 
doch blos zwei?

Oder muss ich ganz andere Programme benutzen?
(Ich nutze WinXP)

Gruß Markus

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gegen defekte Hardware hat man keine Chance. Gut dass du einen Ersatz 
gefunden hast. Aber wirf den ersten µC noch nicht weg, probiere noch das 
aus:
http://www.embeddedrelated.com/groups/lpc2000/show/4015.php

Autor: mmvisual (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieser Sondertrick funktioniert leider nicht.

Kann es sein dass der Insight Debugger nur debuggen kann wenn ein 
Programm im RAM läuft ?

Gruß Markus

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn dein Code im Flash liegt, musst du ocdremote erst sagen, dass es 
immer hardware breakpoints verwenden soll, auch wenn ein SW bkpt 
angefordert wurde. Das genaue Kommando kenne ich leider auch nicht, aber 
"monitor help" (im GDB Window) sollte eine Liste der verfügbaren 
Kommandos ausgeben.

Gruss,

Dominic

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.