Ich nutze Eclipse mit dem GCC und den GNU ARM Eclipse Plugins zur Software-Entwicklung für STM32(L151). SWD-Probe ist ein ST-Link V2 vom F4Discovery über openOCD. Jetzt habe ich den DFU Bootloader (HAL Version) von ST für meine Zwecke angepasst, so dass je nach Zustand an einem GPIO-Pin die Applikation oder eben der Bootloader gestartet wird. Vor der Abfrage des Pegels wird der Pin als (langsamer) Eingang mit Pullup konfiguriert. Das Problem ist, dass sich das Programm unterschiedlich verhält, je nachdem ob es aus der Debug- oder Release-Konfiguration geladen wurde. D.h. aus aus der Debug-Konfig wird der Bootloader gestartet, aus der Release-Konfig aber die Applikation, d.h. der Eingangspegel wird quasi invertiert erkannt. Ich habe schon jeweils eine Konfiguration gelöscht und neu als Kopie der vebliebenen erstellt (ohne Änderungen vorzunehmen), das Projekt und den Workspace unzählige Male gecleant, in einen neuen Workspace importiert, das Flash gelöscht, etc. - alles ohne das Problem zu lösen. Wenn ich die Abfrage invertiere (mit !), wird auch jeweils der andere Code geladen, aber Debug-/Release verhalten sich auch dann nicht gleich. Hat jemand eine Idee was die Ursache sein oder wo ich noch suchen könnte?
Micha schrieb: > Hat jemand eine Idee was die Ursache sein oder wo ich noch suchen > könnte? 1. Programmierfehler 2. Debug und Release haben unterschiedliche Projekteinstellugnen 3. Timing Probleme (debug läuft eventuell etwas langsamer) 4. Bug im Optimierer (sehr unwahrscheinlich) Auch ein Release kann man debuggen, wenn auch nur im ASM code.
Micha schrieb: > D.h. aus aus der Debug-Konfig wird der Bootloader gestartet, aus der > Release-Konfig aber die Applikation, d.h. der Eingangspegel wird quasi > invertiert erkannt. Bist du dir da sicher? Wird der Eingangspegel überhaupt betrachtet in Debug bzw Release-Config? Den Satz hier ober beschreibt nur 2 von 4 Möglichkeiten...
Einen Pin einzulesen ist keine triviale Sache. Es dauert einige Zyklen, eh der Pullup an ist, die Pinkapazität sich aufgeladen hat und die CPU den Input gelatcht hat. Z.B. beim AVR ist es grundsätzlich so, daß wenn man einen Pin setzt und direkt danach den Input liest, man noch den vorherigen Zustand im Latch liest. Im Debug sind oft die Optimierungen aus, d.h. der Code braucht länger und dadurch kann ein anderer Wert eingelesen werden.
Ich habe den Code jetzt mal schrittweise in beiden Konfigurationen ausgeführt und dabei den Pegel am Pin beobachtet. Nach der Initilialisierung des Pins liegt dieser wie erwartet auf 3.3V und das Programm läuft wie es soll ab (startet die Applikation) - in beiden Konfigurationen. Es scheint tatsächlich ein Timing-Problem beim Initialisieren des Pins zu sein, denn wenn ich das Programm anschließend ohne Debugger laufen lasse, wird der Bootloader geladen, der Pegel am Pin liegt dann aber ebenfalls bei 3.3V. Als Lösung habe ich die Pin-Init nach vorne verschoben und seither kein Problem mehr gehabt. Ich habe das wirklich an den Konfigs fest gemacht, da es damit reproduzierbar war, auch wenn dies egtl. keinen Sinn gemacht hat, da die Konfigurationen ja identisch waren. Jedenfalls gehe ich davon aus, dass Eclipse die 1:1 kopiert, wobei ich da auch nicht sicher sein kann. An den Einstellungen hatte ich anschließend ja nichts geändert, also gleiche Optimierung, gleicher Debug-Level, gleiche Symbole, etc. Danke euch allen für die Tipps und den Stups in die richtige Richtung!
> Vor der Abfrage des Pegels wird der Pin als (langsamer) Eingang mit
Pullup konfiguriert.
Und vermutlich wird die Hardware für dieses "langsam" einige Takte
Vorlauf brauchen, die der Compiler nur im Debug-Build (optimierungsfrei)
auch abwartet. Ich würde der jetzt laufenden Version zumindest einen
Kommentar anhängen, warum sie überhaupt läuft, d.h. Das diese
(anderweitig genutzt) Wartezeit Pflicht ist.
Bastler schrieb: > Und vermutlich wird die Hardware für dieses "langsam" einige Takte > Vorlauf brauchen, die der Compiler nur im Debug-Build (optimierungsfrei) > auch abwartet. Das ist, wie geschrieben, das seltsame: Debug und Release waren identisch, da eines die Kopie des anderen war und ich nichts geändert hatte. Bastler schrieb: > Ich würde der jetzt laufenden Version zumindest einen > Kommentar anhängen, warum sie überhaupt läuft, d.h. Das diese > (anderweitig genutzt) Wartezeit Pflicht ist. Das mache ich.
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.