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
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.
Gast
#2225773
Wenn es Deine Toolchain unterstützt, könntest Du dem Step-Key ein Macro hinterlegen, welches: - IRQs ausschaltet - Einzelschritt ausführt - IRQs wieder einschaltet
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.
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
@ 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.
Gast
#2232354
falls jemand einen Tipp haben sollte, wie und wo die genannten Befehle eingetragen werden müssen, bitte hier posten.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.