Overclocking STM32F103

This post is actually a continuation of one begun back on the old Arduino.cc forum:
http://forum.arduino.cc/index.php?PHPSE … msg2188003

Relevant posts that I have found via trickle-down links: message to message to message…

Leaflabs, 5+ years old
http://forums.leaflabs.com/topic.php?id=31

TKJ Electronics, 5+ years old
http://blog.tkjelectronics.dk/2010/02/s … rclocking/

bnewbold, gist, 2.5 years ago:
https://gist.github.com/bnewbold/407140

This is the first time this subject has been listed on the new forum, mainly I just wanted to capture the older references in the event anyone decided to bring up the topic again; TKJ’s URL was incorrect, I was able to track down his main site and do a search off that site to the blog post. One day if I’m feeling particularly radical, I may give this a go

Ray

Interesting !

AFIK

The big problem with overclocking is that USB doesnt work if you overclock, because there doesnt appear to be a way to configure the 48Mhz clock signal for USB if the main clock is anything other than 72mhz or 48mhz

So it seems possible to underclock and run USB but not overclock.

This is because the USB clock prescaler only has 2 possible values, no division or divide by 1.5

I suppose some people may be happy with a small amount of extra performance and live without USB.
I dont know if it would be possible to have a short term “Nirto boost” type mode, where the USB went off for a while without the host system noticing ?

Underclocking may be potentially more useful in power power applications, as 48mhz is still a lot faster then AVR devices, an you still get the benefit of the extra RAM and flash.

(i note in another thread someone thinking of building a watch using a STM32, so low power may be beneficial to stuff like that)

if we can swicth to SloMo at any time then back again with no side effects, it seems a usefull addition.

THIS COULD BRICK YOUR BOARD! OVERCLOCKING IS A HACK NOT A FEATURE!—> found here: https://gist.github.com/bnewbold/407140
blablabla –> only overVOLTAGE can harm your board
I do overclock my pic32mx250 every time from 40mhz to 48mhz, because I’m lazy —> 48mhz = USB clock and a odd audio frequency for I2s.
So 128MHZ should be possible. Here at Vienna we have about 38 centigrade, perfect temperature to stress overclocked board in the sun.
don’t forget to change the system clock define (720000) in stm32.h or somewhere else (can’t remember) or your peripherals run mad.

edit: an yes, Roger warned about USB

Wouldnt overvoltage be dumb as they would die with more than 3.6V?

~Straw

Wouldnt overvoltage be dumb as they would die with more than 3.6V?

No, not really, you only need some coolings with liquid nitrogen or similar

Next big thing : water cooling Blocks for MCUs. In a kit With 360mm Rads

~Straw

I guess ahull has a passive solution with very hot cold glue for it

madias wrote:I guess ahull has a passive solution with very hot cold glue for it

Only 10 Heatpipes? Way too less

~Straw

*ROFL*
With this “building” into a marshall valve combo you wont have the “volume 11”, but the “volume 13” at minimum
https://en.wikipedia.org/wiki/Up_to_eleven

You could of course also bolt on a fan

With all this GD32F103 speed daemon talk, I thought I’d try pushing my chips a little. I was surprised no one has mentioned how to output the clock to verify what speed you are running. You can output the PLL clock divided by 2 on PA8 if you use the following:

// configure PA8 to output PLL/2 clock
gpio_set_mode(GPIOA, 8, GPIO_AF_OUTPUT_PP);
*(volatile uint8_t *)(0x40021007) = 0x7 /*MCO_Config(PLL/2)*/;


oh wizard, from whence did the 0x40021007 come?

stephen

RCC_CFGR

look in the rm0008 reference manual bits 24:26
it was on page 98 I found the address in spl headers

Rick Kimball wrote:RCC_CFGR

look in the rm0008 reference manual bits 24:26
it was on page 98 I found the address in spl headers

I wasn’t worried about it , but I seriously doubt it. BTW 0 wait states locked it up

zmemw16 wrote:oh wizard, from whence did the 0x40021007 come?

stephen

Rick Kimball wrote:
I You do have to change some defines regarding systick and microsecond counting..

-rick

Update
This works

#define STM32_DELAY_US_MULT (F_CPU / 3000000)

Sorry. I don’t think it works, but there must be a way to get something like this to work

Rick Kimball wrote:With all this GD32F103 speed daemon talk, I thought I’d try pushing my chips a little. I was surprised no one has mentioned how to output the clock to verify what speed you are running. You can output the PLL clock divided by 2 on PA8 if you use the following:

// configure PA8 to output PLL/2 clock
gpio_set_mode(GPIOA, 8, GPIO_AF_OUTPUT_PP);
*(volatile uint8_t *)(0x40021007) = 0x7 /*MCO_Config(PLL/2)*/;


Victor,

I’m fairly sure I tried setting the main PLL to its maximum setting of 16 x and the red pill still worked … at least for a while

The PLL setting is in one of the boards variant files (I can’t remember which one as all the names are similar), just look for the definition that has xxx MUL_9 and change it to MUL 16. But all you can test is blinking as serial will be going at the wrong rate as well USB

victor_pv wrote:So 0 wait state crashes it, what about going any faster than 96? does it have multipliers for more? and if it does, it runs or crashes?

Rick Kimball wrote:victor_pv wrote:So 0 wait state crashes it, what about going any faster than 96? does it have multipliers for more? and if it does, it runs or crashes?

I get the impression that the GD32 is being produced using using a better fabrication plant than the STM32.

I’ve also seen something that mentions the core voltage is lower, but also that the range of voltages that the chip will operate over is a narrower band.

The Flash memory is almost certainly, completely, different. They mention millions of write cycles in their blurb, so I imagine the technology for their flash is different than in the STM32 and it has much faster read access as well as many times more erase cycles. This isn’t so surprising as GigaDevices seem to be a memory manufacturer, so I suspect they just use the same memory they designed for other stuff and combined it with the STM32 silicon design.

With the STM32, on most of the boards available at the moment, you’ll be limited to 128Mhz as thats the highest PLL multplier available (16 x ) of 8Mhz.

But if anyone has a 12Mhz crystal kicking around, you could swap it for the existing 8MHz, and just change the main PLL multplier to 6 (at least to start with), then push it the PLL multipler up to 192 (I don’t think it will go that fast as I don’t think my GD32 went that fast when I tried it)

What I guess I should do, is put the improvements I did for the GD32 in terms of setting the systick stuff to the correct value based on F_CPU rather than being hard coded just for 72Mhz, as it would then be easy to have menu for speed e.g. 72Mhz or 48Mhz, or to push it above that if people were happy to loose the USB functionality

I just tried 48Mhz, 128Mhz and a few speeds in between, and as far as blinking the led, everything works, but apparently nothing that I do changes the multiplier for the USB port.

I tried to set the USB prescaler to 1, and the pll for 6, to get 48Mhz, and usb, but did not work.
I am not sure if I did something wrong or what, but right now I am unable to communicate with the usb port even after returning the pll to x9.
The bootloader works, so I know I my usb peripheral does work.

Was anyone ever able to set the usb prescaler to /1 and run an STM32 at 48Mhz?

Hi Victor

Are you using the Bootloader or STLink

It looks like the PLL startup code in the core presumes that the hardware is booting from cold, and if the PLL has already been set by the Bootloader to a different value, I was not able to get USB to work.

i.e If I compile the bootloader for 120Mhz I can run the GD32 at 120Mhz, but I can’t run the GD32 at 96Mhz as the USB doesnt seem to work.

But if I use STLink I can choose any frequency I like and USB serial works if I have a valid USB clock frequency

RogerClark wrote:Hi Victor

Are you using the Bootloader or STLink

It looks like the PLL startup code in the core presumes that the hardware is booting from cold, and if the PLL has already been set by the Bootloader to a different value, I was not able to get USB to work.

i.e If I compile the bootloader for 120Mhz I can run the GD32 at 120Mhz, but I can’t run the GD32 at 96Mhz as the USB doesnt seem to work.

But if I use STLink I can choose any frequency I like and USB serial works if I have a valid USB clock frequency

Hi Victor

Thanks.

I suspect it was something like that, but I’ve not had time to investigate

Success!!

I was writting my changes in a text file, so I can post them to you in a minute.
First of all, I applied the changes you did in the GD core to have several USB DIV options, so that is exactly as your GD core.
Then I added the functions needed in a few files to be able to disable peripheral clocks, and then before setting the prescaler, I disable the clock.

Interestingly enough, leaflabs had written a couple of funtions to enable a clock to a peripheral, but no function to disable the clock, which doesn’t make much sense to me. It comes very handy in low power applications, where you can go a disable every peripheral that your dont need to save power.
I am sure Ahull, Madias, and Ray will benefit as they are always playing with bateries (and blowing them up… ).
Anyway, let me do a sanity check, and will post you the changes.

EDIT: work fine for 48mhz div_1 and 72Mhz div_1_5.
Bit 23 doesnt seem to have any effect as div2_5 works as 1_5 (usb only works at 72mhz) and div_2 works as div_1 (only works fine at 48mhz).

So, to your GD32 core perform these changes:

To Arduino_STM32/STM32F1/system/libmaple/rcc_private.h
Added:

static inline void rcc_do_clk_disable(__io uint32** enable_regs,
rcc_clk_id id) {
__io uint32 *enable_reg = enable_regs[rcc_dev_clk(id)];
uint8 line_num = rcc_dev_table[id].line_num;
bb_peri_set_bit(enable_reg, line_num, 0);
}

Thanks Victor

I should copy my changes for the GD32 into the STM32 as they will all be beneficial.

I had to add a function to set the prescaler function and the emums etc, as it was the only way that seemed to work

I should change the stuff to do with systick as well and use F_CPU – 1 as the preload value …. etc etc

Victor

I’ve just realised, you may need to change the bootloader as well, as it will try to run at 72Mhz but may not be able to change its USB prescaler (though I’d give it a try first as the bootloader startup code is a lot different to the core, so it may be OK)

RogerClark wrote:Victor

I’ve just realised, you may need to change the bootloader as well, as it will try to run at 72Mhz but may not be able to change its USB prescaler (though I’d give it a try first as the bootloader startup code is a lot different to the core, so it may be OK)

Victor

OK.

Send me the text changes to reset the USB prescaler stuff and I’ll give it a try, as I already have it setup to run the GD32, but I can only test the various speeds if I use STLink

PS. I have quite a few changes to make sure everything works when you change F_CPU, there are some numbers associated the peripheral clocks e.g. e.g. 72000000 and 36000000 on the STM32 and the delay timing coefficient

Actually, I’ve not checked why the clock speed of the peripherals clocks is defined in the code at all. It seems a bit odd, but I thought it was safer to update everything.

But in hindsight, perhaps I should have checked if there were any referneces to APB1 and APB2 in the code, as its possible the perhipheral clock freq def’s are redundant

BTW. In the GD32 I also removed from of the stm32f2 stuff as I knew it was completely redundant

So this is something I suspect I can do in the STM32 core as well.

RogerClark wrote:Victor

OK.

Send me the text changes to reset the USB prescaler stuff and I’ll give it a try, as I already have it setup to run the GD32, but I can only test the various speeds if I use STLink

OK

I think you mean this post

http://www.stm32duino.com/viewtopic.php … t=20#p5565

Thanks

Victor

Thanks.

I’ve applied those changes to the GD32 core and they seem to work OK. i.e I can select the CPU speed from the menu and still upload via the bootloader.

I will probably change the bootloader so that its running at 96Mhz for the GD32, so that its within spec in case someone has a GD32 that won’t run at 120Mhz

I’ll try to update the STM32 stuff as well today.

Thanks

Roger

Is it correct, that I configure the PLL with

void rcc_configure_pll(rcc_pll_cfg *pll_cfg);

now in the latest stm32duino code?

So I need a object of type

typedef struct rcc_pll_cfg {
rcc_pllsrc pllsrc; /**< PLL source */

/** Series-specific configuration data. */
void *data;
} rcc_pll_cfg;

to set the pll multiplier? I there an example for the content of *data ?

TIA,
Andreas