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
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.