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.
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.
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.
:-(
@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?
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 :-(
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.
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. ...)
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.
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...
@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.
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.
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?
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?
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?
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 ...
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.
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
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 ;-)
