Guide for under- and over-clocking the blue-pill needed

Dear experts,

I would need a step-by-step guide for over- and under-clocking.
Although I have found here and here some relevant info, but it is only partial, I don’t have a complete picture about:
– where to change CPU clock? Are flash wait-states involved in final CPU operating speed? How?
– where to change peripheral (SPI, GPIO?) clock? Is it related to changing CPU clock? How?
– can I decrease flash wait-states (to zero maybe) if I under-clock to 48MHz?
– under which circumstances (which CPU/peripheral clock combinations) is USB still working?

Example:
– would it be possible to underclock to 48MHz, decrease flash-wait states (to zero?), set SPI to 24/48 MHz ?

I would greatly appreciate if someone could collect and post this (and more?) info here and/or on wiki.

@stevestrong,

See my other post to your question.

USB will only for for 72Mhz and 48Mhz (and you need to change the USB divider)

See the GD32 for how to set the CPU frequency and still have the tick etc work OK (I think the tick code should actually be fine now as I made it dependent on F_CPU months ago)

SPI etc are a different matter, as they are just divisions of the main clock freq.

Wait states… Depends on how hard you want to push it. But I don’t think its guaranteed to work with less wait states than it already uses on 72MHz

OK, here it is what I have found out so far:

CPU PLL frequency is set up in “/variants/[your_board]/wirish/boards_setup.cpp”.
For BP it is https://github.com/rogerclarkmelbourne/ … _setup.cpp.

Btw, I think there is a bug in line 74: the divider for USB at 48MHz main clock should be RCC_USB_SYSCLK_DIV_1, right?

The value of F_CPU is set in platform.txt, as build parameter
build.f_cpu=72000000L

i don’t know if you’ve used stm32cubemx already, but if you haven’t, you should download it .
It’s not only useful for generating code, but also gives great overviews of the microcontrollers. The interface has a seperate screen just for the entire clock configuration of the microcontroller you chose, and you can play around with the values and it’ll show where there are conflicts, but also show the consequences of the values you chose (such as how the peripheral clocks change etc..)
It makes exploring the over/underclocking options of an stm32 a lot easier . and then you also know which clock setting you have to set to what to achieve the result you configured in the cubemx .

My 103ZET6 (default ws):
Starting Whetstone benchmark…
Loops: 1000Iterations: 1Duration: 20366 millisec.
C Converted Double Precision Whetstones: 4.91 MIPS <<< 72MHz

Loops: 1000Iterations: 1Duration: 15250 millisec.
C Converted Double Precision Whetstones: 6.56 MIPS <<< 96MHz

Loops: 1000Iterations: 1Duration: 12201 millisec.
C Converted Double Precision Whetstones: 8.20 MIPS <<< 120MHz

Loops: 1000Iterations: 1Duration: 11438 millisec.
C Converted Double Precision Whetstones: 8.74 MIPS <<< 128MHz

Dhrystone Benchmark, Version 2.1 (Language: C) <<< 128MHz
Execution starts, 300000 runs through Dhrystone

Execution ends
Microseconds for one run through Dhrystone: 7.28
Dhrystones per Second: 137397.93
VAX MIPS rating = 78.20

Should flash wait states have an effect on GPIO toggling speed?
Because I tried to toggle one GPIO pin at different flash wait states (0, 1 and 2) here.
The result: no change!

Is this normal?
What am I doing wrong?

It could happen when the core uses cache or a multi-stage-pipeline and your toggle insts are close together.
Not sure it happens with 103, however

I am assuming that the GPIOs are directly driven by the CPU core, as I could not detect any clock group which would be supposed to drive the GPIO pins. And as long the CPU executes the instructions dependent on the core clock and the flash wait states, I would expect to have different GPIO toggle periods for different wait states.
But somehow my theory seems to be wrong.

Interesting pictures
https://vjordan.info/log/fpga/stm32-bar … speed.html

Yes, it does discuss the toggling at no setting and 2 flash wait states. The difference is about 20%.

Me, I cannot observe any difference in behavior between wait states 0, 1 and 2, I always get ~12MHz at 48MHz CPU, that’s my problem here…
I doubt now whether the flash wait states are indeed set as I expect.

You really have to look at the assembler code that is setting the GPIO to determine if it is going to be any different.

stevestrong wrote:Dear experts,

I would need a step-by-step guide for over- and under-clocking.
Although I have found here and here some relevant info, but it is only partial, I don’t have a complete picture about:
– where to change CPU clock? Are flash wait-states involved in final CPU operating speed? How?
– where to change peripheral (SPI, GPIO?) clock? Is it related to changing CPU clock? How?
– can I decrease flash wait-states (to zero maybe) if I under-clock to 48MHz?
– under which circumstances (which CPU/peripheral clock combinations) is USB still working?

Example:
– would it be possible to underclock to 48MHz, decrease flash-wait states (to zero?), set SPI to 24/48 MHz ?

I would greatly appreciate if someone could collect and post this (and more?) info here and/or on wiki.

victor_pv wrote:
On toggling pins, GPIO is not affected by wait states, neither RAM or any other peripheral, only flahs, BUT, if the code toggling a pin is in flash, it may be slower as you add wait states, but again since the flash ready 128bits at once, if it is a very tight loop that falls within 4 instructions, you may end up with a single flash read every 4 instructions. On the other hand, if you jump back and forward, and force 1 flash read for every 1 or 2 instructions, the wait states will impact you.

@stevestrong

Yes. I think there is probably a bug with the USB divider setting for 48MHz

It should be set to DIV 1

On the GD32 I was fo focussing on the higher speeds and may have not fully tested the 48MHz option

However I am not sure whether anyone would use the 48MHz option.

I did some tests on a project which needs to run from a battery, and do pulse timing, using millis() .

So I tried running the Maple Mini at 48MHz, to see if the current consumption is lower, and it is about 1/3 less current than at 72MHz.

But this was not low enough for me, so I ended up dropping right down to 8MHz and loosing USB, and this dropped the current by about 90%

Hence, I concluded that the 48MHz option would probably not be used by anyone, as I could not see any benefits; because if the board is running from USB, then saving 10mA is not likely to be important.

What is probably more important is overclocking, but as it kills USB, perhaps it would be better to have a function to set the overclocking speed, and perhaps force USB reset when returned to 72MHz

Overall however, as the F4 boards are now becomming a lot cheaper and STM’s F4 core will be here some time this year, I hope , anyone wanting higher speeds would be better of overclocking an F4 board.

RogerClark wrote:
Overall however, as the F4 boards are now becomming a lot cheaper and STM’s F4 core will be here some time this year, I hope , anyone wanting higher speeds would be better of overclocking an F4 board.

You can remove dust on your F4 by simply using our own F4 core …

martinayotte wrote:You can remove dust on your F4 by simply using our own F4 core …

@Roger, I’ve never got issue with DFU, maybe it is because I’m on Linux.

Martin

Yes. Linux seems to work OK, but Windows doesn’t work unless you use STM’s own GUI tool and their special drivers.

Then, you should do what Ray did a year go : switch to Linux and forget crappy MS Windows …
I’m still running WinXP/WinVista/Win7 but inside VMs, so if you still need Windows for your consultant contracts, maybe that solution could fit your needs.

RogerClark wrote:[…] and that version does not have a CLI, or take binary files (arrrgghhh)

stevestrong wrote:..Because I tried to toggle one GPIO pin at different flash wait states (0, 1 and 2) here.
..

F407 – overclocking – I did in past (F4Discovery) but the chances for such an overclock like the F103 (1.77x) are minor.
The max I got was 210MHz (1.25x). Hopefully my Disco has got a crappy 407 chip on it and the others work higher .
In the meantime there are F4xx at 200MHz standard speed. In the Q2 this year this
http://www.st.com/en/microcontrollers/s … tId=SS1951
should be available, 400MHz.

edogaldo wrote:RogerClark wrote:[…] and that version does not have a CLI, or take binary files (arrrgghhh)

I’ve updated the core and pushed a change so that the generic F103C and the Maple mini can select CPU speed of 72Mhz or 48Mhz, both of which still maintain USB.

We could add more options for higher clock speeds, but USB will stop working, so I don’t know whether its something that is worth adding to the core / boards.txt as it adds even more complication

I suppose we could add more #ifdef’s for higher CPU speeds and if anyone wants them, they would just need to change their boards.txt file, but I don’t know what RCC PLL multiplier are worth adding e.g. I don’t see much point in adding a setting for 80Mhz or 88Mhz as this would not give a big speed boost, so it would need to be at least 96Mhz

That was my original idea: to have a place where it is shown what to do (step-by-step for dummies like me) if one needs to over(/under)clock…
This makes any further change in repo obsolete, even more because then the USB upload would be not functional, causing more headache then solving problems, as you said.
We could maybe add the collected info to a wiki page.

I think for hobbyist it could be interesting to have those overclocking options in the menu, even when USB serial will not work.
The speeds 96, 128.
You may add to the menu description “(oclkd, noUSB)” or something like that.
The Q is how many do use USB serial actually.

@pito

The problem with No USB, is that there is No Reset to upload.

I am sure that if overclocking with Reset not working, was on the menu, I would get all sorts of direct emails and bug reports on github, and messages via youtube.

So its safer to do as @stevstrong has suggested, and document how to overclock, but not put it on a menu where inexperienced users can select, something which makes their system non functional.

The problem with No USB, is that there is No Reset to upload.
Yes, that I noticed too – I wanted to shot an utube video on the issue, but then I pulled out/in the usb plug while uploading sketch and it uploaded fine

Pito wrote:The problem with No USB, is that there is No Reset to upload.
Yes, that I noticed too – I wanted to shot an utube video on the issue, but then I pulled out/in the usb plug while uploading sketch and it uploaded fine

RogerClark wrote:
So its safer to do as @stevstrong has suggested, and document how to overclock, but not put it on a menu where inexperienced users can select, something which makes their system non functional.

Guys, I have a strange behavior here.
I follow the guide to set the CPU to 80MHz, only using different settings in boards.txt, restarting the IDE each time, having correct multipliers for RCC
#if F_CPU==96000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_12
#elif F_CPU==88000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_11
#elif F_CPU==80000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_10
#elif F_CPU==72000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_9
#elif F_CPU==64000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_8
#elif F_CPU==56000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_7
#elif F_CPU==48000000
#define BOARD_RCC_PLLMUL RCC_PLLMUL_6


@stevstrong

I think you’d need to test the speed in some other way, e.g. toggle a gpio in loop or perhaps run the dhrystone test to confirm CPU clock frequency.

I think Pito successfully overclocked his STM32’s. I’ve definitely done it with the GD32 and looked at the dhrystone test to confirm it

OK, so the CPU frequency seems to be the one set, bit toggle checked with scope.
The SPI frequency does not. The funny thing is that it worked before I tried to play with the flash wait states.. is the pill tired?

OK, it’s me…
I only forgot to change the frequency in the SPI.beginTransaction() part…
So I better go sleep now, before I “invent” some other non-existing self-generated issues…

Yes, my 103ZET6 has been working few days 128MHz fine. Even from EXRAM.
When you change F_CPU, the SPI clock must change when the sketch’s SPI settings are left untouched.
Mind the 36MHz SPI is already “overclocked”. So 64MHz SPI with 128MHz F_CPU will most probably not work – try.

36 MHz SPI_1 is “normal”, and it works.
Pito wrote:So 64MHz SPI with 128MHz F_CPU will most probably not work – try.

Fantastic
Now, how to force my Sdcard to follow

Pito wrote:Fantastic
Now, how to force my Sdcard to follow

Nope, in past the Reset button solved all the problems..
Yea, I can remember that button too, not sure my Sdcard does..

Few months back I had a good discussion with BillG (SdFat’s author) and I pushed him to introduce CMD6 command (switching high speed mode on) for the new Sdcards (like CL10, UHS-I), but at the end of the day he decided not to do as the cards can work 50MHz without CMD6 (moreover we did not see the CMD6 to be really switched on). He also claimed somebody ran Sdcard at 80MHz with ESP8266..
So we must elaborate, 64MHz SPI with an sdcard could be nice to have