cancel
Showing results for 
Search instead for 
Did you mean: 

[SOLVED] STM32F3-Discovery: HSE never switches to ready, no 72 MHz

widemeadows
Associate II
Posted on February 21, 2015 at 04:20

I'm trying to get a STM32F3-Discovery to run on 72 MHz. I have a test project set up

https://github.com/sunsided/stm32f3-disco/tree/hse-problem

. The project is nothing fancy, basically a default project generated from GNU ARM Toolchain for Eclipse.

However, in the 

SetSysClock()

code (

https://github.com/sunsided/stm32f3-disco/blob/hse-problem/system/src/cmsis/system_stm32f30x.c&sharpL273-L280

), the loop that waits for the HSE to become ready always times out, so I'm stuck with the 8 MHz internal oscillator.

I tried 

RCC_HSEConfig(RCC_HSE_ON)

as well as 

RCC_HSEConfig(RCC_HSE_Bypass)

(which I assume is what I need), to no avail. This is on a plain F3-Discovery, i.e. only the 8 MHz osc from the ST-Link, no osc on X2.

Am I doing anything wrong?

0690X00000605ZKQAY.png

#stm32f3-discovery #stm32f3 #hse
5 REPLIES 5
Posted on February 21, 2015 at 05:48

And you have the appropriate SB (solder bridges) configured to connect the 8 MHz signal from the F103 part?

SB12 is OFF by default.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
widemeadows
Associate II
Posted on February 21, 2015 at 06:00

If I understood that correctly, SB12 should be closed, SB17 open and R33 open as well. Should be the case, this is how it looks like on my board:

0690X000006036TQAQ.jpg

R32 and R33 appear to be closed in the photo due to perspective, but are open.

0690X00000603JPQAY.jpg

Posted on February 21, 2015 at 12:52

The library has code for the bypass case

STM32F3-Discovery_FW_V1.1.0\Project\Peripheral_Examples\ADC_Example\system_stm32f30x.c

You might also what to check the signals with a scope, and direct the HSE signal out the MCO (PA8) pin, to see what the core sees.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
widemeadows
Associate II
Posted on February 21, 2015 at 15:36

Thank you so far! The ADC example code very much looks like what I did already (and I'm glad about that! :))

I tried it nevertheless just to be sure, but it didn't work, that is, didn't change anything. As for measuring the clock via PA8, I used the following code.

void
InitializeMCOGPIO() {
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
/* Configure MCO (PA8) */
GPIO_InitTypeDef gpioStructure;
gpioStructure.GPIO_Pin = GPIO_Pin_8;
gpioStructure.GPIO_Speed = GPIO_Speed_50MHz;
gpioStructure.GPIO_Mode = GPIO_Mode_AF;
gpioStructure.GPIO_OType = GPIO_OType_PP;
gpioStructure.GPIO_PuPd = GPIO_PuPd_NOPULL ;
GPIO_Init(GPIOA, &gpioStructure);
/* Output HSE clock on MCO pin (PA8) */
RCC_MCOConfig(RCC_MCOSource_HSE);
}

Note that I'm unable to set a higher clock speed than

GPIO_Speed_50MHz

and my logic analyzer only samples up to 24 MHz, so I tested with several sampling rates to rule out aliasing ... without success. With

RCC_MCOSource_HSE

there's always flatline. When I use

RCC_MCOSource_HSI

or

RCC_MCOSource_SYSCLK

instead, I can see a wobbly, but good-enough 8 MHz waveform. So, from what it appears, the F3 doesn't even get any clock from the F103?
widemeadows
Associate II
Posted on February 21, 2015 at 16:21

Humpf ... from what it seems, the R48 resistor is dead.

EDIT: Indeed it was. I replaced the R48 resistor with one I desoldered from an old scanner board and voila, 72 MHz we go. Thanks again!