STM32F103RB - Different Clock Speed Between Reset?

[i_]

Posted on March 02, 2014 at 15:43

Afternoon all,

I am having some problems with clock rate setting on the stm32f103 and I am hoping you can point me in the correct direction. (I think this is a very simple problem!). First up I do not have a scope on me at the moment to check the clock out pin. Hopefully I will be able to check this soon. Anyway the problem. I have a board that uses an Xbee radio for wireless comms. Some simple code I have setup (And working) prints wirelessly to terminal Buad rate set in code to 9600. This works perfectly after flashing the board and the xbee transmits perfectly. However, when I do a power reset on the board the Xbee begins communicating incorrect data (common problem I have seen with having the baud rate set wrong). I assume this is because on 'startup' the board is/isn't setting the clock speed correctly and since the buad rate is calculated using this it is causing problems. Am i missing something obvious? On my stm32f100rb (discovery board), I do not seem to have this same issue. Thanks all, any advice is much appreciated. Iam

[Tesla DeLorean]

Posted on March 02, 2014 at 16:45

Perhaps the external crystal on your board isn't starting reliably? You could modify the clock/pll configuration in system_stm32f1xx.c (SystemInit) to use the HSI (8 MHz, 4 MHz into PLL) as the clocking source. You could also check the RCC bits related to the HSE and PLL. Without a scope you could toggle an LED via a TIM or SysTick based on expected clocks at 1 Hz, and then see if it's wildly off by eye.

[i_]

Posted on March 02, 2014 at 16:49

On some reboots I seem to 'luck into' the correct frequency and the Xbee communicates properly. (further testing)

Not quite sure what is going on here. I have a 8Mhz external osc connected just like with the discovery board.

[i_]

Posted on March 02, 2014 at 17:01

Thanks Clive,

A good suggestion. I will try this now. Why would it work fine 100% after programming though?

[i_]

Posted on March 02, 2014 at 17:15

Putting a delay in code between transmits seems to fix the problem.

Thanks for the help, I will check with a scope when I am able to get access to one.

[Tesla DeLorean]

Posted on March 02, 2014 at 17:21

Why would it work fine 100% after programming though?

Hard to say, you'd have to do a bunch more diagnostic work to understand/explain how the part was starting in the two conditions, and what the xbee is doing in these conditions.

[Andrew Neil]

Posted on March 31, 2014 at 15:52

''Why would it work fine 100% after programming though?''

Because that doesn't involve a power-cycle, perhaps?As clive1 says, you need to do some more investigation;  but perhaps you external crystal only starts oscillating some considerable time after power-up - so that the chip uses the internal oscillator instead...?

[Andrew Neil]

Posted on March 31, 2014 at 15:54

Someone else with an apparently similar issue:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Wrong%20STM32%20clock%20at%20startup&currentviews=3