Problem with STM32F105VC using 8MHz crystal

[Fristedt.Jan]

Posted on July 15, 2011 at 19:58

Hi,

I have spent the better part of the day trying to get code that run perfectly on an STM32F107VC using a 25MHz crystal to run on an STM32F105VC with an 8 MHz crystal. We are using v3.5.0 of the library from ST.

Changing the HSE_VALUE either directly in the header file or via a definition get the UARTs (or at least the one I have tested) to run at the correct speed. The problem is the timers that run a factor 25/8 slow. The value of the SystemCoreClock variable is set to 72MHz by SystemInit(), as expected.

Any help available?

TIA

/Janne

#hse_value-external-clock-connectivity-line #utsl

[Tesla DeLorean]

Posted on July 15, 2011 at 20:50

Probably because system_stm32f10x.c has stupid code like this for the ''STM32F10X_CL'' which presumes HSE = 25 MHz, correct ALL of these and it'll work fine.

    /* PLL2 configuration: PLL2CLK = (HSE / 5) * 8 = 40 MHz */

    /* PREDIV1 configuration: PREDIV1CLK = PLL2 / 10 = 4 MHz */

    RCC->CFGR2 &= (uint32_t)~(RCC_CFGR2_PREDIV2 | RCC_CFGR2_PLL2MUL |

                              RCC_CFGR2_PREDIV1 | RCC_CFGR2_PREDIV1SRC);

    RCC->CFGR2 |= (uint32_t)(RCC_CFGR2_PREDIV2_DIV5 | RCC_CFGR2_PLL2MUL8 |

                             RCC_CFGR2_PREDIV1SRC_PLL2 | RCC_CFGR2_PREDIV1_DIV10);

[raptorhal2]

Posted on July 15, 2011 at 20:51

I am guessing that you are connecting the HSE directly to SYSCLK instead of passing it through the PLLCLK where the 8 MHz is multiplied to get the SYSCLK frequency. Note that 25 is not an integer multiple of 8, so you will have to readjust the timers anyway.

The USART frequencies are automatically adjusted for SYSCLK frequency, which is why everything is wonderful there.

If the above is not the answer, post your code so that we don't have to guess anymore.

Cheers, Hal

[Tesla DeLorean]

Posted on July 15, 2011 at 21:01

The system is almost certainly NOT running at 72 MHz. The USART's work because the library works the math backward on actual the PLL setting and the HSE_Value, no doubt computing that your system is, in fact, running at 23.04 MHz

Try printing the value out

RCC_ClocksTypeDef RCC_ClocksStatus;

RCC_GetClocksFreq(&RCC_ClocksStatus);

printf(''%d %d %d\n'', 

RCC_ClocksStatus.SYSCLK_Frequency,

RCC_ClocksStatus.PCLK1_Frequency,

RCC_ClocksStatus.PCLK2_Frequency);

[Fristedt.Jan]

Posted on July 15, 2011 at 22:20

Thank you both for your replies. I guess this is what happens when you try to be ''modern'' and reuse canned code. I will try to get it up and running tomorrow.

I completely agree that the library is full of stupid code. And what's the point of having a variable with the system frequency when you can't trust it? And when it's not used in other library code.

Thanks again, I will report back tomorrow.

/Janne

[Fristedt.Jan]

Posted on July 16, 2011 at 09:58

Problem solved! Thank you for your help!

If anyone is interested I have an ugly fix.

/Janne

[mschwab]

Posted on August 06, 2011 at 01:46

Most of the evaluation boards for the Connectivity Line use 25 MHz crystals.  Does anybody know why?  Does that come out to better frequencies for USB OTG or Ethernet or something?  It sure makes you do some funny math with PPL2 (/5 x8 /5) just to get back to 8 MHz!

Otherwise, we'd rather standardize on 8 MHz crystals for both CL and XL parts.

[donald2]

Posted on August 06, 2011 at 02:01

That it's only frequency that allows both Ethernet and USB to run at the correct speed.  Even just using Ethernet, you pretty much need a stable 25MHz clock.