Incompatability between FWLib 2.0.3 and GCC 4.1.1

[darcy]

Posted on March 05, 2009 at 04:13

Incompatability between FWLib 2.0.3 and GCC 4.1.1

[mhindi]

Posted on May 17, 2011 at 13:04

We have GCC 4.3.2 version. No problem as far we tested. The code generated with ''volatile'' is equal to that one without.

[darcy]

Posted on May 17, 2011 at 13:04

Hi all,

We appear to have found an incompatability of sorts between the ST firmware library and GCC. The whole issue seems to be based around the way in which the firmware library declares the peripheral structure pointers e.g.

stm32f10x_map.h

#define RCC ((RCC_TypeDef *) RCC_BASE) //Line 905

typedef struct //Line 426

{

vu32 CR;

vu32 CFGR;

vu32 CIR;

vu32 APB2RSTR;

vu32 APB1RSTR;

vu32 AHBENR;

vu32 APB2ENR;

vu32 APB1ENR;

vu32 BDCR;

vu32 CSR;

} RCC_TypeDef;

When code is compiled with optimisation enabled, the volatile nature of the structure members is ignored. The result is that the compiler treats the members as non-volatile... which produces all kinds of problems. An example of this problem is described in another thread

http://www.st.com/mcu/forums-cat-7515-23.html

We have just verified that by changing the object declaration to volatile that this resolves the issue. e.g.

#define RCC ((volatile RCC_TypeDef *) RCC_BASE) //Line 905

This could present serious issues when checking peripheral flags from a loop when optimisation is used. If the registers are not treated as volatile then this will lead to all kinds of potential problems.

When compiling in DEBUG mode with optimisation turned on (just for kicks) the problem does not occurr. In this case the variables are declared differently in the map file

EXT RCC_TypeDef *RCC; //Line 1146

When declared in this fashion we don't have a problem.

STOne-32, could you please have a look in to this?

Is this an issue with GCC itself incorrectly handling the volatile structure members? Or should the library be declaring the definitions as volatile pointers?

[darcy]

Posted on May 17, 2011 at 13:04

Yep, without turning on optimisation you won't notice a thing.

One thing that makes me uncertain is that the struct members are clearly specified as being volatile yet the compiler doesn't treat them that way.

[trevor1]

Posted on May 17, 2011 at 13:04

Hi mhindi,

Are you using the same optimisation level?. Volatile is largely ignored until the optimiser comes into play.

Trevor

[darcy]

Posted on May 17, 2011 at 13:04

Quote:

Have you tried adding volatile qualifiers to the overall structures?

(I was going the other way: I started with a pragma on my overall file, then added volatile qualifiers to my structures, then had to add volatile qualifiers to the individual structure members! :| )

Crikey, at least we know this isn't an isolated occurrance. I would rather avoid modifying the libraries themselves as it does rather defeat the purpose of using the libraries in the first place... In saying that, I can't see any other way to resolve this. Thanks for the input

[st3]

Posted on May 17, 2011 at 13:04

Quote:

One thing that makes me uncertain is that the struct members are clearly specified as being volatile yet the compiler doesn't treat them that way.

I have had problems with GCC disregarding volatile qualifiers in an unrelated environment (still ARM, but not ST or Cortex).

Have you tried adding volatile qualifiers to the overall structures?

(I was going the other way: I started with a pragma on my overall file, then added volatile qualifiers to my structures, then had to add volatile qualifiers to the individual structure members! :| )

[budde2]

Posted on May 17, 2011 at 13:04

Hi Darcy,

we have got the same problem using the Rowley Crossworks IDE (based on gcc).

See:

http://www.st.com/mcu/forums-cat-7773-23.html

[st3]

Posted on May 17, 2011 at 13:04

I'm sorry - I seem to have had a major memory failure there!

It was the ''packed'' qualifier I was trying to use - not volatile.

But maybe this just goes to show that GCC has a general problem with applying qualifiers to structures...?