CubeIDE doesn't step into ISR

Bonusfrage: Wenn ich den Systick deaktiviere, crasht das System bei 
Verwendung von HAL_PWR_EnterSLEEPMode(PWR_MAINREGULATOR_ON, 
PWR_SLEEPENTRY_WFI);
Obwohl ich eigentlich keine Funktionen benutze, die den Systick 
benötigen (z.B. delay oder timeout bei blockierenden Funktionen).

Diese beiden Punkte haben mich in den letzten Tagen locker 5-6 Stunden 
gekostet. Ich konnte es zwar herausfinden, aber weiß nicht warum es so 
ist...

>Bonusfrage: Wenn ich den Systick deaktiviere, crasht das System bei
>Verwendung von HAL_PWR_EnterSLEEPMode(PWR_MAINREGULATOR_ON,
>PWR_SLEEPENTRY_WFI);
>Obwohl ich eigentlich keine Funktionen benutze, die den Systick
>benötigen (z.B. delay oder timeout bei blockierenden Funktionen).

Benutzt nicht die HAL den SysTick....

Nun ja... schrieb:
> Aber warum lande ich nicht automatisch beim Steppen in der ISR???

Hast du "ISR" schon einmal ausführlich ausgesprochen, also 
"Interrupt-Service-Routine"?

Dabei würde dir klar werden, daß die nur dadurch ausgeführt wird, daß 
eine besondere Schaltung in deinem Chip den gewöhnlichen Lauf der 
Abarbeitung unterbricht und die CPU auf die ISR umlenkt. Das ist also 
jedesmal außer der Reihe und nicht von dir oder deinem Debugger planbar. 
Deshalb eben.

W.S.

Nun ja... schrieb:
> Sie wird auch angesprungen, funktioniert also.
> Aber warum lande ich nicht automatisch beim Steppen in der ISR???

Moin,

weil eventuell im Single-Stepping automatisch bestimmte Interrupts 
deaktiviert werden, damit man z.B. nach ein paar Steps keine drölfzig 
Timer-Interrupts anstehen hat? ;-)

Stichwort: C_MASKINTS
https://developer.arm.com/documentation/ddi0337/e/CEGCJAHJ

Um welchen Interrupt geht es denn und welcher Arm Cortex-M wird 
verwendet?

Gruß,
Michael

W.S. schrieb:
> Nun ja... schrieb:
>> Aber warum lande ich nicht automatisch beim Steppen in der ISR???
>
> Hast du "ISR" schon einmal ausführlich ausgesprochen, also
> "Interrupt-Service-Routine"?
>
> Dabei würde dir klar werden, daß die nur dadurch ausgeführt wird, daß
> eine besondere Schaltung in deinem Chip den gewöhnlichen Lauf der
> Abarbeitung unterbricht und die CPU auf die ISR umlenkt. Das ist also
> jedesmal außer der Reihe und nicht von dir oder deinem Debugger planbar.

Das war mir grundsätzlich klar. Aber wohl nicht klar genug. Die ISR wird 
aus Sicht des Debuggers zu einem nicht vorhersehbaren Zeitpunkt von der 
Zielhardware ausgeführt. Ja. Aber ich dachte bisher, daß der ganze 
"Debug-Prozeß" (also Kombi aus Debug-Hard- und Software) quasi Takt für 
Takt  bzw. mindestens Befehl für Befehl abarbeitet. Aber da liegt wohl 
der Hund begraben: Der Zeitpunkt ist a.) nicht vorhersehbar und wird b.) 
von der Zielhardware ausgeführt. Ist also schon zu Ende, bevor das 
"Debug-System" es überhaupt merken kann. Aber dann frage ich mich, warum 
das Setzen eines Breakpoints in der ISR den Prozeß dort anhalten kann.
Nun gut, da habe ich dann ja etwas, wo ich mich noch ausführlich 
beschäftigen muß. Ist ja nicht ganz unwichtig.

Michael F. schrieb:
> Stichwort: C_MASKINTS
> https://developer.arm.com/documentation/ddi0337/e/CEGCJAHJ

Da habe ich ja noch nie was von gehört. Muß ich mal in Ruhe lesen.
Es ist übrigens ein Original BluePill. Und den Timer halte ich mit

1

#ifdef DEBUG

2

#include "stm32f1xx_hal.h"

3

    __HAL_DBGMCU_FREEZE_TIM2();

4

#endif

während des Steppen an. Aber ist offensichtlich nur ein kleiner Teil, 
wenn man vernünftig debuggen will.
Besten Dank Euch beiden.