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.
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/jtag-intro/jtag-intro.html
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.
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
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
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 ;-)
@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
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_projects/wiggler_intro/index.html
beschrieben.
Wenn "Ende Oktober" ;-) endlich mein ewig im Shop bestellter ARM USB
JTAG Adapter kommt, will ich endlich mal zu OpenOCD umschwenken.
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.
(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_projects/winarmtests/h-jtag_flashing_preliminary.pdf
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
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
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.php4?t=1425&highlight=rdi151).
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 ;-)
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
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
