#67 improve clock setup for stm32f4xx template
I had some hard time starting the blinky led template project with stm32401re nucleo board.
got opencd failure etc .. it was all about clock setting crashing device in early pwoer up stage :(
STM32Fxxx template file /src/_initialize_hardware.c is setting 168Mhz clock
that is too high many device/board that do not work at such freq.
I think it is preferable to use a a lower freq like 84Mz or even 68 MHz
Like many programer I'm not mush doc or source comment reader (until i face problems)
but i pay atention to any error/warning on the console.
So a source warning or error (#pragma warning) can be added to file to attract
user attention it better customized that code or at least ensure it is ok for it's device/board.
Note that src/_initialize_hardware.c file in completely over-hiding system/src/cortexm/_initialize_hardware.c that could hence be removed.
To make project template more cooperative or ease import of project from STM3232CubeMX
a code generator highly valuable for "non expert" user and quick start a project
the clock config function could be made "weak" and renamed to "SystemClock_Config"
So that user importing CubeMX project files will directly have there generated clock setup.
I have done all these and tested it locally (blink led porting) for nucleo board
if you want the code just let me know.
thank you for your feedback, but the current templates will be migrated to a completely different structure based on cmsis packs, so I do not plan to further maintain them, since they are too complicated.
so please post your suggestions here and I'll try to use them in the next version.
in case I forget, please remind me.
your' welcome
in link below you can see how i changed the template to use my side STM32CubeMX override
https://github.com/diabolo38/STM32F4Nucleo-base/blob/rc0/STM32NucleoF401-base/src/_initialize_hardware.c
I took a look at your code, but what you basically do is to redefine the CMSIS SystemCoreClockUpdate() with your own specific routine.
I'm afraid things are more complicated than you think, the _initialize_hardware.c file is portable across all processors, and cannot include specific code.
the place for your routine is probably in the application code.
Exactly What i did is
remame template configure_system_clock in SystemClock_Config();
make SystemClock_Config weak
hence user redefinition can take precedence over the default one
The default template configure_system_clock is setting up
a too fast 168MHZ clock for most stm32f4 devices (STm32F401 is 84MHZ).
I think these is even more portable over all cross f4 variant and platform.
You cannot assume all f4 device can run 168MHz on PLL !
As is the template do not ork on STM32F401 nucleo board sois nto cross platform at all.
Unfortunately clock setting is cpu+board and application dependent so you can"t generealized it but using the safest setting (ie slow clock from internal osc).
Note that I changed configure_system_clock name to SystemClock_Config cos it is the name given by CubeMX generated clock function setup.
So when cube project is used it override template default with working setting out of the box.
You can keep original name , the weak ref that is most important part.
Second is to know what the default clock is and that default 168MHz will crash most F4 MCU cos too high .
as I already said, in the near future I plan a completely new template engine, and by then I'll probably include these suggestions too.
I did a changes in the F4 template and improved the _initialise_hardware.c.
version 2.9.2 is available from updates-test.
any suggestions are welcome.
on win7-64 -luna SR2 I can't generated any stm32 project
the final "finish" button is always grayed ?
But i have the same issue with non test version plugin so....
Eclipse Mars or ubuntun 14.04 or WIn7-64 wasi t's (maybe my luna is corrupted)
I don't see much difference how finilay the closk is set
It is still 168MHz on HSE mode or HSI mode.
But at least the function doc and comment is clear about it
you could change
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4; instead of RCC_PLLP_DIV2
That will make 84MHz that is ok for most F4xx (401 and 407 ..)
what do you mean by this? do you have a picture?
the idea was to use the maximum clock for each subfamily.
if you have a list of devices that require changes in the PLL settings, I can add some #if defined() for them.
see list fo cpu max freq from this page http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577
F401 84MHz
F411 100MHz
F407... 168MHz
F477 ... 180MHz
I'm scared some AHB/APB clock divider and over thing may need to be adjusted
The "finish" button is gray like the next is that image so can't be used :(
http://s17.postimg.org/vb4al73cv/gnu_arm_template_final.png
that's an issue wiht my hone PC luna install , it work on over PC
ok, I'll add as many #ifdef's as necessary to set each sub-family at max clock correctly.
probably because of the unfortunate macro. enter the absolute address and it'll work.
please check the new version in git and let me know if you have further improvements.
it sets 84 MHz for the small devices and 168 for the large ones. I prefered to not go to the highes possible to keep the 48 MHz required for USB.
I just published a new beta on updates-test, you can check that one too.
as you coudl see it was not gray despite the system var used.
here is what i had on home pc absolute path no way to have it :(
http://s22.postimg.org/fuaa8tv75/home_luna.png
After re-install luna all went well .
Agree 84MHz is best kept for usb even if that not quite so imprtant when running on HSE
(clock precison ofen cause usb instability)
From the update test
new F401 anf F407 look all good (code and comment)
For F411 clok seam good shall be 84Mhz (/4)
but the comment on function is wrong
hmmm... so we have no idea what went wrong...
why would you need a system var for this?
I guess you checked an intermediate version, the comment went away.
ne no idea at all what mesed up , i did mutliple update install uninstall on that luna + had ac6 so many thing could have mess up :(
i use the var cos i have mutliple arm toollchain installed in use (arm926, r4-uclinux, gnu ebai) so it make it easier to swicth (source the full env script then start eclispe from command line).
Some project are shared , not all user have same intsall version at same place so that canot be abolutte path.
As CROSS_COMPILE is the comon var for linux kernel cross compile
make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-gcc ...
it make some window/linux cross used project mroe straigth foward to use.
the managed build plug-in already can keep track of all toolchains that I could think of. if you need even more, we can add them.
hmmm... the toolchain path is not stored in the project, so using absolute toolchain path does not affect project portability. there are lengthy explanations on project portability in the project web. did you read them?
based on your suggestions, I changed the SystemClock_Config() to weak and added a #warning.
the latest version is available from updates-test.
perfect
fixed in 2.9.2-201508071246