Problem beim debuggen auf LPC2387 mit Zylin Plugin

OP #1520161
Lesenswert?

Hallo ich hoff mal wieder auf euch als Hilfe:

Ich nutze Eclipse mit openOCD und Zylin Plugin (GDB Debugger) um mein 
Programm über einen ARM-USB-TINY auf ein LPC2378 Entwicklungsboard zu 
übertragen (beides von Olimex).

Mein Problem ist nun, dass nur jeder zweite Start des Debuggers glückt.
Wenn der Debugger startet, reagiert er auf Breakpoints und ich kann 
beobachten wie sich der Wert von Variablen ändert oder Registerinhalte 
gesetzt werden.

Theoretisch also alles sehr schön aber am Entwicklungsboard tut sich 
nix. Genauer: ich setze Register damit eine LED blinkt und lese einen 
Taster ein -> beides geht nicht mit Debugger.
Dem Zylin Plugin habe ich folgende die Komandos mitgegeben:
1
target remote localhost:3333
2
monitor reset
3
monitor sleep 500
4
monitor poll
5
monitor soft_reset_halt
6
monitor arm7_9 force_hw_bkpts enable
7
monitor flash erase_sector 0 0 0
8
monitor flash write_image Debug\\test1.hex 0x0
9
break main
10
load
11
continue

Übertragen wird mein Test Programm korrekt in den Flash, wenn ich es 
ohne Debugger laufen lasse funktioniert es.
Muss ich fürs debuggen vll. was am Programm ändern? Z.B. im startup-File 
ändern?

vvl. noch hilfreich: ich erhalte die Meldung
1
Warning: arm7_9_common.c:1950 arm7_9_read_memory(): memory read caused data abort (address: 0xffffffff, size: 0x1, count: 0x1)
wenn er mit dem Speicher interagiert.

Hoffe sehr auf euch, da mir kein Fehler auffällt.

LG Steffen
Gast #1521616
Lesenswert?

Klar kann im im Flash debuggen. Allerdings sind dann max. 2 Breakpoints 
möglich.

Ansonsten konnte ich nichts erkennen. Wäre es nicht sinnvoll, den "PC" 
auf Adresse 0x0 zu setzen, bevor das Programm mit "continue" weiter 
ausgeführt wird?

Im Moment machst du folgendes:
Reset -> Programm wird an Adresse 0x0 ausgeführt
Halt -> Das laufende Programm wird irgend wo angehalten
Flash -> Neues Programm wird in den Flash geladen
Continue -> Das neue Programm wird an der Stelle ausgeführt, an der 
vorher das alte Programm beendet wurde.

Füge mal vor dem break:
monitor reg pc 0x0
ein.
OP #1521654
Lesenswert?

Hey erstmal großen dank für die hilfe!!!!

so hab monitor reg pc 0x0 mit reingenommen, denk mal so ist es logisch 
sinnvoller

mein problem hat sich aber nicht verändert, OpenOCD giebt bei jedem step 
denn ich mache die folgendes aus:
1
Warning: arm7_9_common.c:1950 arm7_9_read_memory(): memory read caused data abort (address: 0xffffffff, size: 0x1, count: 0x1)

kann es an der konfiguration von OpenOCD scheitern?
Hab sie auch mal angehangen. als argumente ünergen ich OCD nur:
-f armusbocd_tiny.cfg

find keinen Grund warum sonst mein entwicklungsboard nicht beim debuggen 
reagiert
Angehängte Dateien:
Gast #1521843
Lesenswert?

Das ganze ist nur eine Warning.

Das Problem ist, dass irgend wo in deinem Code steht, dass auf die 
höchst mögliche Adresse zugreifen will. Da dort nichts existiert, 
beschwert sich der MCU und geht in den DAbt Mode. Da wirst du dich 
schrittweise durchkämpfen müssen.
OP #1522481
Lesenswert?

so, hab jetzt geschaut ob ich im code was finde wo er auf die höchste 
adresse zugreifen will...hab bis jetzt nix gefunden. hast du einen 
vorschlag wo ich explitit suchen sollte?

hab grad noch festgestellt, das die erste warnung für eine niedrine 
adresse ausgegeben wird und dann nur noch hohe folgen:
1
Warning: arm7_9_common.c:2120 arm7_9_write_memory(): memory write caused data abort (address: 0x00000000, size: 0x4, count: 0x60)
2
Warning: arm7_9_common.c:1950 arm7_9_read_memory(): memory read caused data abort (address: 0xffffffff, size: 0x1, count: 0x1)

denk das problem liegt beim OpenOCD, oder?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren