Actual speed of the STM32F4-Discovery

[orders-st]

Posted on July 07, 2013 at 21:30

Running into some discrepancies between my code and the world. So I was operating under the assumption that the STM32F4-Discovery board was running at 168Mhz SysClock. When building the SysTick_Handler it was running way slow, so I set up a GPIO to toggle in it and used my scope to calibrate the setting, 53,760 was the result so the board is running with a SysClock of 53.76Mhz which as I've been spelunking makes sense if the on board crystal is 8Mhz (it is) and PLL_N and PLL_M are set to 336/25 respectively.

Going through trying to figure out if there is actually a way to make this run at 168Mhz or if that is a chip spec and not the EVAL board spec? The code seems to assume its running that fast which is confusing me.

--Chuck

#stm32f4-discovery-hse-hsi-timing

[Tesla DeLorean]

Posted on July 07, 2013 at 23:48

Going through trying to figure out if there is actually a way to make this run at 168Mhz or if that is a chip spec and not the EVAL board spec? The code seems to assume its running that fast which is confusing me.

You have to change it!

Of course it can run at 168 MHz, you just have to change the 25 divider that assumes an external 25 MHz source of the EVAL series boards to 8 to reflect that fact that the external clock on the STM32F4-Discovery board is 8 MHz. If I recall the part will take an external input between 4 and 26 MHz. The software has to be cognizant of these settings because it's can't figure them out by itself. The PLL requires you to have the comparison frequency between 1-2 MHz. You can play games with the settings to get the processor to run at a desired frequency, 168 MHz may not be ideal for generating other timing values that might be needed for external devices.

You also need to make sure the define HSE_VALUE is 8000000, again to reflect the reality of the system you're using. This value is used in math for computing things like baud rates.

There is actually a firmware library and examples tailored to the STM32F4-Discovery, the primary firmware/dsp library is tailored to the EVAL boards, and F4 parts in general.

[dthedens23]

Posted on July 08, 2013 at 17:27

Page 1 of the data sheet says fast I/O up to 84Mhz.

If ART can really do zero wait states (and it should be able to, with a small ASM inline code)

then you should see a pin toggle at 84Mhz.

As soon as you code in a loop, then it will be less than 84Mhz.

And, you probably cannot get there in ''C''

[Tesla DeLorean]

Posted on July 08, 2013 at 17:58

ART is pretty effective at masking the slowness of the FLASH array, a) by utilizing the much wider flash line access, and b) delivery of instruction prefetches very rapidly.

A more effective way to get the clock out would be via an MCO pin, which should easily get you 84 MHz (limited to 100 MHz on the output driver BTW)

You can get 84 MHz bit-banging the GPIO in assembler, but it's not recommended.