www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LPC2124: Probleme mit JTAG-Debugging


Autor: Thomas O. (mondry)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich mache gerade die ersten Schritte mit ARMs, speziell mit dem
LPC2124-Board von Olimex samt Wiggler.
Deshalb habe ich als erstes ein "Hello World" geschrieben, wass die
LED blinken lässt und einen String über das UART verschickt. Kompiliert
wird das ganze mit WinARM. Die Linker-Skripte habe ich vom LPC2129
genommen, weil er die gleiche Memory-Map hat. Flashe ich Programme mit
dem Philips-Tool, dann läuft alles. Starte ich direkt vom RAM (mit
angepasstem Linker-Script um die Bootloadervariablen nicht
überzubügeln) dann geht es auch.

So jetzt zu Problem:
Ich wollte das JTAG-Debugging ausprobieren (schließlich hat man auch
nen Wiggler...). Nehme ich mein kleines Hello-World dann wirds korrekt
ins RAM geladen und auch ausgeführt. Hier mal ein Auszug. Benutzt habe
ich insight-gdb aus dem WinARM-Verzeichnis sowie OCDRemote 2.17:


Remote debugging using localhost:8888
0x7fffe250 in ?? ()
(gdb) load
Loading section .text, size 0x314 lma 0x40000000
Start address 0x40000050, load size 788
Transfer rate: 900 bits/sec, 262 bytes/write.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x400002c8 in uart_send_str (pchar=0x4000030a "") at uart.c:18
18              while (!(U0LSR & (1<<5))); // Warten bis der
Sende-buffer geleert ist
(gdb)


Ich kann dannach steppen. Funktioniert sehr gut.

Wird das Programm aber größer als 1KB (.text-section) (ich habe einfach
nur mal 20 mal hintereinander "Hello-World" ausgeben lassen als
Funktionsaufruf), dann bekomme ich folgendes:


Remote debugging using localhost:8888
0x7fffe254 in ?? ()
(gdb) load
Loading section .text, size 0x3f0 lma 0x40001000
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Start address 0x40001050, load size 1008
Transfer rate: 350 bits/sec, 252 bytes/write.
(gdb)


Dazu die Ausgaben von OCDRemote:


ocdremote 2.17: WIGGLER via LPT 1 at speed : 5
JTAG SDO <-| CPU(1) ARM7TDMI-S : listening on port 8888 |<- JTAG SDI
CPU[1] Accepted gdb connection on port 8888.
Unexpected packet start received (ACK missing?)
Unexpected packet start received (ACK missing?)
Unexpected packet start received (ACK missing?)


continue oder ähnliches geht dann im gdb natürlich nicht mehr. Nehme
ich genaus dieses Programm und lade es mit dem Philips-Tool ins Flash
oder ins Ram, dann läuft es wie erwartet ohne Probleme.

Ich habe mehrere gdb's ausprobiert und es auch mit OpenOCD versucht,
nur das hilft nicht weiter:


Info:    openocd.c:86 main(): Open On-Chip Debugger (2006-06-25 23:00
CEST)
Debug:   jtag.c:1145 jtag_init():
...
...
...
Warning: jtag.c:981 jtag_read_buffer(): value captured during scan
didn't pass the requested check: captured: 0f check_v
alue: 01 check_mask: 0f
Error:   arm7_9_common.c:599 arm7_9_poll(): JTAG queue failed while
reading EmbeddedICE status register

und gdb sagt dann:

...
(gdb) continue
Continuing.
Watchdog has expired.  Target detached.
(gdb)


Damit bin ich mit meinem Latein am Ende...

Hat jemand die gleiche Kombination (Board und Linker) am Laufen und
kann auch JTAG-Debuggen und helfen?
Oder ist da irgend ein komischer Kniff drin? Das mit der 1KB-Grenze
finde ich ja sehr merkwürdig.

Gruß,
Thomas

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne das config File, das du für den OpenOCD benutzt kann ich zwar nur
raten, aber das Problem liegt in dieser Meldung:

Warning: jtag.c:981 jtag_read_buffer(): value captured during scan
didn't pass the requested check: captured: 0f check_value: 01
check_mask: 0f

Ich muss diese Warnung endlich mal in einen Error ändern, da es
eigentlich ein fataler Fehler ist.

Vermutlich hast du in der 'target' Zeile als Reset-Modus
"reset_halt" oder "reset_init" stehen - das ist bei LPCs nicht
moeglic. Statt dessen solltest du "run_and_halt" verwenden. Falls das
dein Problem nicht löst solltest du bitte dein Config File und den
kompletten OpenOCD output (kann man mit -l <filename> in eine Datei
umleiten) hier posten (bzw. an einen Post anhängen).

Gruss,

Dominic

Autor: Thomas O. (mondry)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe den OpenOCD-Output und Konfigurationsdatei in den Anhang
gepackt. "run_and_halt" hatte ich verwendet, weil es so auf den
Webseiten "OpenOCD configuration" so stand. Generell habe ich da aber
nicht alle Kombinationen durchgespielt, sondern mich an die Vorlage aus
dem WinARM-Archiv gehalten.

Das verwendete Programm habe ich nochmals zur Sicherheit per Bootloader
ins RAM geladen -> funktioniert. Die .elf-Datei sollte also in Ordnung
sein. Da es kleiner als 1KB ist, kann ich es ohne Schwierigkeiten mit
OCDremote debuggen.

Hier noch mal das gdb-getippe:


GNU gdb 6.5.50.20060517-cvs
...
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x7fffe254 in ?? ()
(gdb) load
Loading section .text, size 0x388 lma 0x40001000
Start address 0x40001050, load size 904
Transfer rate: 7232 bits/sec, 301 bytes/write.
(gdb) continue
Continuing.
Watchdog has expired.  Target detached.
(gdb)


Ich hoffe das hilft. Ich könnte mir noch die 77'er Version aus dem SVN
laden. Durch das Kompilieren schaff ich das aber nicht so schnell.

Gruss,
Thomas

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich sieht alles gut aus. Ändert der Code vielleicht die Zuordnung
der GPIO Pins, evtl. auch nur für eine kurze Zeit? Oder könnte der Code
einen Watchdog Reset auslösen?

Gruss,

Dominic

Autor: Thomas O. (mondry)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also ich habe alles (PLL, MAM, UART) weggeschmissen. Das Programm sieht
so aus:

int main( void )
{
  IODIR0 |= ( 1<<12 ); // Pin 25 auf Ausgang
  IODIR0 |= ( 1<<13 ); // Pin 26 auf Ausgang
  IOCLR0  = ( 1<<12 ); // Pin 25 auf LOW schalten
  IOSET0  = ( 1<<13 ); // Pin 25 auf HIGH schalten

  while(1) {
    for(volatile int i=0; i<100000; i++);
      IOSET0 = (1<<12);
      IOCLR0 = (1<<13);
    for(volatile int i=0; i<100000; i++);
      IOCLR0 = (1<<12);
      IOSET0 = (1<<13);
  }
  return 0;
}

Einfacher geht es also nicht. Beim "continue" im GDB kommt der selbe
Fehler....

Ich dachte es könnte auch am Linker-Skript liegen (habe einfach eins
aus den Beispielen genommen). Aber die Programme funktionieren per
Bootloader ganz normal. Es wird auch kein Reset ausgelöst (habe ich
noch mit den UART-Ausgaben überprüft) und den Watchdog benutze ich
nicht.

Ich habe keine Idee mehr, was auch daran liegt, dass ich noch nicht
viel mit ARMs gemacht habe. Vielleicht fällt Dir noch was ein, was es
sein könnte; egal ob abstrus oder nicht.

Der JTAG-Adapter schein ja zu funktionieren (zumindest mit OCDremote
bis 1KB), so dass ich nicht denke, dass es ein Hardwareproblem ist.

Mit H-JTAG kann ich auch ein Programm reinflashen, so dass auch wohl
der LPC hardwaremäßig in Ordnung ist.

Deshalb habe ich ja im Forum gefragt, ob jemand diese Kombination im
Einsatz hat, weil das Verhalten so komisch ist. Anscheinend ist das
nicht der Fall. So weiss ich nicht, ob es vielleicht generelle Probleme
gibt bei der Kombination.

Wenn ich noch mehr Infos/Daten liefern soll, die Du gebrauchen kannst
(ich habe erst jetzt mitgekriegt, dass OpenOCD Dein Baby ist), dann
mache ich das gerne. Ansonsten "gebe ich auf" und beschäftige mich
lieber weiter mit der Programmierung, obwohl es mich doch wurmt.

Gruß,
Thomas

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, hatte in deinem Logoutput vollkommen übersehen, dass sich dein
Target im Thumb State befand, als es in den Debug Modus gegangen ist.
Der GDB kümmert sich darum erstmal nicht, so dass der OpenOCD den neu
geladenen Code auch im Thumb State anspringt - das führt zu einer
Undefined Exception, und löst wohl einen (Soft-)Reset aus, so dass der
Philips Bootloader erstmal den JTAG Port deaktiviert, bevor er später
wieder aktiviert wird. OpenOCD pollt das Target in der Zwischenzeit
bereits, und beendet sich, da die JTAG Kommunikation fehlschlägt.

Den aktuellen Core State (so, wie ihn OpenOCD sieht) kannst du mit
"monitor armv4_5 core_state" anzeigen lassen, und mit "monitor
armv4_5 core_state ['arm'|'thumb'] ändern. Um das Problem zu lösen
solltest du also z.B. nach dem load folgenden Befehl ausführen:
monitor armv4_5 core_state arm

Grüsse,

Dominic

Autor: Thomas O. (mondry)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich sage nur eins: Geht!

Also ich glaube nicht, dass ich darauf gekommen wäre, dass es am
Thumb-Mode liegt...

Deshalb vielen Dank für Deine Hilfe!

Gruß,
Thomas

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.