STM32F103 CubeMX FreeRTos Problem

Jojo S. Gast #4506075
Lesenswert?
• ▲
▼ 
Hat hier jemand Erfahrung mit dem CubeMX generierten FreeRTos Code? Ich 
habe mir für den STM32F103C8T ein Projekt mit FreeRTos generieren lassen 
und das kompiliert und läuft auch an. Als Beispiel wird ja ein Task mit 
Endlosschleife und osDelay(1); angelegt. Die Task wird gestartet und das 
delay wird aufgerufen aber da läuft das Programm nicht drüber, warum??
Der osSystickHandler() wird aufgerufen, konfiguriert über Timer2 wie 
CubeMX das vorgeschlagen hat. Zur Kontrolle habe ich einen 
vApplicationTickHook() eingebaut der eine LED blinken lässt, die Clock 
initialisierung sieht damit ok aus.
CubeMX möchte für FreeRTOS nicht den SysTick verwenden und ich habe ja 
Timer2 angewählt. Trotzdem wurde der osSystickHandler() in der SysTick 
ISR aufgerufen. Das habe ich auf die Timer ISR geändert aber auch das 
hat nicht geholfen.
Ein zweite Task mit höherer Prio hängt genauso im osDelay bzw. 
vTaskDelay. Was kann da noch faul sein?

1
/* IOTaskEntry function */

2
void IOTaskEntry(void const * argument)

3
{

4
  /* USER CODE BEGIN IOTaskEntry */

5
  /* Infinite loop */

6
  volatile int dummy = 0;

7
  for(;;)

8
  {

9
      osDelay(10);

10
      dummy++; // diese Zeile wird nicht erreicht, osDelay hängt

11
  }

12
  /* USER CODE END IOTaskEntry */

13
}
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Christopher B. Persönliche Seite #4506452
Lesenswert?
• ▲
▼ 
Jojo S. schrieb:
> volatile int dummy = 0;

Werner A. schrieb:
> Wenn du den "dummmy" nicht irgendwo im Programm verwendest, wir der
> compiler die Variable wegoptimieren, dann bleibt eine leere schleife mit
> Delay übrig .

das hoffe ich mal nicht. Wobei, wie ist das bei lokalen volatilen 
variablen?

Edit: Moment mal, er kann dummy doch gar nicht 'irgendwo im Programm' 
verwenden. dummy ist doch lokal.

Edit2: Vielleicht noch was zum Thema, sind die Interrupts global 
aktiviert?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jojo S. Gast #4506597
Lesenswert?
• ▲
▼ 
Durch kompilieren mit Debug Option bleibt mir das dummy erhalten. Aber 
auch wenn ich es weglasse und mit dem Debugger über das Delay springen 
will hängt es im Delay. Oder wenn ich einen Breakpoint auf die delay 
Zeile setze sollte die ja zyklisch drankommen, die wird aber nur beim 
ersten Taskstart durch vTaskStartScheduler() aufgerufen.
Was im Delay passiert habe ich noch nicht ganz verstanden, es wird die 
Weckzeit in Ticks berechnet und das sieht auch ok aus. Und der Scheduler 
wird auch zyklisch im Timerinterrupt aufgerufen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jojo S. Gast #4506734
Lesenswert?
• ▲
▼ 
aaaargh... da habe ich über Stunden einen falschen Fehler gesucht :-(
Die Compileroption hatte ich auf -Og, Optimize for debugging gesetzt. 
Die (oder das volatile) hat das dummy stehen gelassen, aber das 
osDelay() wegoptimiert. Bzw. osDelay() ist ein kleiner Wrapper für 
FreeRTOS nach CMSIS_RTOS. Ein Breakpoint auf die osDelay Zeile wird 
nicht getroffen, aber einer in der Funktion die vTaskDelay() aufruft tut 
was er soll...
Ok, dafür habe ich die Unschärfe mit dem SysTick und dem Timer2 
entdeckt, eigentlich soll der Timer2 als Systemtakt dienen aber der 
Systick wird auch initialisiert und der ruft den osSystickHandler() auf. 
Kennt jemand den Grund warum der Timer anstelle des Systicks verwendet 
werden soll?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren