its a STM32F103VET6 and I want to use Rogers core
what is the best way to implement it into my additional board definitions & files for the core ?
(of course it would be nice if the modification can be done in some of the files in my added variant folder instead of modifying core files)
there is a suggest from Roger here -> viewtopic.php?p=13842#p13842
to change the boards_setup.cpp so I tried to insert something like this
#ifdef XTAL16M
// 16MHz crystal (HSE)
// in this case we set additionally the Bit 17 (PLLXTPRE=1) => then HSE clock is divided by 2 before PLL entry
static stm32f1_rcc_pll_data pll_data = {BOARD_RCC_PLLMUL | (0x1 << 17) };
#else
// default 8MHz crystal
static stm32f1_rcc_pll_data pll_data = {BOARD_RCC_PLLMUL};
#endif
RCC_BASE->CFGR = pll_src | pll_mul | (0x3<<22) | (0x1<<17);You should only need to change the clock PLL multiplier
If you look at the GD32 variant ( which is no longer an option in the menu but the code is still included),it used a 12MHz crystal, so you can compare with something like the generic stm32c8 variant and not the difference to the PLL settings
72/16 = 4.5 thus the only way is to set the PLL prescaler as above (bit 17). The integer PLL multiplieries will not work for 72MHz and 16Mhz Xtal.
[Pito – Mon Jan 01, 2018 2:59 am] –
PF 2018!72/16 = 4.5 thus the only way is to set the PLL prescaler as above (bit 17). The integer PLL multiplieries will not work for 72MHz and 16Mhz Xtal.
Good point
3 x PLL could be used, to give 48MHz and still maintain USB
Alternative the OP would need to use 64MHz to stay within spec or 80MHz to operate just beyond spec
(In normal domestic conditions I’ve found 128Mhz worked fine)
But for all these options the F_CPU defines would need to be changed, and running at frequencies other than 72MHz has not been extensively tested.
BTW. I recall someone else posting a similar question, but I think they may have been using an even higher frequency crystal
[Pito – Sun Dec 31, 2017 5:03 pm] –
It may work when you do in Arduino_STM32/STM32F1/cores/maple/libmaple/rcc_f1.c line 107:
RCC_BASE->CFGR = pll_src | pll_mul | (0x3<<22) | (0x1<<17);
(it would be better if the modification can be done in some of the files in my added variant folder instead of modifying core files)
There is the RCC_CFGR_PLLXTPRE defined in the F1 rcc.h, but not used.
It must be added into the core in order to use it in your variant (boards_setup.cpp), it seems..
[BlackBrix – Mon Jan 01, 2018 7:11 pm] –
Do you think it could be added to the core?
… Why should the core be changed for a one-off initiative?
The question would be if the forum wished to fully support the referenced board, the way we do Black, Blue, Red, and Maple Minis.
Example: http://wiki.stm32duino.com/index.php?title=Blue_Pill
I am pleased you have your unit functioning with a 16MHz crystal and this thread will document how you achieved the solution. Please feel free to ask for WiKi privileges and document the over-clocking. However, core changes introduce many problems even for things that seem overly simple as can be seen from the number of roll-backs last year.
My recommendation is just to use a Post Note-it to remind yourself to make a local change to your system everytime you update your PC from the master github.
Ray
externalize it from the core ?
could it made in such a way that the cores use c.f a linked library, built simply on the crystal frequency.
new year, new ideas, ok maybe 
stephen
[mrburnette – Mon Jan 01, 2018 11:41 pm] – It is absolutely prudent that all members understand that this forum is a private venture, not commercial, is sponsored and maintained essentially by one human being who does strive to “have a life” beyond the forum.
yeah,
I absolutely agree and understand that *thumbsup*
[mrburnette – Mon Jan 01, 2018 11:41 pm] – Or, create a parallel github branch and sync only as needed…
yes you’re right, I did that already.
(although I do not (yet) have any knowledge at all about using git/github the right way 
)
.
.
zmemw16 wrote:can we invert this and ask how to make it such it could be applied to any platform ?
externalize it from the core ?
In the \STM32F1\variants\generic_stm32f103v\wirish\boards.cpp there is (line 129)
// Configure AHBx, APBx, etc. prescalers and the main PLL.
wirish::priv::board_setup_clock_prescalers();
rcc_configure_pll(&wirish::priv::w_board_pll_cfg);
I will check that out …
[edit] there’s only one additional line needed,so the final solution is (in “..\STM32F1\variants\YOUR_BOARD\wirish\boards.cpp”):
// Configure AHBx, APBx, etc. prescalers and the main PLL.
wirish::priv::board_setup_clock_prescalers();
rcc_configure_pll(&wirish::priv::w_board_pll_cfg);
#ifdef XTAL16M
// 16MHz crystal (HSE)
// in this case we additionally set the Bit 17 (PLLXTPRE=1) => then HSE clock is divided by 2 before PLL entry
RCC_BASE->CFGR |= RCC_CFGR_PLLXTPRE;
#endif
RCC_BASE->CFGR = cfgr | RCC_CFGR_PLLXTPRE;
RCC_BASE->CFGR |= RCC_CFGR_PLLXTPRE;I edited my post above accordingly …
i have added this line for 16MHz, it worked
RCC_BASE->CFGR |= RCC_CFGR_PLLXTPRE;
Can you help for 12 MHz, as i want to run my system on it.
Done with 12Mhz also,
found help from https://github.com/rogerclarkmelbourne/ … _setup.cpp
I observed my PLL multiplier was at 3 which gives clock peripherals as 36Mhz
I have done PLL multiplier as 2, so PLL runs at 24 MHz now. and works all peripherals fine now.
You would need to multiply by 6
I am not sure if the actual values you write to the Pll control register for either Pll multiplier
