STM32F103 Internal Flash Bank2 Access

[stuart]

Posted on May 31, 2013 at 13:57

I am working on a project using an STM32F103 with 768K of internal Flash. I can successfully erase and program the first bank of internal Flash, but am having problems with bank2.

The problem seems to be that I am having problems accessing the address range of the bank. If I use the JTAG to program the second bank, then try to read it from my code it just reads as all F's. I am unable to program bank 2. The process seems to complete successfully, but when I check via the JTAG the area has not been written. If I program the bank via the JTAG I can erase the area from code, confirmed via the JTAG. Given that I can't seem to read the bank, I was wondering if the problem was the step where I effectively write to the address. Do I have to write to any registers to allow me to access the second bank? My code is running from bank1. Thanks, Stuart #stm32f103-flash

[Tesla DeLorean]

Posted on May 31, 2013 at 15:25

While there is some magic with XL parts, most of that is achieved by picking the right flash algorithm/applet in the tool chain, and building with the startup_stm32f10x_xl.s and STM32F10X_XL defined.

From a perspective of flashing from within ones own code, you have to deal with the page size, and recognize which bank, registers and control bits need to be used. You should be able to read the memory in a linear fashion, and programming it should work, check that you have verify enabled. You don't mention a tool chain, but you could try other avenues and tools to program the part. The ST-Link utilities and Flash Demonstrator being particularly good sanity checkers.

[stuart]

Posted on July 04, 2013 at 15:14 My problem was a bug in the FLASH_GetBankXStatus() functions stm32f10x_flash.c. These functions read the Flash status register several times, meaning that the value can change half way through the function. They should read the status once at the start and use that value throughout. This doesn't happen when programming Bank1 from code running from Bank1 as the code is held up until the Flash operation completes. The same thing does happen though, if you try to program Bank1 from code running from RAM. When these functions are used there is another bug in that the return code is checked against FLASH_FLAG_BANKX_BSY when it should be checked against FLASH_BUSY, but as these happen to be the same value this doesn't matter. In general, the way the code has been extended to support the second bank is awful, really it needs rewritten.