Probleme beim Debuggen (openOCD)

[Manu (Gast)]

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

[R. F. (rfr)]

Riecht nach einem Problem im Interruptbereich.
Gruss
Robert

[Manu (Gast)]

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

[R. F. (rfr)]

In Zeile 213 des gccstartscriptes steht sicher irgendwas, was hilft. 
Oder scshreibe doch< einfach eine ISR.
Gruss
R.

[Tilo (Gast)]

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.

[Manu (Gast)]

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

[Manu (Gast)]

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