__STREXH problems on STM32 with GCC optimization settings

[hermanv]

Posted on October 03, 2012 at 15:20

Hi all,

I know there are other posts that address the issues regarding __STREXH and __STREXB on the STM32, but the answers provided does not solve all the problems involved.When I build the STM32 Standard Peripheral library with optimization set to anything other than -O0, I get the following errors:..\Temp\ccFeqMNJ.s:319: Error: registers may not be the same -- `strexb r0,r0,[r1]'..\Temp\ccFeqMNJ.s:334: Error: registers may not be the same -- `strexh r0,r0,[r1]'The obvious fix is to change the

 ''=r'' (result)

part of the code to 

''=&r'' (result)

. Then all optimization levels work and all seems fine, until you try to write to the onboard FLASH of the STM32 device. The pages can be erased, but not written to. Also, no fault registers are set to inform you of what is the problem. Only when I changed the __STREXH and __STREXB code back to its original state and changed the optimization back to 0 all worked again.Can anyone explain this to me?I would like to optimize the code for size but this is not allowed as per my discussion.Thanks,H #gcc #arm-cortex-m3 #flash

[Tesla DeLorean]

Posted on October 03, 2012 at 15:57

I've been using GCC 4.6.2 to compile the libraries (F2 and F4) with -Os and -O3 without the compiler throwing fits about it.

Compiling file: stm32f2xx_flash.c
arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O3 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes
-Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/stm32f2xx_flash.lst -DUSE_STDPERIPH_DRIVER
-DSTM32F2XX -DUSE_STM322xG_EVAL -DHSE_VALUE=25000000 -MD -MP -MF out/stm32f2xx_flash.d -I. -ICommon
stm32f2xx_flash.c -o out/stm32f2xx_flash.o

C:\>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: arm-none-eabi
Configured with: ../gcc-4.6.2/configure --target=arm-none-eabi --prefix=/home/yagarto/install
--disable-nls --disable-shared --disable-threads --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2
--enable-languages=c,c++ --enable-interwork --enable-multilib --with-newlib
--with-headers=../newlib-1.0/newlib/libc/include --disable-libssp --disable-libstdcxx-pch
--disable-libmudflap --disable-libgomp -v
Thread model: single
gcc version 4.6.2 (GCC)

You will need to be more precise about which version, options, and setting being used that manifest this issue. If there is a specific code generation issue, then you'll need to generate some listings of the offending code and walk through it. If it's just a matter of erasing and writing flash, that's fairly well contained. I doubt this is an STM32 limited issue, you perhaps would be better discussing this on a GNU/GCC specific mailing list once you can provide an exemplar that clearly demonstrates the code generation issue, and the architectural failure that results.