STM32F4 Discovery + FreeRTOS: Zwei Probleme

Hello World!

Ich habe ein STM32F4 Discovery und entwickel unter Mac OS (Link: Tutorial) mit der summon-arm-toolchain (GCC).
Compilieren+Debuggen funktioniert. Ich habe FreeRTOS (7.2.0) eingebunden, die Interrupt Vektoren mit den FreeRTOS Handlern vernknüpft (Link: Handler). Nach vielen Mühen kann ich es nun kompilieren und debuggen.

FreeRTOS ruft im Laufe von xTaskCreate memset und strncpy auf. Beim debuggen lande ich immer in "Infinite_Loop" (startup_stm32f3xx.S). Das ist der Default Handler für unerwartete Interrupts.
Ich habe die Funktionsaufrufe innerhalb xTaskCreate testweise auskommentiert und konnte so Tasks starten. Solange ich memset und stncpy (und vermutlich auch andere) vermeide funktioniert das Programm. Allerdings ruft z.B. xQueueSend auch strncpy auf, also praktikabel ist das nicht und ich will wissen woher das Problem kommt.

Ein weiteres Problem: Der Controller ist langsamer wie er soll. Z.b. vTaskDelay(500 / portTICK_RATE_MS) soll den Task 500ms pausieren, es sind aber ca. 1.5sek.
Ich bin nicht sehr vertraut mit den verschiedenen Taktfrequenzen des STM32F4 bzw. dem Cortex M4 und wie man diese einstellt. Dafür gibt es aber Code in der system_smt32f4xx.c (stammt aus den Librarys von STM). Da gibt es eine Funktion SystemInit die SetSysClock aufruft. Der Code wird auch vor der main() aufgerufen.

Zitat:

---

SetSysClock: Configure the System clock source, PLL Multiplier and Divider factors, AHB/APBx prescalers and Flash settings

---

Da es der der unveränderete Code ist der auch in den Beispielprojekten von STM verwendet wird gehe ich davon aus dass der Controller korrekt Initialisiert wird. Die Taktfrequenz wird nach dokumentation auf 168MHz eingestellt, diese 168MHz werden auch FreeRTOS als configCPU_CLOCK_HZ bekannt gegeben. Meine letzte Idee war der Timer Interrupt der den SysTick Interrupt generiert. Der wird innerhalb port.c eingestellt. Da es sich hier um einen offiziellen FreeRTOS Port handelt gehe ich davon aus dass auch der Code korrekt sein wird.

Wenn ich configCPU_CLOCK_HZ manuell verändere (kleiner als 168MHz setze) laufen die Tasks erwartungsgemäß schneller ab. Mir ist unklar an welcher Stelle da ein Fehler sein kann.

Nachtrag: Habe gerade nochmal nachgemessen und eine led im Sekundentakt durch den SysTICK Handler toggeln lassen. Auch hier wieder Faktor 3 Mal langsamer wie erwartet (also anstatt mit 1000Hz kommt der SysTICK mit ca. 333Hz). Das entsprächen 56MHz. Mal weiterforschen ... Es würde mich halt sehr wundern wenn in den Library bzw. Port Codes was falsch ist denn darüber muss ja jeder stolpern.


Nochmal kurz meine zwei Frageb:
- Warum führen memset und strncpy zu einen "unerwatrten Interrupt"
- Warum ist der Controller/FreeRTOS Task langsamer als er soll?

Gruß
Christoph

Ok ich habe die Lösungen (mehr oder weniger) gefunden:

Der Controller ist langsamer da auf dem STM32F4 Discovery ein 8MHz Quarz verbaut ist. Die Library geht von 25MHz aus:

Code:

---

system_stm32f4xx.c
#define PLL_M      25
in
#define PLL_M      8
ändern.

---

Siehe auch: EXE2 FreeRTOS on STM32F4-Discovery

Die Sache mit den memset, memcpy, strncpy ... liegt anscheinend daran dass die newlib inkompatibel für den STM32 kompiliert wurde. Siehe auch hier (in den Kommentaren). Das verstehe ich z.Z. noch nicht so ganz und weiß nicht genau was ich beim kompilieren der Toolchain anders gemacht werden muss. Umgehen kann man das Problem indem man die problematischen Funktionen selber schreibt (Den Code findet man über Google z.B. hier http://clc-wiki.net/wiki/).

Das ist zwar alles nicht zufriedenstellend, aber ich hoffe das hilft jedem der ähnliche Probleme hat.

Zitat:

---

Zitat von BoondockDuck

... Der Controller ist langsamer da auf dem STM32F4 Discovery ein 8MHz Quarz ...

---

Heißt das man kannsollte die Quarze tauschen ?

Zitat:

---

Zitat von oberallgeier

Heißt das man kannsollte die Quarze tauschen ?

---

Das heißt, dass man auf jeden Fall den Quellcode an den tatsächlichen Quarz anpassen muss.
Ob man den Quarz einfach tauschen kann muss man rausfinden. Es wird ja auch einen Grund geben warum die einen 8MHz Quarz nehmen. Datenblätter welzen wird möglicherweise anstrengend, einfach ausprobieren könnte auch helfen ;-)

ich werf mal einen Link von einem Freund in die Runde von einem FreeRtos Discovery F4 porting.

http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_cortex.html

edit: leider hat er es scheinbar runtergenommen :(