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.
