I am developing for a project an STM32 Cortex processor, using gcc on 
Eclipse. Initially I am working with the ST Electronics 
STM32F10x-128K-EVAL demo board, which included an LCD display and a 
joystick.

I need to reset the backup domain, so I want to pulse bit 16 of the RCC 
backup domain control register.  I have a macro definition to access 
this bit using bit banding.

In my code I included two consecutive lines:

  RCC_BDRST = 1;
  RCC_BDRST = 0;

If I set the optimisation to -O0 or -O1 the code compiles and functions 
correctly, but inefficiently.  The machine code loads r3 with the 
bit-banding register address (0x42420440), then loads r2 with 1, writes 
r2 to address r3, then again loads r3 with 0x42420440, loads r2 with 0 
then writes r2 to address r3.

Not only is this inefficient, at these level of optimisation for some 
reason the processor is unable to write to the LCD display.

If I change the optimisation to -Os the processor is able to write to 
the display, but no machine code is generated for the instructions 
above.

If I change the optimisation to -O2 the processor is unable to write to 
the display, and again no code is generated for the instructions above.

It seems to me that in the process of optimising the code, gcc sees that 
the overall effect of the above two line of code is to have no change to 
the initial state of the relevant flag, so it skips them.  This is 
obviously not right.

According to the gcc manual the various optimisation levels activate 
different combinations of optimisation flags.  Obvioulsy one of these 
affects the code that interfaces to the LCD display, and another 
inhibits implementation of the desired reset code.

I guess I could leave the optimisation at -O0 but include all the flags 
that would be invoked by -Os, then delete one flag at a time until I 
find which are responsible for the two problems.  Does anyone have any 
other suggestions?

You need to use the volatile keyword in the definition of RCC_BDRST to 
tell the compiler that it must not remove accesses to this variable.

That's solved my problem.  It's easy when you know how!

I must thank you sincerely for your prompt response

Since the behaviour of the code you posted would be entirely dependent 
on the definition of the macro, you should have posted the definition. 
Just showing the un-preprocessed code tells us nothing.

I would have 'guessed' the same solution as Andreas given the symptoms, 
but it was still a guess (albeit an educated one), you got lucky.

> This is obviously not right.

No, actually that was exactly right. Some useful reading for you: 
http://www.embedded.com/story/OEG20010615S0107

Clifford