Merkwürdiges STM32 Verhalten

Hilfloser schrieb:
> Die Release Variante zeigt erst gar keine Reaktion.

Ein schöner Bericht den du da verfasst hast. Danke dafür, der
Thread kann jetzt geschlossen werden.

Es sei denn du hättest noch eine Frage dazu.

Optimierung ist aus. Selbst bei einem Minimalbeispiel wie dem folgenden 
kann ich wenn ich pausiere nicht den Chip reseten. Der PC landet dabei 
irgendwo im Nirvana und ich muss die gesamte Debugsession neu starten:

1

Break at address "0x1fff5930" with no debug information available, or outside of program code.

1

int main() {

2

  int x = 0;

3

4

  while (true) {

5

    x++;

6

  }

7

8

  return 0;

9

}

Können sich - warum auch immer - durch das auflöten oder durch einen 
falschen Click die option bytes verändert haben? Wo finde ich deren 
default Einstellung?

Hilfloser schrieb:
> Break at address "0x1fff5930" with no debug information available, or
> outside of program code.

Das ist wohl im Bootloader ... Tja, aber warum der im Booloader landet, 
ist schwer zu sagen. Allein schon deshalb: ST listet z. Z. 1168 
verschiedene STM32-Derivate auf. Und "eine Leiterplatte" ist ja 
wunderbar aussagekräftig. Meine Glaskugel ist im Moment zur Reparatur 
...

neben den oben genannten Tipps zum Optimierungslevel ist in diesem 
Zusammenhang auch wichtig, dass die Option -g verwendet wird, damit die 
Debug Symbole in die *.elf Datei aufgenommen werden. Da du teilweise 
debuggen, hast du diese Option vermutlich gesetzt.

Dann ist es mir relativ oft passiert, dass die IDE die Falsche Version 
(Build versus Release) in den Chip geladen hat. Ich verzichte inzwischen 
auf diese Umschaltmöglichkeit. Wenn ich ein neues Projekt anlege, lösche 
ich immer gleich am Anfang eine dieser beiden Build Konfigurationen und 
benutze in der verbleibenden die Kombination Parameter "-O1 -g".

In dieser Optimierungsstufe lassen sich die Programme noch weitgehend 
gut debuggen und sind für meine Bedürfnisse genügend optimiert. Die 
höheren Optimierungsstufen bringen mir letztendlich keinen zusätzlichen 
Nutzen.

So habe ich auch die Gewissheit, dass ich mein Gerät am Ende mit genau 
der Software betreibe, die ich vorher mit dem Debugger geprüft habe. Auf 
der Arbeit handhaben wir das in Server-Anwendungen ebenso. Auch dort 
unterscheiden wir absichtlich nicht zwischen Debug- und Release- 
Version. Dass dies ein bisschen Performance kostet ist klar, den Luxus 
leisten wir uns.

Auch wenn ich ein neues Projekt anlege und debugge, dieses pausiere und 
neu starte landet der Debugger mit obiger Fehlermeldung im Nirvana.