Hallo, nachdem ich von einem Projekt wieder eine Leiterplatte bestückt habe und nachdem ich mein STM32CubeStudio auf die neueste Version aktualisiert habe zeigt sich ein komisches Verhalten. Im Debug kann sporadisch ein beliebiger Breakpoint nicht angesprungen werden. Wird pausiert wird überwiegend folgendes angezeigt: Break at address "[...]" with no debug information available, or outside of program code. Manchmal hält der Debugger jedoch tatsächlich an einer Stelle. Ein Reset des Controllers ist grundsätzlich nicht möglich, es muss immer komplett neu verbunden werden. Wenn ich step by step debugge bleibt der Controller an einer beliebigen Codestelle hängen mit obigem Fehler. Irgendwie habe ich das Gefühl, dass die neue Version vom Studio mir einen reinwürgt. Wie so oft schließe ich aus, dass der Controller einen Fehler hat. Der Programmcode ist unverändert und lief bei vorherigen Exemplaren, von denen ich leider keines hier habe. Es ist ein frisch zusammengelötetes Exemplar, welches bisher nur mit RUN/Debug programmiert wurde. Die Release Variante zeigt erst gar keine Reaktion.
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.
Schau mal nach, was für Optimierungsflags verwendet werden. Findet sich unter Projekt -> Properties -> C/C++ Build -> Settings -> (GCC oder G++ compiler) -> Optimization Wenn das dort auf -Og steht, probier es mal mit -O0 aus. -Og führt im Gegensatz zu O0 schon Optimierungen durch, versucht aber noch gut debuggbar zu sein, aber teilweise werden trotzdem Sachen optimiert und der resultierende Code stimmt nicht gut mit dem C Code überein.
Optimierungen abschalten. Der Kompiler hat die Zeile/den Code wegoptimiert.
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.
Hilfloser schrieb: > Break at address "0x1fff5930" with no debug information available, or > outside of program code. Ich hatte letztens ein ähnliches Problem. Die Ursache war, dass ich versehentlich den BOOT0 Pin offen gelassen hatte. Wenn ich auf der gleichen Platine den BOOT0 Pin mit einem dünnen Draht fix an GND verbunden habe, hat es funktioniert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.