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.
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.SetSysClock: Configure the System clock source, PLL Multiplier and Divider factors, AHB/APBx prescalers and Flash settings
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
Zitieren
Lesezeichen