STM32L4 Disco-Board CPU arbeitet nicht korrekt?!

[MOBA 2. (Gast)]

Hallo,

Vorweg: alles was mit USB zu tun hat, und ausgeklammert ist, kann 
erstmal ignoriert werden. Interessant nur die Lines mit "Fehler"!


ich habe ein STM32L476 Disco-Board. Mit ach und krach habe ich das Teil 
unter EMBitz zum laufen bekommen. Beim F407 hat das jetzige Programm 
ohne Probleme gearbeitet (also was Interrupts und Config der 
Timer/Interrupts angeht).


Ich habe den L476 mit MXCube configuriert, in EMBitz eingebunden.
Ich kann nun mit dem Joystick als GPIO_ReadPin (rechts zeigt richtung 
Reseet-Button) die grüne LED toggeln. Beide LEDs leuchten.


Problem: Mit dem Center-Button sollte durch Interrupt die grüne LED 
toggeln, Timer2 sollte im Interrupt-Modus die rote 1Hz blinken lassen.

Beide Interrupts funktionieren nicht. Wenn ich den Timer2 starten will, 
hängt er sich weg, HAL_Delay hängt er sich ebenfalls weg.

Ich bin absolut ratlos, vorallem weil beim F407 alles ohne Probleme 
geklappt hat.


Ich habe mal die main.c und das .ioc angehängt.
Die Zeilen, die Auskommentiert mit "Fehler" sind, verursachen das hängen 
des MC. Vll. stürzt er auch ab, keine Ahnung.

Komischer weise kann ich mit MXCube auch kein HSI auswählen, sollte aber 
daran nicht liegen. Ein Quarz ist auf dem Board nicht verbaut.

Ich weiß jetzt nicht ob der Fehler am Quellcode liegt, oder am Einbinden 
vom Ler in EMbitz (da man dort keinen L auswählen kann).

Ich habe einfach von MXCube von TrueStudio die xxx.ld ins 
root-verzeichnis von EMBitz kopiert und im Linker übernommen.
Außerdem unter Templates/xxx.S mit der von EMBitz ersetzt.
Offiziell hatte ich am Anfang beim Erstellen des Projekts den M4 with 
FPU ausgewählt, und dann einfach irgendeinen davon, werden ja nur 
F-Serie angezeigt.


Ich bin absolut ratlos, bitte um Hilfe!

[Arc N. (arc)]

EXTI und TIM2-Interrupt sehen nicht wie von CubeMX generiert worden aus 
und passen nicht zum HAL:
HAL_GPIO_EXTI_Callback und HAL_TIM_PeriodElapsedCallback wären die 
Callbacks, die das HAL vom Interrupt aus aufruft und überschrieben 
werden sollten (deshalb sind die auch mit __weak dekoriert).
Siehe stm32l4xxhal_tim.c und stm32l4xx_hal_gpio.c
Also bspw.

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
   if (GPIO_Pin == MYPINDEFINITIONFROMCUBEMX) {
      ...
   }
}

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
   if (htim == &myTimerHandle) {
   }
}

[MOBA 2. (Gast)]

Arc N. schrieb:
> EXTI und TIM2-Interrupt sehen nicht wie von CubeMX generiert worden aus
> und passen nicht zum HAL:
> HAL_GPIO_EXTI_Callback und HAL_TIM_PeriodElapsedCallback wären die
> Callbacks, die das HAL vom Interrupt aus aufruft und überschrieben
> werden sollten (deshalb sind die auch mit __weak dekoriert).
> Siehe stm32l4xxhal_tim.c und stm32l4xx_hal_gpio.c
> Also bspw.
>

> void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
>    if (GPIO_Pin == MYPINDEFINITIONFROMCUBEMX) {
>       ...
>    }
> }
> 
> void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
>    if (htim == &myTimerHandle) {
>    }
> }
>

Ich bin neu bei den STM. Aber was ich im Netz gelesen habe, war auch 
immer sowas wie deins, hat aber nie funktioniert. Das was in meiner main 
ist, ist das was CubeMX generiert hat (nur halt in der _it.c). Damit 
funktioniert es. Ich habe den Fehler auch gefunden, es lag am 
Startup-Scipt und an der .ld. Wenn man die von CubeMX von TrueStudio und 
aus dem Templates/gcc nimmt  und die mit dem .S löscht, dann geht es und 
mein Code arbeitet wieder fast wie vorher.

Blöderweise geht nur das USB gar nicht. Auch mit den Files von CubeMX. 
Wenn ich es anstecke dann passiert nichts. Auch keine Geräteerkennung - 
gar nichts. Ich habe die Treiber mal hochgeladen.