STM32F103 CubeMX FreeRTos Problem

[Jojo S. (Gast)]

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?

/* IOTaskEntry function */
void IOTaskEntry(void const * argument)
{
  /* USER CODE BEGIN IOTaskEntry */
  /* Infinite loop */
  volatile int dummy = 0;
  for(;;)
  {
      osDelay(10);
      dummy++; // diese Zeile wird nicht erreicht, osDelay hängt
  }
  /* USER CODE END IOTaskEntry */
}

[Werner A. (gnuopfer)]

HI,



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


mfg

[Christopher B. (chrimbo)]

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?

[Karl (Gast)]

Soweit ich weiß sind lokale Variablen und volatile zusammen ziemlich 
sinnlos. Google weiß sicher Details.

[Jojo S. (Gast)]

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.

[Jojo S. (Gast)]

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?