STM32F3Discovery mit RIOT-OS bootet häufig nicht

[Mark (Gast)]

Hallo zusammen,

mein Team und ich sind relativ neu in der praktischen Arbeit mit 
Mikrocontrollern und haben uns nun zwei STM32F3Discovery DevBoards 
gekauft, um erste Erfahrungen zu sammeln. Als Entwicklungs-OS benutzen 
wir Ubuntu 14.04, auf den Controllern wollen wir RIOT-OS 
(http://www.riot-os.org/) verwenden.

Nun haben wir mit beiden Boards folgendes Problem:
Wir haben ein Hello-World geschrieben (in C), das ein paar LEDs 
ansteuert, und das ganze kompiliert und geflasht.
Wenn das Board nun neu gestartet wird (entweder USB-Stecker raus und 
wieder rein, oder über den Reset-Taster), startet das Programm in ca. 
70% der Fälle nicht (keine LEDs gehen an). Wenn man dan irgendwann oft 
genug reseted hat, klappt es auch ein paar mal. Besonders nervig ist das 
beim Debuggen (momentan über GDB), da hier nach jedem Reset der GDB 
Server neu gestartet werden muss.

Inzwischen haben wir herausgefunden, an welcher Stelle der Fehler 
auftritt:
In der Datei RIOT/cpu/stm32f3/startup.c findet sich die Funktion 
reset_handler() (Zeile 54). Hier ist beim Debuggen immer der erste 
automatische Breakpoint. Das ganze läuft dann bis zur Funktion 
__libc_init_array() (Zeile 72) problemlos. In dieser Funktion läuft 
irgendetwas schief und der PC landet in isr_hard_fault() (Zeile 100). 
Diesen Dead-Loop haben wir zum Testen so modifiziert, dass hier eine der 
LEDs gebracht wird. So konnten wir feststellen, dass wir im Fehlerfall 
immer hier landen.

In __libc_init_array() werden scheinbar c-Libraries für den Thumb Modus 
initialisiert. Kommentiert man die Funktion aus, läuft alles, aber das 
ist doch sicher keine gute Lösung, oder?
Gibt es eine Funktin, die die entsprechenden c-Libraries im ARM Modus 
initialisiert, die wir statt der __libc_init_array() verwenden könnten?

Sehr interessant ist, dass das Problem gar nicht auftritt, wenn wir das 
Board zusätzlich zum USB Anschluss mit 3V oder 5V aus unserem 
Labornetzteil versorgen.
Stattdessen nur eine zusätzliche Erdung zu verwenden bringt hingegen 
keine Verbesserung.
Die Oszilloskopie der Versorgungsspannung über USB am Board zeigte nur 
minimale Schwankungen von 30mV beim Reset und ansonsten eine wunderbare 
Gleichspannung.
Wie kann die das alles also mit der Spannungsversorgung zusammen hängen?
Oder gibt es irgendwelche floatenden Kapazitäten, die sich auf-/entladen 
und dadurch Fehlverhalten herbeiführen?

Für Tipps zur Erklärung und/oder Lösung dieses Problems wären wir sehr 
dankbar!

Beste Grüße
Mark

[Florian (Gast)]

Hi Mark,

habt ihr mittlerweile schon eine Lösung für das Problem gefunden? Bei 
mir scheint nämlich genau das gleiche Problem aufzutreten. Würde mich 
freuen, wenn du mir weiterhelfen kannst.

Flo

[Jim M. (turboj)]

Florian schrieb:
> das Problem

Welches Problem? Er hat doch schon eine Lösung im Beitrag: Bessere 
Stromversorgung verwenden, dann tut es.