STM32 HAL Timer Interrupts (STM32CubeF4)

[Christian (Gast)]

hi, ich habe bereits viel mit 8-Bit AVRs gemacht,
und mache jetzt meine ersten Erfahrungen an einem STM32.

Habe hier ein "WaveShare Core 4171" mit einem STM32F407 auf einem 
"WaveShare Open 4171" Breakout-Board.

Toolchain mit GCC, Eclipse und JTAG-Debugger läuft.

Mein erstes Programm wo ich die GPIOs ansteuere funktioniert.

Jetzt wollte ich einen Timer-Interrupt haben der alle 8ms aufgerufen 
wird.

Aber die Interrupt-Callback-Funkltion wird nicht aufgerufen.

Hab ich irgendwas vergessen?
Timer mit Clock-Quelle verbinden.
Interrupts global erlauben?

Die Dokumentation der STM32CubeF4-HAL ist leider nicht so toll.

Der Aufruf von HAL_TIM_Base_GetState() gibt 1 (Peripheral Initialized 
and ready for use) zurück

#include <stm32f4xx_hal.h>
#include <diag/Trace.h>

TIM_HandleTypeDef hT4;

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
  HAL_GPIO_WritePin(GPIOH, 0b00000100, GPIO_PIN_RESET);
}

void init(void) {
  /* ### GPIO ####################################################################################### GPIO ### */
  __HAL_RCC_GPIOH_CLK_ENABLE();
  GPIO_InitTypeDef GPIO_InitStructure;
  GPIO_InitStructure.Pin = 0b00001100;
  GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
  GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
  GPIO_InitStructure.Pull = GPIO_PULLUP;
  HAL_GPIO_Init(GPIOH, &GPIO_InitStructure);

  // Start with leds turned on
  HAL_GPIO_WritePin(GPIOH, 0b00001100, GPIO_PIN_SET);

  /* ### Timer ##################################################################################### Timer ### */
  __HAL_RCC_TIM4_CLK_ENABLE();
  hT4.Instance = TIM4;
  hT4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV4; // 168 MHz / 4 = 42 MHz
  hT4.Init.Prescaler = 419; // 42 MHz / (419 + 1) = 100 KHz
  hT4.Init.Period = 799; // 100 KHz / (799 + 1) = 125 Hz
  hT4.Init.CounterMode = TIM_COUNTERMODE_UP;
  hT4.Init.RepetitionCounter = 0;
  HAL_TIM_Base_Init(&hT4);
  //HAL_TIM_Base_Start(&hT4);
  HAL_TIM_Base_Start_IT(&hT4);
}

void loop(void) {
  static unsigned int i = 0;
  i++;
  if ((i & 0x00FFFFFF) == 0x00800000) {
    HAL_GPIO_WritePin(GPIOH, 0b00001000, GPIO_PIN_SET);
    //trace_puts("Alive");
    trace_printf("Timer4 state: %i\n", HAL_TIM_Base_GetState(&hT4));
    HAL_TIM_StateTypeDef x;
  }

  if ((i & 0x00FFFFFF) == 0x00000000) {
    HAL_GPIO_WritePin(GPIOH, 0b00001000, GPIO_PIN_RESET);
  }
}

// ----- main() ---------------------------------------------------------------

// Sample pragmas to cope with warnings. Please note the related line at
// the end of this function, used to pop the compiler diagnostics status.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
#pragma GCC diagnostic ignored "-Wmissing-declarations"
#pragma GCC diagnostic ignored "-Wreturn-type"

int main(int argc, char* argv[]) {
  // At this stage the system clock should have already been configured
  // at high speed.

  init();

  // Infinite loop
  while (1) {
    loop();
  }
}

#pragma GCC diagnostic pop

// ----------------------------------------------------------------------------

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Christian schrieb:
> GPIO_InitStructure.Pin = 0b00001100;

So etwas kann beim STM32 funktionieren, muss aber nicht, denn sowohl 
CMSIS als auch HAL/Cube erwarten hier ein 16-bit Argument. Nimm lieber 
die 'GPIO_Pin_3' und 'GPIO_Pin_4' Definitionen, denn dafür sind sie da. 
Das gleiche kommt in deinem Code noch woanders vor.
Also

 GPIO_InitStructure.Pin = GPIO_Pin_3 | GPIO_Pin_4 ;

Dann sehe ich in deinem Code keine Initialisierung des NVIC. Der wird 
für Interrupts benötigt. In CMSIS Syntax sieht das ungefähr so aus:

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
  TIM_ClearITPendingBit(TIM4, TIM_IT_Update);   // clr any pending irqs
  TIM_ITConfig(TIM4, TIM_IT_Update, ENABLE);    // lets enable update events
  NVIC_InitStructure.NVIC_IRQChannel = TIM4_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x0b;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;   // ready to run
  NVIC_Init(&NVIC_InitStructure);

hier mal für Timer 4. Erst dann kann der Timer periodisch IRQs auslösen, 
in diesem Fall beim Update Event.

[Christian (Gast)]

Danke für die Info, das wird mir sicher weiterhelfen,

jetzt muss ich mal schauen wo die HAL-Äquivalent zu den CMSIS-Aufrufen 
sind.

[Christian (Gast)]

Es geht jetzt.

Die HAL-Funktionen habe ich gefunden

HAL_NVIC_SetPriority(TIM4_IRQn, 4, 0);
HAL_NVIC_EnableIRQ(TIM4_IRQn);

und die ISR musst auch ändern:

statt HAL_TIM_PeriodElapsedCallback()
habe ich jetzt

void TIM4_IRQHandler(void) {
  static int i = 0;
  i++;
  if (i == 125) {
    HAL_GPIO_WritePin(GPIOH, 0b00000100, GPIO_PIN_RESET);
  }
  if (i == 250) {
    HAL_GPIO_WritePin(GPIOH, 0b00000100, GPIO_PIN_SET);
    i = 0;
  }
  
  HAL_TIM_IRQHandler(&hT4);
}

Die Makros GPIO_Pin_x usw. sind aus CMSIS. Jetzt mal schauen ob es in 
der HAL auch welche dafür gibt.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Christian schrieb:
> HAL_TIM_Base_Start_IT(&hT4);

Wenn ich HAL richtig kapiere, sollte das eigentlich die ISR 
Initialisierung erledigen, so das das Problem evtl. wirklich nur die 
GPIO Definition betrifft.
Bin aber wirklich mit HAL auf Kriegsfuss - schon CMSIS geht mir über die 
Hutschnur.
Edit: Ahh, lese jetzt dein letztes Posting - fein, das es klappt.
Übrignes gibt es bei einigen STM32 ein Problem mit dem Rumfummeln an 
GPIOs in ISR Routinen, wenn man nicht vorher schon das IT Bit löscht. 
Das betrifft aber eher externe Interrupts - sollte man aber dran 
denken,z.B. so:

void EXTI9_5_IRQHandler(void)
{
  if(EXTI_GetITStatus(PLAY_EXTI_LINE) != RESET)
  {
 /* Clear the EXTI line pending bit */
    EXTI_ClearITPendingBit(PLAY_EXTI_LINE);
    if (!fastFlags.PlayUpdate) {
        fastFlags.PlayUpdate = TRUE;
        DRIVE_GPIO_PORT->ODR ^= REEL_SENSOR_PIN;
    }
  }
}

[Christian (Gast)]

Das nächste Problem,
meine ISR wird um den Faktor 2 zu häufig aufgerufen, sprich mit 250Hz 
statt 125Hz.

Ist der Timer-Takt ein andere als der CPU-Takt?

Der CPU-Takt sollte vom Startup-Code auf 168Mhz eingestellt sein.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Christian schrieb:
> Ist der Timer-Takt ein andere als der CPU-Takt?

Oh, ja. Schau dir mal den Clock Tree im Reference Manual an (RM0090) auf 
Seite 212/1713, dort steht auch, das die Timer von APB1 oder APB2 
angetrieben werden, typisch 1/2 oder 1/4 CPU Clock. Wie genau die 
Vorteiler stehen, kannst du mittels der SystemClock_Config() einstellen, 
aber voller CPU Takt geht nicht.

[Christian (Gast)]

OK, also wenn die maximale Timer-Clock, 1/2 CPU-Clock ist, dann läuft 
mein Timer sogar um den Faktor 4 zu schnell.

Also, so als ob diese Zeile kein Effet hat.

hT4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV4;

Dann werde ich mir mal Reference Manual reinziehen.

[Christian (Gast)]

Jep, hab mal ClockDivision auf 0 gesetzt und Blinkt immer noch genau so 
schnell.

[Jens E. (surfjenser)]

In CubeMx kann man sich ja auch grafisch ganz gut ansehen, wie sie die 
Clocks zusammensetzen

[Sebastian V. (sebi_s)]

Matthias S. schrieb:
> Christian schrieb:
>> GPIO_InitStructure.Pin = 0b00001100;
>
> So etwas kann beim STM32 funktionieren, muss aber nicht, denn sowohl
> CMSIS als auch HAL/Cube erwarten hier ein 16-bit Argument. Nimm lieber
> die 'GPIO_Pin_3' und 'GPIO_Pin_4' Definitionen

Tatsächlich ist Pin eine 32-bit Variable, was einem als C-Programmierer 
aber auch egal sein kann, da sowieso automatisch konvertiert wird. 
Interessanter ist eher die Frage ob das Bitmuster immer stimmt. Daher 
würde ich auch eher zu den Defines raten, allerdings meintest du wohl 
'GPIO_PIN_2' und 'GPIO_PIN_3', denn hier wird bei 0 angefangen zu 
zählen!

[Steffen R. (steffen_rose)]

Sebastian V. schrieb:
> Tatsächlich ist Pin eine 32-bit Variable, was einem als C-Programmierer
> aber auch egal sein kann, da sowieso automatisch konvertiert wird.

Darüber, dass die automatische Konvertierung manchmal nicht so 
konvertiert, wie es der unerfahrene C-Programmierer erwartet, ist schon 
so mancher gestolpert.

[Sebastian V. (sebi_s)]

Steffen R. schrieb:
> Darüber, dass die automatische Konvertierung manchmal nicht so
> konvertiert, wie es der unerfahrene C-Programmierer erwartet, ist schon
> so mancher gestolpert.

Wenn man nicht gerade signed und unsigned mischt kann bei der 
Konvertierung zu größeren Datentypen eigentlich nichts schiefgehen. Bei 
signed zu unsigned gleicher Größe ist auch alles gut wenn man keine 
negativen Werte hat.

[Steffen R. (steffen_rose)]

Sebastian V. schrieb:
> Wenn man nicht gerade signed und unsigned mischt

>> GPIO_InitStructure.Pin = 0b00001100;

Pin sollte unsigned sein.

0b00001100 naja, dürfte implementierungsspezifisch sein. GGf als int und 
somit signed interpretiert werden.
Üblich angewendet werden hex und binär eher als unsigned.

Ich wäre mir hier zumindest unsicher. Aber das trägt nichts zum Thema 
bei.

[Sebastian V. (sebi_s)]

Steffen R. schrieb:
> Üblich angewendet werden hex und binär eher als unsigned.

Richtig. Das hat man sich beim Standardkomitee auch wohl bedacht. Daher 
hat 0x7FFFFFFF den Typ int (wenn int 32Bit groß ist) und 0x80000000 den 
Typ unsigned int. In dem 0x7FFFFFFF Fall und alle kleineren Zahlen ist 
es aber auch kein Problem wenn der Wert zu unsigned konvertiert wird, da 
0x7FFFFFFF nicht negativ ist und daher garantiert in einen unsigned int 
passt. Für binary wird es ähnlich sein, auch wenn es nicht 
standardisiert ist. Wenn man sich unsicher ist kann man ja immer noch 
ein 'u' anhängen.

[Martin M. (murmele)]

Ich versuche derzeit auch den Timer mit Interrupt zum laufen zu 
bekommen. Doch bei mir springt er dauernd in den Default Handler. Warum 
wird mein TIM2_IRQHandler nicht erkannt? Ist die 
"HAL_TIM_PeriodElapsedCallback"-Funktion die in den Beispielen von ST 
verwendet wird, für alle Timer gleichzeitig? In den Beispielen 
funktioniert der Timer auch ohne HAL_NVIC_EnableIRQ(TIM2_IRQn);

 //TIM2: APB1
// Timer channel 2 as base timer
void timer2Init()
{
  /* Variables */
  TIM_HandleTypeDef initTimBase;

  /* enable Clocks */
  __HAL_RCC_TIM2_CLK_ENABLE();

  // every 1ms an overflow
  initTimBase.Instance = TIM2;
  initTimBase.Init.CounterMode = TIM_COUNTERMODE_UP;
  initTimBase.Init.Period = 32;
  initTimBase.Init.Prescaler = 1344;
  initTimBase.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
  initTimBase.Init.RepetitionCounter = 0;


  //HAL_TIM_Base_Start(&initTimBase);

  HAL_NVIC_SetPriority(TIM2_IRQn, 4, 1);
  HAL_NVIC_EnableIRQ(TIM2_IRQn);

  HAL_TIM_Base_Init(&initTimBase);   //MspInit haben keinen Rückgabewert
  HAL_TIM_Base_Start_IT(&initTimBase);
}


void TIM2_IRQHandler(void)
{
  int i = 0;
  i++;
}



// just defined interrupt function
/**
 * @brief  Period elapsed callback in non blocking mode
 * @param  htim : TIM handle
 * @retval None
 */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
  static uint32_t time = 0;
  time ++;

  // 1sek
  if(!(time % 1000))
  {
    if((*htim).Instance == TIM2)
    {
      HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
    }
  }
}

[Steffen R. (steffen_rose)]

Warum sollte er? Hierzu machst Du keine Angaben, die man überprüfen 
könnte.

Der Interrupt selbst ist aktiv. Du bestätigst ja selbst, dass "ein" 
Interrupthandler aufgerufen wird.
Dein Problem ist eher, dass bei Dir noch der Defaulthandler statt des 
TIM2_IRQHandler als Interrupthandler für den Timer hinterlegt ist.

[Christian (Gast)]

Du musst in dem Interrupt Handler ein Flag zurück setzen, weiß jetzt 
nicht welches.

Das macht die HAL-Funktion die du aus dem Handler aufrufen musst, wenn 
du es nicht selbst machst.

mach initTimBase global
dann

void TIM2_IRQHandler(void){
    int i = 0;
    i++;
    HAL_TIM_IRQHandler(&initTimBase);
}

[Martin M. (murmele)]

Christian schrieb:
> Du musst in dem Interrupt Handler ein Flag zurück setzen, weiß jetzt
> nicht welches.

Hat leider nichts geändert.

[Christian K. (the_kirsch)]

Sehr komisch,

HAL_NVIC_* eventuell erst nach Start_IT machen.



Übrigens HAL_TIM_PeriodElapsedCallback() wird aus der 
HAL_TIM_IRQHandler() aufgerufen, und die wiederum muss aus 
TIM2_IRQHandler() mit dem richtigen Handler aufgerufen werden.

Hab mich in den letzten Wochen intensiv damit beschäftigt.

[Martin M. (murmele)]

Aber dann muss ich TIM_HANDLE_Typedef global definieren. Geht das auch 
so, dass ich diese irgendwie lokal erstelle? Im Beispiel von ST wird 
aber HAL_TIM_PeriodElapsedCallback() als Interruptroutine verwendet.
Nein es ändert sich nichts, wenn ich die Zeilen vertausche.

[Christian K. (the_kirsch)]

Dann schau dir mal die stm32f4xx_it.c in den Beispiel Projekten an, da 
sind die xxx_IRQHandler() definiert, die alle die HAL_xxx_IRQHandler() 
aufrufen.

Die HandleType variablen müssen leider global definiert sein.

[Christian K. (the_kirsch)]

Was hast du denn als Entwicklungsumgebung?

µVision Keil mit dem MDK-ARM Compiler, oder was auf GCC Basis.

Bei meinem Eclipse wird bei der Projekterstellung bereits CMSIS und die 
HAl eingebunden, und auch durch den Startup Code initialisiert.

[Martin M. (murmele)]

Ich verwende Eclipse unter Linux

Christian K. schrieb:
> Dann schau dir mal die stm32f4xx_it.c in den Beispiel Projekten an, da
> sind die xxx_IRQHandler() definiert, die alle die HAL_xxx_IRQHandler()
> aufrufen.

Stimmt sorry habe ich übersehen. Muss ich meinen Handler auch in einer 
Datei mit diesem Namen machen oder ist das egal wo ich meinen Interrupt 
Handler erstelle/ die Standardroutine überschreibe?

[Armin (Gast)]

Kommentier mal den Default Handler für Timer2 aus, bei mir steht er in 
der startupxxx.S
//  .weak  TIM2_IRQHandler
//  .thumb_set TIM2_IRQHandler,Default_Handler
dann wird der Linker schon moppern.

Ich hatte den Fehler auch, meinen Handler hatte ich einer .cpp Datei und 
da wurde er nicht gefunden.

Er muss in C++ als
extern "C" void void TIM2_IRQHandler(void){
...
deklariert werden.

[Martin M. (murmele)]

void __attribute__ ((section(".after_vectors")))
Default_Handler(void)
{
#if defined(DEBUG)
  __DEBUG_BKPT();
#endif
  while (1)
    {
    }
}

Wenn ich das auskommentiere dann kommen alles Fehlermeldungen, da der 
Defaulthandler nicht mehr verfügbar ist.

void __attribute__ ((weak, alias ("Default_Handler")))
TIM2_IRQHandler(void);

 Wenn ich das auskommentiere, dann kommt ein Fehler, dass 
TIM2_IRQHandler undeclariert ist. Wie kann ich meine Handler funktion 
dazu linken, dass ich Sie verwenden kann?

[Christian K. (the_kirsch)]

Die Weak-Funktionen brauchen nicht auskommentiert werden.

Weak bedeutet, dass die Funktion nur benutzt wird, wenn keine andere 
gleichnamige vorhanden ist.

Martin M. schrieb:
> Muss ich meinen Handler auch in einer
> Datei mit diesem Namen machen oder ist das egal wo ich meinen Interrupt
> Handler erstelle

ist egal wo sie stehen.


Da du einen anderen Statupcode hast als ich, fehlt bei dir eventuell der

HAL_init() Aufruf, denn musst am Anfang der Main machen.

[Martin M. (murmele)]

Jetzt habe ich die HAL_Init eingebaut. Leider keine Veränderung.
Habe jetzt mal im Datasheet gelesen. Hier steht, dass dies die minimalen 
Dateien sind, die man braucht. Dabei ist auch die stm32f4xx_it.c wo die 
interrupt handler sein sollen. Kann ich die Datei einfach erstellen oder 
wie kann ich das verstehen?

[Steffen R. (steffen_rose)]

Da der Default Interrupt Handler aufgerufen wird, brauchst Du nicht an 
der Interrupterzeugung herumzudocktern!

Armin schrieb:
> Kommentier mal den Default Handler für Timer2 aus, bei mir steht er in
> der startupxxx.S
> //  .weak  TIM2_IRQHandler
> //  .thumb_set TIM2_IRQHandler,Default_Handler
> dann wird der Linker schon moppern.

Dem stimme ich für die Fehlersuche zu. Das weak führt dazu, dass das 
fehlen des Symbols TIM2_IRQHandler überdeckt wird. Solange du versuchst 
dein Symbol sichtbar zu machen hilft der Linkerfehler weiter.

Da zu wenig Angaben gemacht wurden, hat Armin auch ein Beispiel 
geliefert, warum TIM2_IRQHandler nicht gefunden wird.

Martin M. schrieb:
> void _attribute_ ((weak, alias ("Default_Handler")))
> TIM2_IRQHandler(void); Wenn ich das auskommentiere, dann kommt ein
> Fehler, dass
> TIM2_IRQHandler undeclariert ist. Wie kann ich meine Handler funktion
> dazu linken, dass ich Sie verwenden kann?

Genau das ist dein Problem, was du lösen mußt. Nicht die Erzeugung des 
Interrupts.

Das Problem liegt in der Datei, aus dem dein Eingangs geposteter Code 
stammt. Entweder ist die Funktion nicht global sichtbar oder der 
Compiler nennt diese um. Die Idee von Armin war, dass diese mit (C++) 
gpp übersetzt wird. Und C++ hat ein anderes NamensSchema wie C. Der Code 
ist für eine Übersetzung mit einem C Compiler (gcc).

Vielleicht hast Du die Datei mit *.cpp enden lassen statt mit *.c?
Vielelicht einfach mal die Originaldatei anhängen, welche den 
TIM2_IRQHandler() enthält.

[Christian (Gast)]

Zeig doch mal deinen gesamten Code.

Mit Main und allen Handlern die du definiert hast. Am besten alles in 
eine Datei reinkopieren, soviel hast du ja noch nicht.


Du verwendest als Startup Code die Assembler-Datei aus dem 
CMSIS-Package.
Die ruft einige Funktionen auf (noch bevor Main losgeht) auf die du 
selbst implementieren musst.

In den Beispielprojekten sind diese in der system_stm32f4xx.c drin.

[Martin M. (murmele)]

Hier mal der gesamte Code:

#include <stdio.h>
#include "diag/Trace.h"
#include "stm32f411xe.h"
#include "stm32f4xx_hal.h"

void timer2Init();


// ----- main() ---------------------------------------------------------------

// Sample pragmas to cope with warnings. Please note the related line at
// the end of this function, used to pop the compiler diagnostics status.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
#pragma GCC diagnostic ignored "-Wmissing-declarations"
#pragma GCC diagnostic ignored "-Wreturn-type"

TIM_HandleTypeDef initTimBase;

int main(int argc, char* argv[])
{
  /* Variables */
  uint32_t i;

  HAL_Init();
  gpioInit();
  timer2Init();

  // Button: PC13
  // LED: PA5

  // Infinite loop
  while (1)
  {
    for(i = 0; i<500000; i++){}
    HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
  }
}



//TIM2: APB1
// Timer channel 2 as base timer
void timer2Init()
{

  /* enable Clocks */
  __HAL_RCC_TIM2_CLK_ENABLE();

  // every 1ms an overflow
  initTimBase.Instance = TIM2;
  initTimBase.Init.CounterMode = TIM_COUNTERMODE_UP;
  initTimBase.Init.Period = 32;
  initTimBase.Init.Prescaler = 1344;
  initTimBase.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
  initTimBase.Init.RepetitionCounter = 0;

  HAL_TIM_Base_Init(&initTimBase);   //MspInit haben keinen Rückgabewert
  HAL_TIM_Base_Start_IT(&initTimBase);

  HAL_NVIC_SetPriority(TIM2_IRQn, 4, 1);
  HAL_NVIC_EnableIRQ(TIM2_IRQn);
}


void TIM2_IRQHandler(void)
{
  HAL_TIM_IRQHandler(&initTimBase);
} 



// just defined interrupt function
/**
 * @brief  Period elapsed callback in non blockfaceing mode
 * @param  htim : TIM handle
 * @retval None
 */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
  static uint32_t time = 0;
  time ++;

  // 1sek
  if(!(time % 1000))
  {
    if(htim->Instance == TIM2)
    {
      HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
    }
  }
}

#pragma GCC diagnostic pop

// ----------------------------------------------------------------------------

> Kommentier mal den Default Handler für Timer2 aus, bei mir steht er in
> der startupxxx.S
> //  .weak  TIM2_IRQHandler
> //  .thumb_set TIM2_IRQHandler,Default_Handler
> dann wird der Linker schon moppern.
Ich finde aber keine startupxxx.S Datei

[Christian K. (the_kirsch)]

Nach dem generierten Main-Code sieht es so aus als ob du Eclipse 
verwendest.

Dann gibt es keine startupxxx.S Datei.
Eclipse verwendet stattdessen µOS++III als Startupcode, welcher komplett 
in C geschrieben ist (statt Assembler)

Im Startupcode wird bereits die Hal und der Systemtakt initialisiert.

Der Aufruf von HAL_Init(); in der Main ist unnötig.

Die If Abfragen in deiner Timer Callback solltest du tauschen, oder es 
direkt in den TIM2_IRQHandler schreiben.

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
  static uint32_t time = 0;

  if(htim->Instance == TIM2){
    time++;
    // 1sek
    if(!(time % 1000)){
      HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
    }
  }
}

Was passiert denn jetzt, springst du immer noch in den Default_Handler?
Ich sehe jetzt keine Fehler im Code.

[Martin M. (murmele)]

Hat leider nichts geändert, springt immer noch in den Default Handler.

[Dieter Graef (Gast)]

Hab grad einen ähnlichen Fall.Bei mir hat der Linker die schwachen 
Symbole aus dem Assemblerfile nicht durch die starken aus dem C -Code 
ersetzt. Linken mit der Option Wl,--whole-archive brachte die 
Fehlermeldung das der Assemblercode kein Objekt ist. Im C Code klappte 
das Ersetzen. Meine Theorie ist das gcc die Dinge auseinanderhalten will 
weil irgendwelche Assemblerdirektiven nicht stimmen, Meine Lösung war 
das Auskommentieren der weak Stellen im Assemblercode.

[Martin M. (murmele)]

Aber ich habe ja kein Assembler Initfile in Eclipse

[Steffen R. (steffen_rose)]

Martin M. schrieb:
> #pragma GCC diagnostic ignored "-Wunused-parameter"
> #pragma GCC diagnostic ignored "-Wmissing-declarations"
> #pragma GCC diagnostic ignored "-Wreturn-type"

Wozu die ganzen pragmas?

Martin M. schrieb:
>> Kommentier mal den Default Handler für Timer2 aus, bei mir steht er in
>> der startupxxx.S
>> //  .weak  TIM2_IRQHandler
>> //  .thumb_set TIM2_IRQHandler,Default_Handler
>> dann wird der Linker schon moppern.
> Ich finde aber keine startupxxx.S Datei

Naja, irgendwo mußt du die Interruptvektoren schon eingebunden haben.
Da findest Du dann auch den Code, der TIM2_IRQHandler auf 
Default_Handler umbiegt. Ich hoffe mal, dass du die Vektoren drin hast 
und der Default_Handler nicht durch einen Trap ausgelöst wird.

Dieter Graef schrieb:
> Hab grad einen ähnlichen Fall.Bei mir hat der Linker die schwachen
> Symbole aus dem Assemblerfile nicht durch die starken aus dem C -Code
> ersetzt.

Martin M. schrieb:
> Aber ich habe ja kein Assembler Initfile in Eclipse

Bei Dieter G. wird der relevante Code im Linkerfile sein.

Anm:
Da dein Projekt scheinbar anders ist, als die meisten es von uns gewöhnt 
sind, müßtest Du wohl etwas mehr beschreiben. Es geht um alles, das
TIM2_IRQHandler und Default_Handler enthält.

[Martin M. (murmele)]

Steffen R. schrieb:
> Wozu die ganzen pragmas?

Die Pragmas hat Eclipse erstellt.

In der vectors_stm32f4.c wird auf den Default Handler verlinkt:

void __attribute__ ((weak, alias ("Default_Handler")))
TIM2_IRQHandler(void);

Habe mal versucht die Routine direkt hier einzufügen, hat aber nicht 
funktioniert.
Wenn ich es auskommentiere kommt folgender Fehler:

../system/src/cmsis/vectors_stm32f4xx.c:532:7: error: 'TIM2_IRQHandler' undeclared here (not in a function)
       TIM2_IRQHandler,        // TIM2
       ^
make: *** [system/src/cmsis/vectors_stm32f4xx.o] Fehler 1
system/src/cmsis/subdir.mk:21: die Regel für Ziel „system/src/cmsis/vectors_stm32f4xx.o“ scheiterte

[Steffen R. (steffen_rose)]

Martin M. schrieb:
> vectors_stm32f4.c

OK. Genau richtig.

Kommentiere nur die 'weak' Funktionalität aus:

void /* __attribute__ ((weak, alias ("Default_Handler"))) */
TIM2_IRQHandler(void);

Die eigentliche Deklaration brauchst Du für die Vectortabelle.

Er wird vermutlich melden, dass er TIM2_IRQHandler nicht findet. Das 
wäre dann der Beweis, dass es an der Nicht-Sichtbarkeit deines 
Interrupthandlers liegt. Nun ist es an Dir den Linkerfehler zu 
beseitigen.

Wenn diese Linkerwarnung nicht kommt, sondern weiterhin der 
Default-Handler aufgerufen wird, wird ein anderer Interrupt/Trap 
aufgerufen.

Danach kannst Du den Originalzustand in vectors_stm32f4.c wieder 
herstellen.

[Martin M. (murmele)]

Springt immer noch in den Default Handler. Hab aber in der gleichen .c 
Datei noch das gefunden. kann damit aber leider nichts anfangen.

// The vector table.
// This relies on the linker script to place at correct location in memory.

__attribute__ ((section(".isr_vector"),used))
pHandler __isr_vectors[] =
  {
  // Core Level - CM4
      (pHandler) &_estack,                      // The initial stack pointer
      Reset_Handler,                            // The reset handler

      NMI_Handler,                              // The NMI handler
      HardFault_Handler,                   

...

#elif defined(STM32F411xE)

      WWDG_IRQHandler,        // Window WatchDog
      PVD_IRQHandler, // PVD through EXTI Line detection
...

  TIM1_TRG_COM_TIM11_IRQHandler,  // TIM1 Trigger and Commutation and TIM11
      TIM1_CC_IRQHandler,     // TIM1 Capture Compare
      TIM2_IRQHandler,        // TIM2
      TIM3_IRQHandler,        // TIM3
      TIM4_IRQHandler,        // TIM4
      I2C1_EV_IRQHandler,     // I2C1 Event
...

In der HAL_Init() wird der SysClock initialisiert:

__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
  /*Configure the SysTick to have interrupt in 1ms time basis*/
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

  /*Configure the SysTick IRQ priority */
  HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0);

  /* Return function status */
  return HAL_OK;
}

aber die Interrupt Funktion wird nicht aufgerufen und soweit dass andere 
Interrupts noch laufen bin ich noch nicht.

[Dieter Graef (Gast)]

Martin M. schrieb
>Springt immer noch in den Default Handler. Hab aber in der gleichen >.c
>Datei noch das gefunden. kann damit aber leider nichts anfangen.
Dem Linker muß mitgeteilt werden wo sich was im Mikrokontroller befindet 
(RAM ROM)
Dazu wird dem Linker per Option ein Linkerscript meist mit der 
Dateiendung ld  mitgegeben in dem dann unter anderem steht:

/* Specify the memory areas */
MEMORY
{
FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 512K
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

[Steffen R. (steffen_rose)]

Einfach die komplette Datei anhängen. Ist einfacher und enthält auch 
Infos, an die du nicht denkst.

Was sagt das Mapping File?
Hast Du das richtige Derivate ausgewählt oder nur ein ähnliches?

HAL_InitTick() nutzt den Systick interrupt. Aber der sollte bei dir auch 
schon eingerichtet sein, oder? Den genauen Namen hast du mit deinen ... 
verschluckt. Ich glaube Systick_Handler().

Du kannst echt nicht debuggen?

[Steffen R. (steffen_rose)]

Dieter Graef schrieb:
> Dem Linker muß mitgeteilt werden wo sich was im Mikrokontroller befindet

Ohne diese Angabe wäre er gnadenlos abgestürzt.
Aber richtig:
@Martin: Woher weißt du, dass du im Default_Handler() landest?

[Martin M. (murmele)]

Steffen R. schrieb:
> Woher weißt du, dass du im Default_Handler() landest?
Er springt immer in diese Routine:

void __attribute__ ((section(".after_vectors")))
Default_Handler(void)
{
#if defined(DEBUG)
  __DEBUG_BKPT();
#endif
  while (1)
    {
    }
}

Ich habe dort zwar kein Brakepoint gesetzt, aber der Debugger hält hier 
immer.

Im Anhang habe ich jetzt mal das komplette Projekt hochgeladen.

"Placeholder to list other libraries required by the application." Das 
steht in der libs.ld muss ich da eventuell meine C Dateien angeben?

Dieter Graef schrieb:
> Dazu wird dem Linker per Option ein Linkerscript meist mit der
> Dateiendung ld  mitgegeben in dem dann unter anderem steht:

Ja habe ich gefunden.

Steffen R. schrieb:
> Was sagt das Mapping File?
> Hast Du das richtige Derivate ausgewählt oder nur ein ähnliches?

???

Steffen R. schrieb:
> Du kannst echt nicht debuggen?

Doch ich kann Debuggen, habe nie gesagt, dass ich das nicht kann.

[Steffen R. (steffen_rose)]

Martin M. schrieb:
> Ich habe dort zwar kein Brakepoint gesetzt, aber der Debugger hält hier
> immer.

Na toll.... ;-)

Schau doch gleich in das PSR Register (genauer IPSR, weiß nicht, was bei 
den Core registern angezeigt wird). Dort findest Du den Auslöser des 
Interrupts (Interruptnummer). In deinem Datasheet zu deinem Prozessor 
solltest du die Nummer auflösen können.
(mehr Details im Dokument DM00046982)

Lt. deinem Mappingfile sollte es wohl eines von den Handlern sein, die 
du dort aufgelistet findest:

0x0000000008000418        0x4 ./system/src/cmsis/vectors_stm32f4xx.o
                0x0000000008000418                RTC_Alarm_IRQHandler
                0x0000000008000418                EXTI2_IRQHandler
[...]

Christian schrieb:
> Habe hier ein "WaveShare Core 4171" mit einem STM32F407 auf einem
> "WaveShare Open 4171" Breakout-Board.

Martin M. schrieb:
> Steffen R. schrieb:
>> Was sagt das Mapping File?
>> Hast Du das richtige Derivate ausgewählt oder nur ein ähnliches?
>
> ???

Wenn Du einen STM32F407 hast, wäre das Define STM32F411xE offensichtlich 
falsch. Ich vermute STM32F407xx wäre richtig. Das würde dann auch 
erklären, dass der Timer2 Interrupt nicht an der richtigen Stelle wäre.

[Christian K. (the_kirsch)]

@Martin M.
Erstell nochmal das Projekt neu, und achte das du wirklich den richtigen 
Controller angibst.

Und ändere nichts an den Quellcodedateien im Systemordner.
Eventuell hast du durch dein editieren die Vektortabelle kaputt gemacht.

Alle relevanten Funktionen sind als WEAK Definiert, das heißt du kannst 
sie in deinem Code einfach neu definieren.

@Steffen Rose
Ich bin TO, aber mein Problem ist schon seit längerem gelöst.

[Martin M. (murmele)]

Steffen R. schrieb:
> Wenn Du einen STM32F407 hast

Nein ich habe einen stm32f411re. Hat am Anfang das Problem dass der 
externe Clock nicht stimmte der Standardmäßig eingestellt wurde, weshalb 
es auch lange nicht ging.

[Steffen R. (steffen_rose)]

Christian K. schrieb:
> @Martin M.
> Erstell nochmal das Projekt neu, und achte das du wirklich den richtigen
> Controller angibst.
>
> Und ändere nichts an den Quellcodedateien im Systemordner.
> Eventuell hast du durch dein editieren die Vektortabelle kaputt gemacht.

Zugegeben. Korrekterweise gehören Dateien, die man ändert, immer ins 
Projekt.
Uns man sollte immer auch die Originaldateien behalten, um Fehler wieder 
rückgängig zu machen.

> Alle relevanten Funktionen sind als WEAK Definiert, das heißt du kannst
> sie in deinem Code einfach neu definieren.

Meine Vermutung war, dass das Überdefinieren nicht geklappt hat. Durch 
das weak bekommt man aber keinen Fehler. Welche Alternative hätte man?

> @Steffen Rose
> Ich bin TO, aber mein Problem ist schon seit längerem gelöst.

Mist. Ist mir nicht aufgefallen, dass dein Thread nachgenutzt wurde.

Martin M. schrieb:
> Steffen R. schrieb:
>> Wenn Du einen STM32F407 hast
>
> Nein ich habe einen stm32f411re. Hat am Anfang das Problem dass der
> externe Clock nicht stimmte der Standardmäßig eingestellt wurde, weshalb
> es auch lange nicht ging.

Wie soll man hier noch durchblicken. Wäre hier nicht ein eigener Thread 
besser gewesen?

Also weiter mit dem IPSR.

[Dieter Gräf (Gast)]

@Martin
Hab das Projekt auf einem stm32f407 mit einigen Änderungen  zum laufen 
bekommen.
Mein Linker kam mit der weak Zuweisungen nicht klar
die Methode aus vectors_stm32f4xx.c mit
    void __attribute__((weak))
    Default_Handler(void);
und dann
  void /*__attribute__ ((weak, alias ("Default_Handler"))) */
  TIM2_IRQHandler(void);
mit
  void _attribute_ ((section(".after_vectors")))
  Default_Handler(void)
  {
   #if defined(DEBUG)
   __DEBUG_BKPT();
  #endif
  while (1)
    {
    }
}
sprang generell in die Default routine auch wenn woanders der
TIM2_IRQHandler definiert war. Mit
 void /*__attribute__ ((weak)) */
  TIM2_IRQHandler(void)
{
}
gings aber. Wenn das oben genannte funktioniert spart es Speicherplatz. 
Zusätzlich hab ich noch den ganzen Startuprummel in c durch die von ST 
vorgegebene Assemblermethode mit startup_stm32f407xx.s ersetzen müssen 
da ansonsten gleich ein HardFault kam.

[Martin M. (murmele)]

Dieter Gräf schrieb:
> TIM2_IRQHandler definiert war. Mit
>  void /*__attribute__ ((weak)) */
>   TIM2_IRQHandler(void)
> {
> }
> gings aber.

Hast du einfach das _attribute_ ((weak)) auskommentiert?

[Dieter Graef (Gast)]

Martin M schrieb:
>Hast du einfach das attribute ((weak)) auskommentiert?
nee sorry ein copy und paste fehler

__attribute__((weak)) void TIM2_IRQHandler(void)
{
}

ich hab ne echte Funktion draus gemacht keinen alias

m.f.G.
Dieter

[Martin M. (murmele)]

Wenn ich eine echte Funktion mache und das weak nicht auskommentiere, 
wird immer noch der Default Handler ausgeführt, wenn ich das weak weg 
lasse, dann kommt der Fehler, dass es hier das erste mal definiert 
wurde.

[Dieter Graef (Gast)]

Martin M. schrieb:
>dann kommt der Fehler, dass es hier das erste mal definiert
>wurde

Das ist richtig da in deiner main.c Datei die Funktion ja schon steht.
Wie gesagt ich hab dann den c startup code aus deinem Projekt durch 
Assembler von ST ersetzt und dann gings.Leider hab ich nur den 407 und 
nicht den 411.Vermutlich ist deine Vorlage gar nicht für den gcc 
Compiler sondern für einen anderen.

m.f.G.
Dieter

[Martin M. (murmele)]

Ich weiß nicht obs was hilft, aber mein Projekt wird nicht mit dem gcc 
sondern mit der c++ variante kompiliert.

[Steffen R. (steffen_rose)]

Ich erinnere an:

Beitrag "Re: STM32 HAL Timer Interrupts (STM32CubeF4)"

[Martin M. (murmele)]

Auf meinem Laptop hat sich Eclipse geupdatet. Jetzt konnte ich auswählen 
ob ich ein C oder ein C++ Programm schreiben wollte ( vorher stand immer 
C/C++ Programm jetzt stehen Sie getrennt)
Habe am Code nur das extern "C" eingefügt, was vorher keine Wirkung 
hatte, und siehe da er springt in die Routine rein :)

Ein großes Danke an alle die mir hier geholfen haben!!!

[Sören (Gast)]

Christian schrieb:
> OK, also wenn die maximale Timer-Clock, 1/2 CPU-Clock ist, dann
> läuft
> mein Timer sogar um den Faktor 4 zu schnell.
>
> Also, so als ob diese Zeile kein Effet hat.hT4.Init.ClockDivision =
> TIM_CLOCKDIVISION_DIV4;
> Dann werde ich mir mal Reference Manual reinziehen.

Ich habe das selbe Problem mit einem STM32F746IGK, dass 
TIM_CLOCKDIVISION_ kein Effekt hat. Konntet ihr das lösen? Mein 
Prescaler ist bereits am Limit, weshalb ich auf die Taktteilung 
angewiesen bin.
Danke

[Christian K. (the_kirsch)]

Ich hab mich mittlerweile komplett von der Cube-HAL gelöst.

Und greife jetzt ausschließlich über CMSIS (die Hardware-Register 
direkt) zu.

Registerdefinitionen einfach im Datenblatt nachschlagen.

Hier aus meinem letzten Projekt:
timer4.h

#ifndef STM32F4_TIMER4_H
#define STM32F4_TIMER4_H

void timer4_init(void);
void timer4_enableInt(void);

//WEAK
void timer4_1sec_event1(void);

#endif /* STM32F4_TIMER4_H */

timer4.c

#include <CMSIS_Device/stm32f4xx.h>

#include "timer4.h"

void TIM4_IRQHandler(void);

void TIM4_IRQHandler(void) {
  static int i = 0;
  if (TIM4->SR & TIM_SR_UIF) {
    i++;
    if (i == 125) {
      timer4_1sec_event1();
      i = 0;
    }
    TIM4->SR = ~TIM_SR_UIF;
  }
}

void timer4_init(void) {
  /*
   * GP 16-Bit Timer
   */

  RCC->APB1ENR |= RCC_APB1ENR_TIM4EN;

  TIM4->PSC = 840 - 1; // 84 MHz / (840) = 100 KHz
  TIM4->ARR = 800 - 1; // 100 KHz / (800) = 125 Hz
  TIM4->EGR = TIM_EGR_UG; // Generate an update event to reload the Prescaler

  TIM4->CR1 = TIM_CR1_CEN; // Edge-aligned mode; upcounter; TIM enable
  //TIM4->CR2;
  //TIM4->SMCR;
  //TIM4->DIER = TIM_DIER_UIE; // Enable the TIM Update interrupt
  //TIM4->SR;
  //TIM4->CCMR1;
  //TIM4->CCMR2;
  //TIM4->CCER;
  //TIM4->CNT;
  //TIM4->RCR;
  //TIM4->CCR1;
  //TIM4->CCR2;
  //TIM4->CCR3;
  //TIM4->CCR4;
  //TIM4->BDTR;
  //TIM4->DCR;
  //TIM4->DMAR;
  //TIM4->OR;

  NVIC_SetPriority(TIM4_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(), 6, 0));
  NVIC_EnableIRQ(TIM4_IRQn);
}

void timer4_enableInt(void) {
  TIM4->DIER = TIM_DIER_UIE; // Enable the TIM Update interrupt
}

void __attribute__ ((weak)) timer4_1sec_event1(void) {
}

//EOF

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

TIM_CLOCKDIVISION_ ist für etwas anderes gedacht als es auf den 1. Blick 
scheint. Einfach mal uns Manual schauen.

[Koni (Gast)]

Hallo,

ich bin so frech und knüpfe hier einfach mal an. Ich habe das Problem 
mit dem Timer6, dass wenn ich den Timer mit

HAL_TIM_Base_Start_IT(&htim6);

starte und im Anschluss mit

HAL_NVIC_EnableIRQ(TIM6_DAC_IRQn);

den Interrupt aktiviere, er direkt in die IRQ springt, was ich aber 
nicht möchte und auch absolut keinen Sinn macht.
Muss ich vorher irgendein Bit löschen?
Kennt jemand dieses Problem?

Vielen Dank!

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Kein Plan. HAL ist ein Krampf :)

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Koni schrieb:
> Muss ich vorher irgendein Bit löschen?

Ja bitte. Und zwar vermutlich das TIM_IT_Update Bit (oder bei dir das 
DAC Bit, das ich nicht nachschlagen werde). Dann die ISR freigeben. Nu 
frag aber nicht, wie man das mit HAL macht - davon bin ich aus 
medizinischen Gründen befreit worden :-)