-         

Ergebnis 1 bis 5 von 5

Thema: STM32F4 Discovery + FreeRTOS: Zwei Probleme

  1. #1

    STM32F4 Discovery + FreeRTOS: Zwei Probleme

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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.
    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
    Geändert von BoondockDuck (02.09.2012 um 12:31 Uhr)
    nit resigniert nur reichlich desillusioniert
    e bessje jet hann ich kapiert

  2. #2
    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.
    nit resigniert nur reichlich desillusioniert
    e bessje jet hann ich kapiert

  3. #3
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.554
    Zitat Zitat von BoondockDuck Beitrag anzeigen
    ... Der Controller ist langsamer da auf dem STM32F4 Discovery ein 8MHz Quarz ...
    Heißt das man kannsollte die Quarze tauschen ?
    Ciao sagt der JoeamBerg

  4. #4
    Zitat Zitat von oberallgeier Beitrag anzeigen
    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
    nit resigniert nur reichlich desillusioniert
    e bessje jet hann ich kapiert

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    13.07.2010
    Beiträge
    22
    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

Ähnliche Themen

  1. Projekt: FreeRTos auf RP6
    Von RolfD im Forum Robby RP6
    Antworten: 14
    Letzter Beitrag: 18.12.2012, 13:05
  2. FreeRTos auf RP6?
    Von RolfD im Forum Robby RP6
    Antworten: 11
    Letzter Beitrag: 29.07.2012, 23:58
  3. LCD Libary für STM32F4
    Von Stones im Forum Software, Algorithmen und KI
    Antworten: 3
    Letzter Beitrag: 13.07.2012, 13:55
  4. STM32F4 Discovery und arm-none-eabi-gcc
    Von Torrentula im Forum Software, Algorithmen und KI
    Antworten: 0
    Letzter Beitrag: 21.03.2012, 18:33
  5. freeRTOS.org
    Von Superhirn im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 24.11.2006, 20:07

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •