Probleme beim Debuggen (openOCD)

Manu Gast #1624026
Lesenswert?
• ▲
▼ 
Hi,
ich habe ein Problem bei der Nutzung meiner Toolchain.

Ich nutze Eclipse --> Yagarto --> OpenOCD --> als Target LM3S8962.
(arm-elf-gdb)

Das Debuggen klappt soweit auch, nur stoße ich immer wieder auf 
folgendes Problem. Als Initialiesierung Commandos nutze ich:

#############################################
target extended-remote localhost:3333
monitor debug_level 2
monitor reset init
monitor halt
monitor mww 0xE000ED08 0x20000000
# needed for gdb 6.8 and higher
set mem inaccessible-by-default off
set remote hardware-watchpoint-limit 6
set remote hardware-breakpoint-limit 6
load
monitor cortex_m3 maskisr off
thbreak main
thbreak ResetISR
# Set SP and PC
set $sp = *(int*)0x20000000
set $pc = *(int*)0x20000004
monitor debug_level 0
continue
#############################################

So führe ich dies nun aus, kommt zum Schluss der Initialisierung 
folgender Fehler.

#############################################
Program received signal SIGTRAP, Trace/breakpoint trap.
FaultISR () at startup_gcc.c:213
213      }
#############################################

Wenn ich dann den Flashspeicher per LM Flasher lösche kann ich wieder 
ohne Probleme debuggen.

Kann mir hier jemand weiterhelfen?

Grüße Manu
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Manu Gast #1624112
Lesenswert?
• ▲
▼ 
Hi Robert,

ja das vermute ich auch,
ich habe das Debuggen auch mit dem Segger J-Link versucht, dieser 
unterdrückt diesen Interrupt und debuggt ohne Probleme.

Kennt denn jemand ein Commando mit dem der Interrupt auch bei OpenOCD 
unterdrückt werden kann ?
Soweit ich das verstanden habe, soll dies folgender Befehl ausführen
"monitor cortex_m3 maskisr off", doch dies funktionert auch nicht.


Grüße

Manu
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tilo Gast #1625241
Lesenswert?
• ▲
▼ 
Du meinst mit Jegger J-Link, dass du auch deren gdb-Server verwendest?

Du schreibst wenn das Flash leer ist, klappt alles. Meine Vermutung:
Der MCU startet und der Code rennt los. Irgend wann später willst du 
anfangen zu debuggen. Dabei hängt sich etwas auf.

Hast du schon einmal versucht, am Resethandler einen Sprung zum 
Resethandler zu setzen? Nach dem start hängt so der MCU in einer 
Endlosschleife.
Im Skript kannst du dann den PC auf die richtige Adresse des 
Resethandlers setzen und das Programm kontrolliert starten.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Manu Gast #1626133
Lesenswert?
• ▲
▼ 
Hi Tilo,

habs versucht, klappt auch soweit ganz gut. Danke.
Aber durch den Sprung, den ich am Resethandler eingefügt habe, kann 
jetzt die FaultISR() nicht mehr eintreten.
Es klappt zwar, ist aber nicht optimal gelöst finde ich.

Ich habe auch schon versucht, das SIGTRAP Signal abzufangen, und nicht 
mehr zum Programm durch zu lassen ("handle SIGTRAP nostop"), klappt aber 
auch nicht.

Jetzt habe jetzt ein Kommando, dass mir meinen Flash beim laden eines 
neunen Programms wieder löscht, damit klappts auch, ist aber auch keine 
optimale Lösung.


Grüße

Manu
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Manu Gast #1627548
Lesenswert?
• ▲
▼ 
Hi Leute,

falls jdm. mal ein gleiches Problem haben sollte.
Mir fehlte in der Linker Datei folgendes:

    . = ALIGN(4);
  .eh_frame :
  {
      KEEP (*(.eh_frame))
  }  > SRAM

Nun speichert er mir das .eh_frame ins SRAM und nicht mehr ins Flash --> 
kein Interrupt mehr.


Grüße

Manu
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren