Change Request for stm32f10x_rcc.c in STM32FWlib

[gommel]

Posted on February 27, 2009 at 00:03

Change Request for stm32f10x_rcc.c in STM32FWlib

[darcy]

Posted on May 17, 2011 at 12:49

I've just spent the afternoon tracking down the same bloody problem! The first symptom was that all my timers were screwed and we just traced it back from there.

Details have been posted on the LPC2000 thread as obvious this didn't get any responses the first time around

http://tech.groups.yahoo.com/group/lpc2000/message/39997

Quote:

The scenario is that during power-on the Cortex M3 waits for its

oscillator to stabilise. Once done, off we go. If it fails then it

starts running on the internal oscillator. There is a particular

function in one of the library files that suffers severe problems when

optimised - resulting in the processor running on the internal

oscillator instead.

The function is found in stm32f10x_rcc.c and looks something like

this...

FlagStatus RCC_GetFlagStatus(u8 RCC_FLAG)

{

vu32 tmp = 0;

u32 statusreg = 0;

FlagStatus bitstatus = SET;

/* Check the parameters */

assert_param(IS_RCC_FLAG(RCC_FLAG));

/* Get the RCC register index */

tmp = RCC_FLAG >> 5;

if (tmp == 1) /* The flag to check is in CR register */

{

statusreg = RCC->CR;

}

else if (tmp == 2) /* The flag to check is in BDCR register */

{

statusreg = RCC->BDCR;

}

else /* The flag to check is in CSR register */

{

statusreg = RCC->CSR;

}

/* Get the flag position */

tmp = RCC_FLAG & FLAG_Mask;

if ((statusreg & ((u32)1 << tmp)) != (u32)RESET)

{

bitstatus = SET;

}

else

{

bitstatus = RESET;

}

/* Return the flag status */

return bitstatus;

}

The problem occurs specifically with the ''tmp'' variable. If ''tmp'' is

not declared as volatile then the final if condition will ALWAYS set

bitstatus = RESET. RCC_FLAG is always passed in as 0x31

This seems to us like a compiler error. I would never have thought

setting ''tmp'' as volatile would fix this as I certainly didn't think it

would cause a problem in the first place.

I'm wondering if this has something to do with the Thumb2 instruction

set?

The version of GCC currently provided with Rowley CrossStudio for ARM is

4.1.1

Hopefully someone might have an idea as to what's going on here. I

don't really want to have to modify the libraries just to fix this one

small problem as I can't help but be worried as to what else is going on

in all the other library files!

[gommel]

Posted on May 17, 2011 at 12:49

Hello,

I discovered a mysterious problem using the FWlib (2.0.3) with Rowley's latest CrossWorks/ARM.

Whenever I started a particular program in Release Mode the HSE did not start up.

I tried different things and found out that switching off the Optimization (which sas set to -O1 before) in stm32f10x_rcc.c the problem disappeared.

I re-enabled optimization and tried the ''volatile'' statement on several used variables until I found the right one.

<>

FlagStatus RCC_GetFlagStatus(u8 RCC_FLAG)

{

- u32 tmp = 0;

+ vu32 tmp = 0;

u32 statusreg = 0;

FlagStatus bitstatus = RESET;

<>

I am not sure why Rowley's GCC messes up this but I'd encourage you to add this single ''v'' letter in future releases of the STM32FWlib.

regards

Christoph Gommel

[ This message was edited by: gommel on 28-10-2008 18:38 ]