ARM Cortex: Debugger springt beim steppen immer in eine ISR in

[S. J. (stj)]

Guten Morgen,
ich programiere zur Zeit mit auf einem LPC1768 µC herum.
Dazu benutze ich Eclipse version 3.6.1, den Arm-None-Eabi-gcc, den 
Olimex ARM-USB-OCD zusammen mit Open OCD Version 0.4.0.

Nun zu meinem Problem:

Wenn ich das Programm debuggen will kann ich vom Start des Programms 
soweit steppen, bis die Interrupts konfiguriert und angeschaltet sind. 
Ab dann lande ich immer, wenn ich auf dem "Step Over" oder den "Step 
Into" Button drücke, in einem Interrupt Handler (meist der I2C). Somit 
muss ich jedesmal, wenn ich durchs Programm steppen will, muss ich 
mühsam per Hand nen Breakpoint auf die nächste Instruktion setzen. Wenn 
ich andere µCs debugge(z.B. At91SAM7) habe ich das Problem nicht.

Vielleicht hat ja hier jemand ne Idee woran das liegen kann, und wie ich 
das abstellen kann.

Grüße,
Stephan

[(prx) A. K. (prx)]

Wenn regelmässige Interrupts da sind, dann schlagen die nätürlich recht 
oft zu. Wenn das stört, dann musst du die betreffenden Interrupts 
deaktivieren. Manche Interrupts lassen sich bei manchen µCs (wie STM32) 
im Trace-Mode auch suspendieren, z.B. damit Timer nicht dauernd 
reinhauen.

[StinkyWinky (Gast)]

Wenn es Deine Toolchain unterstützt, könntest Du dem Step-Key ein Macro 
hinterlegen, welches:

- IRQs ausschaltet
- Einzelschritt ausführt
- IRQs wieder einschaltet

[S. J. (stj)]

Danke für die ersten Antworten

Also wenn ich das richtig verstanden habe müsste der Debugger es genauso 
anstellen, wie ich es momentan mache:
Einen Breakpoint auf die Adresse des nächsten Befehls setzen und warten 
bis der Breakpoint zuschlägt. Somit sollte es doch eigendlich egal sein, 
wie viele Interrupts dazwischen ablaufen.
Und eigendlich möchte ich auch nicht die Interrupts ausschalten. Das 
Programm soll sich beim Debuggen schlieslich genauso verhalten wie 
normal.
Bei anderen µCs hab ich das Problem auch nicht, und da laufen auch immer 
Timer im Milisekunden Takt und diverse andere Sachen, die regelmässig 
Interrupts auslösen.

[Marcus H. (mharnisch)]

S. Janssen schrieb:
> Einen Breakpoint auf die Adresse des nächsten Befehls setzen und warten
> bis der Breakpoint zuschlägt. Somit sollte es doch eigendlich egal sein,
> wie viele Interrupts dazwischen ablaufen.

Nein, single step ist beim Cortex-M3 ein natives debug feature (schöner 
Satz). Es wird dazu kein Breakpoint verschwendet.

> Und eigendlich möchte ich auch nicht die Interrupts ausschalten. Das
> Programm soll sich beim Debuggen schlieslich genauso verhalten wie
> normal.

Tut es ja :-) Es wird die nächste Instruktion ausgeführt...
Du kannst das Verhalten allerdings im DHCSR (Bit 3, C_MASKINTS) 
einstellen.
Siehe ARM ARM v7-M.

Gruß
Marcus

[S. J. (stj)]

@ Marcus
Danke, dein Tip hat mich auf die richtige Spur gebracht

Für die Nachwelt:
Der GDB muss mit

define hook-step
mon cortex_m3 maskisr on
end
define hookpost-step
mon cortex_m3 maskisr off
end

initialisiert werden, dann kümmert der sich darum, das das C_MASKINTS 
richtig gesetzt wird.

[Leidensgenosse (Gast)]

falls jemand einen Tipp haben sollte, wie und wo die genannten Befehle 
eingetragen werden müssen, bitte hier posten.