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
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
Dieser Sondertrick funktioniert leider nicht. Kann es sein dass der Insight Debugger nur debuggen kann wenn ein Programm im RAM läuft ? 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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.