STM32F Timer Problem

[Ludwig II. (Gast)]

Hallo Experten,

ich lasse gerade an meinem STM32F105 eine LED über einen Timer Interrupt 
toggeln. (Timer 2 über APB1 max 36Mhz).

Habe am STM32F105 eine Taktfrequenz von 72MHz (externer 8Mhz Crystal) 
eingestellt, alles standardmäßig eigentlich - dachte ich.

Wenn ich nun meinen Quellcode (Auszug) ausführe:

    TIM_TimeBaseInitTypeDef TIM_TimeBase_InitStructure;
    TIM_TimeBase_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1;
    TIM_TimeBase_InitStructure.TIM_CounterMode = TIM_CounterMode_Up;
    TIM_TimeBase_InitStructure.TIM_Period = 1999;
    TIM_TimeBase_InitStructure.TIM_Prescaler = 17999;
    TIM_TimeBaseInit(TIM2, &TIM_TimeBase_InitStructure);

hätte ich erwartet, dass alle 500ms (1Hz Periodendauer) ein Timer 
Interrupt ausgelöst wird.
Laut meinem Oszi habe ich aber eine Periodendauer von ca. 125Hz.

Wie gesagt, in der system_stm32f10.c ist alles auf 72Mhz / APB1 36Mhz 
gestellt.
Wo liegt mein (Denk)Fehler?

Danke für eure Hilfe,
Ludwig II.

[Ludwig II. (Gast)]

Hat niemand eine Idee?? ?

[hp-freund (Gast)]

Ich würde das versuchen:

1. Takt(e) an MCO legen und kontrollieren

2. TIM_Period und TIM_Prescaler Werte ändern und sehen ob sich etwas 
ändert.
Falls nicht ist wohl beim aktualisieren der Konfiguration der Wurm drin.

[Ludwig II. (Gast)]

Habe die Takte mal am dem MCO Pin gelegt und folgende Ergebnisse dabei 
festgestellt:

HSE: 8Mhz
HSI: 8Mhz
PLLCLK_DIV2: 12Mhz
SYSCLK: 24Mhz

Das komische ist nur, in der system_stm32F10x.c habe ich folgene 
Einstellungen:

1.

#define SYSCLK_FREQ_72MHz  72000000

2.

/* PLL configuration: PLLCLK = PREDIV1 * 9 = 72 MHz */

RCC->CFGR &= (uint32_t)~(RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLSRC | 
RCC_CFGR_PLLMULL);

RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLXTPRE_PREDIV1 | 
RCC_CFGR_PLLSRC_PREDIV1 | RCC_CFGR_PLLMULL9);

Also um genau zu sein, habe ich in der Datei alles so gelassen wie es 
ist, außer halt die 72Mhz zu Beginn ausgewählt.

Wenn ich an den Prescalern und Taktfrequenzen rumspiele, ändert sich 
zwar auch mein Takt am MCO, allerdings ist das alles viel zu gering ...

Ich habe auch die system_stm32f10x.c gegen eine neue ausgetauscht usw. 
hat alles nichts gebracht.

:-(

[Andreas R. (daybyter)]

Hab gerade eben wohl das identische Programm geschrieben. Aber mit 
stm32duino. Konnte noch nicht testen, weil ich Morgen erst Bluepill 
löten muss.

[hp-freund (Gast)]

Es sieht so aus als ob nicht 8 sondern 25 MHz als HSE_VALUE eingestellt 
sind. Siehe:

http://diller-technologies.de/stm32_wide.html#takt

[Ludwig II. (Gast)]

@hp-freund

Ich habe in meiner stm32f10x.h folgende defines:

#if !defined  HSE_VALUE
 #ifdef STM32F10X_CL
  #define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External 
oscillator in Hz */
 #else
  #define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External 
oscillator in Hz */
 #endif /* STM32F10X_CL */
#endif /* HSE_VALUE */

Leider habe ich als SYSCLK trotzdem nur 24Mhz am MCO.
Müssen die 8Mhz noch an einer anderen Stelle eingestellt werden?
Aber ist das nicht eigentlich sowieso der Standard Wert?

[hp-freund (Gast)]

Moin,

das Ganze scheint ein #define Problem zu sein.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fClock%20problem%208135&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=190

Du solltest mit Debug durch den Code gehen oder wie im Tutorial 
vorgehen.
Ausserdem macht es Sinn alles im Kopf der stm32f10x.h und der 
system_stm32f10x.c zu lesen.

[Ludwig II. (Gast)]

Danke für deine Hilfe hp-Freunde.

Ich habe mir einige Variablen über das STM Studion ausgeben lassen.
(siehe Bild debug)
Ich habe die Variablen nach der SystemInit(); abgefragt.

Auf dem anderen Bild (oszi_mco_sysclk) sieht man das Ergebnis, was am 
MCO-Pin dabei herauskommt.

Welchen Wert könnte/sollte ich noch überprüfen?
Wie gesagt, in der system_stm32f10x.c habe ich nichts geändert, auch 
nichts in der header. Die sind noch Original. Sollte doch dann 
eigentlich funktionieren :-(

[hp-freund (Gast)]

Hallo,
welche IDE benutzt Du? Wenn eclipse(AC6) oder makefile basiert:

Pack mal alles zusammen und häng es an.
Vorher das Projekt aufräumen wegen der Grösse.

Dann schaun wir mal.

[Ludwig II. (Gast)]

Ich benutze Em::Blocks (.ebp), würdest du damit etwas anfangen können? 
Kann auch die einzelnen .c und .h Files zusammenpacken (main.c, 
system_stm32F10x.c usw. ...)

[CAN-Fan (Gast)]

Nutzt du die neue HAL (CubeMX)?

Früher wurde es im Startupcode/Initcode eingetragen, jetzt wird eine 
SystemClockConfig() aufgerufen, dort sollte der Clock-Tree eingestellt 
werden.

Je nach STM32 kann der Timer von verschiedenen Quellen versorgt werden. 
Passen alle MUX-Einstellungen und es gibt auch manchmal fixe Vorteiler.

Der STM32F446 z.B. teilt den Takt vor dem Timer, gibt aber ein Bit, 
damit er wieder die Sys-Clock nutzt, bzw. eine PLL mit x2 nutzt, oder 
was da verbaut ist.

[hp-freund (Gast)]

Ludwig II. schrieb:
> Ich benutze Em::Blocks (.ebp), würdest du damit etwas anfangen können?
> Kann auch die einzelnen .c und .h Files zusammenpacken (main.c,
> system_stm32F10x.c usw. ...)

Ich habe Em::Blocks 2.30 zwar installiert, aber nie wirklich benutzt.
Da vermute ich aber irgend welche Projekteinstellungen die den #define 
entsprechen. Die sollten geprüft werden.

Aus dem gleichen Grund ist das Projekt in einer anderen Umgebung 
natürlich nicht aus den einzelnen .c und .h Dateien nach zu vollziehen.

Ich kann es gern versuchen, aber es schadet natürlich auch nicht wenn 
jemand der Em::Blocks ständig nutzt mitmacht...

[Ludwig II. (Gast)]

@CAN-Fan

CubeMX habe ich nur mal zum rumtesten benutzt, welchen Teiler ich wo 
einstellen muss um auf meine gewünschten Takte zu kommen (siehe Bild).

Für mein Projekt benutze ich es aber nicht.

@hp-Freund

Ich schau mal alle Einstellungen durch.

[hp-freund (Gast)]

Ludwig II. schrieb:
> Ich schau mal alle Einstellungen durch.

Gute Idee. Das beginnt ja schon bei:

#if !defined  HSE_VALUE .....

Wenn HSE_VALUE in EM::Blocks definiert ist, wird der ganze folgende 
Block in der stm32f10x.h nicht ausgeführt. Somit kannst Du da eintragen 
was Du willst.

[Ludwig II. (Gast)]

Mmhh ... so langsam gehen mir die Ideen aus.

Habe unter Build Options -> Compiler Settings -> #defines -> 
HSE_VALUE=8000000 eingetragen, trotzdem kein Erfolg. Habe jeden Wert 
mittlerweile doppelt und dreifach überprüft.

Was kann ich jetzt noch tun?

[holger (Gast)]

>Was kann ich jetzt noch tun?

Die Ausgabe deines Oscis bezweifeln;)

[Ludwig II. (Gast)]

Den Gedanken hatte ich auch schon ...
Wenn ich am MCO Pin messe, sollte doch bei Ausgabe von:

HSE: 8Mhz
PLLCLK_DIV2: 36Mhz
SYSCLK: 72Mhz

zu messen sein oder liege ich da falsch?

[hp-freund (Gast)]

Also ich habe mal zum Spass ein EM::Blocks Projekt für den STM32F105 
erstellt.
Wie gesagt kenne ich mich mit EB nicht aus, aber es sollte eigentlich 
funktionieren wenn man ein leeres Projekt erstellt - tut es aber nicht.

Für den STM32F105 wird Connectivity Line benutzt und die Dateien 
erhalten die Endung _cl. Dann sucht er die stm32f10x.h die er nicht 
findet.
Es gibt aber eine stm32f10x_cl.h. Hmm.
Dabei wird auch HSE auf 25 MHz gesetzt!

Erstelle ich ein Projekt für den STM32F103 ist alles i.O.

Welche Projektart hast Du benutzt?

Ist ein EM::Blocks Experte anwesend?

[Ludwig II. (Gast)]

Vielleicht könnte beim Anlegen des Projektes der Fehler liegen ...
Ich habe für meinen STM32F105 die Device Series STM32F10x_CL (F105x - 
F107x connectivity) ausgewählt. Die Endung ist mir auch schon in der 
system_stm32f10x.c über den Weg gelaufen.
Die benötigten Dateien für das Projekt habe ich mir aus der 
STM32F10x_StdPeriph_Lib_V3.5.0 geholt.

Vielleicht sollte ich das Projekt nochmal neu anlegen, allerdings dann 
mit der STM32F10x Device Serie ...

[Ludwig II. (Gast)]

Ahne, jetzt hab ich auch bemerkt, dass man für den STM32F105 die 
Connectivity Line benutzen muss.

[Ludwig II. (Gast)]

Bin immer noch nicht weiter gekommen, ist hier ein EM Blocks Experte 
anwesend?

[hp-freund (Gast)]

Kannst Du denn ein leeres Projekt für den F105 mit _cl anlegen das sich 
dann auch kompilieren lässt?

Wie gesagt, bei mir ging es für den F103 aber nicht für den F105.

[Ludwig II. (Gast)]

Also wenn ich ein leeres Projekt für den F105 anlege, kommt beim 
kompilieren:

fatal error: stm32f10x.h: No such file or directory|


Wenn ich ein leeres Projekt für den F103 anlege kompiliert es ohne 
Fehler.

Ist bei mir also genau so ... Em::Blocks Version 2.30

[hp-freund (Gast)]

Im emblocks Forum gab es auch schon mal einen Beitrag zum gleichen 
Thema.

Wenn der nicht von dir war, beantwortet wurde der da auch nicht :-(

Falls niemand eine Lösung findet:
Musst Du denn bei Em::Blocks bleiben?

Komm doch mit zu SW4STM32 ;-)