STM32F4 Discovery Startprobleme

[Martin (Gast)]

Hallo zusammen,

(CoIDE 1.7.5, gcc 4.7 2013q3 und 4.6 2012q4)
mit meinem frisch gekauften STM32F4 Discovery habe ich das Problem, dass 
manche Programme zwar nach Starten im Debugger laufen, nach Ab- und 
wieder anstecken ans USB-Kabel aber nicht loslaufen. Ich habe schon 
alles mögliche probiert, die gcc-Optimierung scheint einen Einfluss zu 
haben (manche Programme laufen mit -o0 los, manche mit -o3)...

Das Minimalst-Programm, dass zuverlässig nicht startet (übrigens hilft 
auch der Reset-Taster nicht), schaltet die LEDs des Boards ein:

#include "stm32f4xx.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"

int main(void)
{
  GPIO_InitTypeDef GPIO_InitStructure;
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12 |GPIO_Pin_13 |GPIO_Pin_14 
|GPIO_Pin_15;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOD, &GPIO_InitStructure);

  GPIO_SetBits(GPIOD, GPIO_Pin_12);
  GPIO_SetBits(GPIOD, GPIO_Pin_13);
  GPIO_ResetBits(GPIOD, GPIO_Pin_14);
  GPIO_ResetBits(GPIOD, GPIO_Pin_15);

    while(1)
    {
  GPIO_ToggleBits(GPIOD,GPIO_Pin_15);
    }
}

Aus dem Debugger läufts, nach Anstöpseln nicht... SysInit() fehlt 
übrigens, das wird vom Startup (startup_stm32f4xx.c in 
cmsis_boot/startup) nicht aufgerufen, aber zum die LEDs einschalten 
sollte auch die Default-Takteinstellung (wahrscheinlich HSI*?) reichen. 
SysInit() an erster Stelle im main() (mit korrekten PLL-Einstellungen 
für den 8-MHz-Quarz) ändert übrigens nichts am Problem.

Ich habe schon die Vektortabelle kontrolliert, MSP und PC werden da 
korrekt geladen, der Startup-Code kopiert zuerst die 
Daten-Initialisierungen, löscht bss und hupft dann zu main().

Stutzig gemacht hat mich die MSP-Initialisierung (erster Eintrag in der 
Vektortabelle an 0x0800 0000: Bei einem Beispiel stand da

  (void *)&pulStack[STACK_SIZE],       /*!< The initial stack pointer 
*/

bei einem anderen

  (void *)&pulStack[STACK_SIZE-1],     /*!< The initial stack pointer 
*/

Egal, wenn der Prozessor zicken würde wegen misalignment, würde er das 
immer machen und nicht nur nach power on reset. Vielleicht sind die 
Optimierungs-Probleme auch auf so ein Alignment-Problem zurückzuführen? 
Fragen über Fragen...

Klingelt's da irgendwo bei Euch? Schon mal sowas gehabt? Ich habe jetzt 
schon einen Tag damit verbraten und nur unkonsistente Verhalten 
beobachtet. Mal gehts, mal nicht. Immerhin habe ich ein Beispielprogramm 
(hier aus dem Forum), das immer geht und das oben, das nie läuft. Jetzt 
kommt das alte Spiel "Finde den Unterschied". Ich habe nur die 
Befürchtung, es könnte etwas fieses sein wie ein Bug im Linkerskript 
(das anscheinend von CoIDE erzeugt wird) oder im gcc. Im Errata-Sheet 
von ST fand ich auch nichts. Das Board könnte defekt sein (sehr sehr 
unwahrscheinlich). Jemand eine Idee?

PS: Mir wäre es schon vielleicht 200 € wert, gcc in die Tonne treten zu 
können, aber für IAR oder Keil reicht das nicht. Werde die Tool-Liste 
noch einmal durchgehen und Alternativen anschauen!

Danke - Martin

[Manfred B. (manib)]

Hi Martin,

ich denke, die Fehlesuche ist nicht einfach.
Bei meinen Projekten ist es immer so definiert:
(void *)&pulStack[STACK_SIZE-1],     /*!< The initial stack pointer 
*/

Dann sind bei mir u.A. die folgenden Initialisierungen gesetzt:
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; //fehlt bei dir!
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP; //ist bei dir 
GPIO_PuPd_NOPULL!
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; //fehlt bei dir!

Wieso nimmst du nicht ein funktionierendes Projekt, und baust damit 
deine Anwendung auf?

Sehr zu empfehlen sind da die Librarys von Uwe, wie z.B.:
01-LED-Library (STM32F4)
http://mikrocontroller.bplaced.net/wordpress/?page_id=113

Ciao,
ManiB

[Uwe B. (derexponent)]

dein Fehler ist nachvollziehbar und mit der "richtigen" Initialisierung
behoben

 GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

die Zeile ... und noch ein paar andere fehlen
(wie Manfred schon geschrieben hat)

schau mal nach welche Parameter "GPIO_InitStructure" noch braucht

Gruss Uwe

[Martin (Gast)]

Uwe B. schrieb:
> GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

Ja, das war schlampig, habe die beiden fehlenden Parameter ergänzt und 
jetzt läuft es. Aber ich wollte natürlich keine LED mit 30 MHz blinken 
lassen, sondern hatte ein Projekt mit DAC-Ausgabe, das eben nicht 
zuverlässig startete, abhängig von der Optimierung (-o0 geht, -o1 
nicht). Ich konnte es nach und nach reduzieren auf diese LEDs, aber das 
hat offensichtlich einen anderen Fehler erzeugt.

@Manfred
>Wieso nimmst du nicht ein funktionierendes Projekt, und baust damit
>deine Anwendung auf?
Diese LED-Geschichte war aus einem funktionierenden Projekt kopiert. 
Ausserdem haben sind die Beispiele hier aus dem Forum z.T. mit einer 
alten CoIDE erstellt und haben lauter Leichen im Verzeichnis. Da 
aufräumen ist mühsam. Aber natürlich, wenn irgend möglich verwende ich 
Beispielprogramme, die funktionieren. Ich werd jetzt mal weiter den 
Fehler am ursprünglichen DAC-Code suchen (der auch aus einem Beispiel 
von hier stammt).

Danke - Martin

[Uwe B. (derexponent)]

Fehler durch die Optimierung sind nur schwer zu finden
(event. eine wegoptimierte Pause)

soviel ich weiß gibt es die Möglichkeit einzelne Funktionen
aus der Optimierung rauszunehemen

damit könnte man Funktion für Funktion prüfen wo der Fehler liegt
(falls es nicht zu viele sind :-)

such mal nach :

void my_function(void) __attribute__((optimize(0)));

aber ob der GCC das unterstützt kann ich dir nicht sagen
(hab ich noch nie gebraucht)

Gruss Uwe

[Pete K. (pete77)]

Hast Du auch einen Takt angelegt?

[Martin (Gast)]

Kurzes Update. Wie ich oben schrieb, würde ich lieber etwas Geld in die 
Hand nehmen, anstelle Bugs in den Tools zu suchen. Habe dann gesehen, 
dass Rowley für $150 für Privatanwender zu haben ist und mir die 
Testversion installiert.
Nachdem ich die etwas unübersichtliche (weil sehr leistungsfähige, wenn 
ich es mal mit IAR vergleiche) Projektverwaltung halbwegs begriffen 
hatte, liefen dort alle Versuche auf Anhieb. Sehr viel habe ich noch 
nicht getestet, bisher sieht Crossworks aber sehr gut aus.
Ich muss sagen, ich habe in meiner Laufbahn schon ein paar wilde Sachen 
mit dem STM32 angestellt. Komplexe Linkermaps, mehrstufige Bootvorgänge 
mit in-System-Updatefähigkeit, geänderte Compiler-Startupcodes... üble 
Sachen die grosses Potential für noch üblere Bugs haben. Aber ich habe 
noch NIE so ein elendes Galama erlebt wie mit der CoIDE, selbst bei 
Primitivprogrämmlein. Da mögen schon dumme Fehler wie die 
GPIO-Initialisierung drin gewesen sein, aber trotzdem geht das auf keine 
Kuhhaut.
Mir bestätigt das die schon oft gemachte Erfahrung, dass Software genau 
so viel taugt, wie sie kostet. Oder andersrum (simple Tools wie 
Irfanview ausgenommen): Es gibt keine Gratis-Software. Entweder kostet 
SW Geld - oder Zeit und Nerven.

- Martin