Rätselhaftes Debugverhalten

[Uwe M. (Gast)]

Guten Tag Freunde der Elektronik!

Ich habe AC6 Eclipse (=STM32 Workbench) unter Linux installiert und 
einen ST-Link V2 USB Stick an meiner Versuchsplatine angeschlossen. Das 
Debuggen klappt teilweise bei dem folgenden Versuchsprogramm:

int main(void)
{
    init_GPIO();
    while(1)
    {
      led_Ax(4,TOGGLE);
      delay(500000);
    }

}

Wenn ich unter Run->Debug mit F6(=Step over) schrittweise debugge, 
klappt das auch gut bis zu led_Ax() Funktion. Danach springt der 
Debugger in die delay() Funktion und führt die Leerschleife schrittweise 
und selbstständig im Sekundentakt mit Ausgaben wie
    Info : halted: PC: 0x080007ca
    Info : halted: PC: 0x0800081a
    Info : halted: PC: 0x0800081c  usw. aus.

Zwar kann ich mit Step return die Funktion verlassen, dennoch kann das 
keine Lösung sein, wenn der Debugger mal einigen  Code abarbeiten soll. 
Kennt jemand die Ursache dieses komischen Verhaltens? Die Debugger 
Sticks laufen unter der IAR Workbench einwandfrei! Wenn ich den 
Debugmodus verlasse, um dann mit Run-> Run das Programm rennen zu 
lassen, passiert nichts, die LED des Sticks zeigt Bereitschaft an. 
Folgende Meldungen erscheinen:

Info : Stlink adapter speed set to 480 kHz
Info : STM32L431CBTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Stlink adapter speed set to 480 kHz
adapter speed: 480 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff3f36 msp: 0x20002c20
Info : Stlink adapter speed set to 4000 kHz
adapter speed: 4000 kHz
** Programming Started **
auto erase enabled
Info : Device id = 0x10016435
Info : STM32L4xx flash size is 128kb, base address is 0x8000000
Info : Erase the padded zone before the write
Error: Whole bank access must start at beginning of bank.
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000050 msp: 0x20002c20
Warn : block write succeeded
wrote 4096 bytes from file Debug/test.elf in 0.179850s (22.241 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002c20
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002c20
verified 3000 bytes in 0.179012s (16.366 KiB/s)
** Verified OK **
** Resetting Target **
Info : Stlink adapter speed set to 480 kHz
adapter speed: 480 kHz
shutdown command invoked

Seltsam ist der pc: 0x20000050, da die CPU im 0x8000000 Flash-Bereich 
rennen müsste und nicht im Ram.

Ist vielleicht der GNU Debug nicht richtig konfiguriert, was schon beim 
Atollic Studio ein erfolgloses Abenteuer war? Hier meine Settings:

Debug Configuration->Debugger:

GDB Command: ${openstm32_compiler_path}/arm-none-eabi-gdb
Open OCD Command: ${openstm32_openocd_path}/openocd"
Port number: 3333. Software System Reset, SWD, 4 MHz,
Enable debug in low power mode und Stop watchdog counters when halt 
beide enabled.

 Die Run Configuration->Debugger haben die gleichen Einstellungen.

Wo liegt der Fehler?
Vielen Dank voraus,

Uwe

[PittyJ (Gast)]

Warum muss man so ein Programm debuggen?

Kann man das delay nicht zum Debuggen weglassen. z.B. mit
#ifdef DEBUG

[Teo D. (teoderix)]

Uwe M. schrieb:
> Versuchsprogramm:

== zB. und eine gesunde Neugier!

Ich kenne die IDE zwar nicht aber ich würd mal tippen, Funktion vs 
Makro.

[Uwe M. (Gast)]

Nein, es gibt keine Makros, die hasse ich (Speicherplatzverschwendung, 
schwere Lesbarkeit des Codes), und mit Weglassen von Problemen kommt man 
nicht weiter! Hier geht es auch nicht um Satire!!!

[Stefan F. (Gast)]

Der Debugger tut sich mit optimiertem Code schwer. Ändere mal die 
Optimierung auf -O0 oder -Og

[Uwe M. (Gast)]

Danke Stefanus, aber der Compiler ist schon defaultmäßig auf O0 
eingestellt. Klar ist mir bekannt, daß optimierter Code den Debugger 
scheinbar quer durch C-Quellcode springen läßt, aber leider ist das 
nicht die Lösung. Ich werde mich allerdings nochmals mit der Schaltung 
beschäftigen, denn bisher lief Code über den IAR nur über Debugger, aber 
selten ohne. Dabei dachte ich, es ist eine weitere Beschränkung der 
kostenfreien Version des IAR. Dabei ist der Resetpin mit 0.1 uF 
verbunden gegen GND.

[Andreas H. (ahz)]

Uwe M. schrieb:
> Wo liegt der Fehler?

Rechts oben.

Hilft das weiter?

Falls nicht dann könntest Du uns ja mal das asm listing von main() 
zeigen (für faule Menschen wie mich am besten mit src lines included).
Ansonsten sind vermutlich alle nur am rumraten :)

Grüße
Andreas

[Uwe M. (Gast)]

Hallo Andreas, du Nachtwandler!

Anbei im Anhang der Assemblercode. Diesen nicht optimierten grauenhaften
Assemblercode bitte ich zu entschuldigen, da Optimierungsstufe 0! Der
Code ist jedenfalls nicht schuld am merkwürdigen Debugverhalten.
Einstellungssache am GDB?
Gruß

Uwe

[Uwe M. (Gast)]

Zusatz: Wenn der Mode auf Stufe O1 optimiert ist, und mache Step over
ab der LED_Ax() Funktion, rennt das Programm los und die LED blinkt 
fröhlich. Lediglich im Instruction Stepping Mode werden brav 
Assemblerzeile für Zeile brav abgearbeitet mit jedem F6 Befehl (=Step 
over). Kurzum: Wirres Debugverhalten!

[Uwe M. (Gast)]

Zusatz 2: Wenn ich im Menu Run den Punkt Run wähle, gibt der Debugger 
die Meldung "shutdown command invoked" aus, folglich passiert nichts, 
die LED des Debuggdr Sticks leuchtet blau, flackert nicht mehr. Haben 
diese ST-Link V2 Sticks vielleicht Kompatibilitätsprobleme, denn für 
2,58 € das Stück sind es natürlich Nachbauten aus China, wobei diese 
unter IAR Workbench perfekt liefen?

[Vincent H. (vinci)]

Häng mal ein

asm volatile("nop");

ganz unten in die Schleife rein. "Step over" über einen Funktionsaufruf 
dessen Rücksprung direkt auf einem Branch landet... das klingt nach 
einer etwas prekären Situation.

Ansonsten kann man noch als Tip mitgeben, dass man über Aufrufe die 
viele Taktzyklen in Anspruchen nehmen schlichtweg nicht steppen sollte. 
Step ist eine viel teurere Operation als was der Anschein vermuten 
lässt...

[Uwe M. (Gast)]

Hallo Vincent!

Dein eingefügter nop Befehl als auch eine kurze delay(1) Funktion 
verändern nichts. Daß Sprünge über zeitlich lange Funktionen kritisch 
sind, habe ich bisher weder gehört noch erlebt. Bei meinem total 
unkomplizierten Atmel Studio waren auch Sprünge über 4s delays() null 
problemo. Ich wechsle morgen mal den Chip, denn daß das Programm ohne 
Debugger nicht laufen will, auch nicht mit Debugger und Run riecht mir 
sehr nach einem Hardwareproblem.

[Johannes S. (Gast)]

Liegt led_Ax hinter main()? Ist dann auch eine forward Deklaration 
vorhanden?

[Uwe M. (Gast)]

Johannes S. schrieb:
> Liegt led_Ax hinter main()? Ist dann auch eine forward Deklaration
> vorhanden?

void led_Ax(uint8_t number, uint8_t state) wurde in global.h als 
Prototyp vorgestellt, und diese Headerdatei wird in main() eingebunden.

[Johannes S. (Gast)]

Das meinte ich, also auch richtig.
Mit Eclipse arbeite ich schon lange, gerade das Debuggen funktioniert 
damit eigentlich sehr gut. Mit VSCode wächst aber gerade sehr rasant 
eine Alternative heran. Ist vieles anders und einfacher, hat aber viel 
Potential finde ich. Mit Cortex-debug gibt es eine Extension die OOCD, 
BMP und JLink als Debugprobe bedienen kann. Benutzt aber auch den gdb 
und wenn das Problem aus dem Code kommt wird es sich ähnlich verhalten.

[Uwe M. (Gast)]

Mit den Startschwierigkeiten ohne Debugger hat sich erledigt dank 
Birgits Nachbarthread zum Thema Pin Boot 0 nicht belegt. Das merkwürdige 
Debugverhalten bei der Pausenfunktion bleibt aber.

[Uwe M. (Gast)]

Guten Morgen Freunde der Elektronik!

Ich konnte das Problem lösen. Bekanntlich fing der Debugger immer an, in 
die delay() Funktion reinzugehen trotz Step over command. Das main.c 
File fing wie folgt an, s.u.. In der ersten Zeile bei der Deklaration 
der globalen Variable stand ein unscheinbarer Breakpoint, vielleicht ein 
Überbleibsel aus der Vergangenheit, was wenig Sinn macht. So hat der 
Debugger dann den Breakpoint in die Delay Funktion verschoben ohne es 
anzuzeigen, so daß man sich nicht wundern braucht.
Ich danke Euch für Eure Hilfe!
Noch einen schönen Sonntag,

Uwe


uint32_t errors;
//********************************************************************** 
****
void delay(uint32_t ms)
{
   //some code here
}