SMT32F103x_XL FLASH bank 2 stays BUSY

hermanv · ‎2012-09-11

Posted on September 12, 2012 at 08:21

Hi all,

I am using an STM32F103ZG with the STM32F10x_StdPeriph Library. I started the development of the project with Keil ARM-MDK but now moved over to GCC.

The switch over has gone pretty smooth until now. I use the last page of FLASH as a configuration page to store product specific parameters. This is page is obviously situated in bank 2. In certain instances these configuration parameters need to be updated at runtime, but now that I have moved over to GCC, the second memory bank goes into a busy state as soon as I try to write to it and then it stays busy until I cycle the power. Erase works fine, but writing fails.

I do unlock all the FLASH and make sure that all the clocks are initialized to access the FLASH. Not sure if there is a problem with my linker file or if I screw something up in my startup file.

Attached are my linker file, startup file and other source. I call function Libhl_Flash_Init() as one of the first functions within main()

If anyone can tell me what I am doing wrong I will be very grateful.

Thanks,

H

#flash-programming #flash

hermanv · ‎2012-09-28

Posted on September 28, 2012 at 15:33

Well I managed to solve my problem.

When I moved over to GCC, I obviously had to recompile the STM32F10x Peripheral library and I lef the optimization setting to -O3. This was not allowed initially as the __STREXH and __STREXL core functions needed to be changed in order to build for the selected optimization. I found the following solution on a forum:

change __ASM volatile (''strexh %0, %2, [%1]'' : ''=r'' (result) : ''r'' (addr), ''r'' (value) ); to

__ASM volatile (''strexh %0, %2, [%1]'' : ''=&r'' (result) : ''r'' (addr), ''r'' (value) );

Several comments related to this solution specified that this solution does not cause any errors.

When I use the original code and set the optimization to -O0, everything works just fine. The access to the on-chip FLASH interface is 16bit and therefore if you screw up the above mentioned functions, all 16bit write accesses will be screwed up.

As I don't need optimization at this stage, I will stay without it.

Any suggestions about how to update these functions correctly for use with optimization will be appreciated.

Enjoy,

H