STM32F103: some blank pages in flash, not visible in binary

[tom239955]

Posted on August 20, 2015 at 11:13

Hello everyone,

First question on this forum.. Ok, so in short: whenever I upload a binary file, either using

st-flash

, ST-LINK Utility, or

gdb load

, the flash memory shows up empty (

0xffffffff

) on pages

0x8004000

-

0x80047FF

. And it does that every time, even though the binary and hex files that I use to upload don't show these empty spaces. Weirdly enough, the verification (while flashing with st-flash for example) doesn't come up with an error. After flashing has been done however, the compare function in ST-LINK Utility does! I have been looking at this problem for a while and it is starting to freak me out now. This would suggest a corrupted chip or damaged flash maybe, but I experience the same problem on a different board (a Nucleo F103RB) using a different USB ST-link v2 and different tools on both windows and OSX. I even tried using a different toolchain to compile the things in a VM, but the problem stays the same. I did notice that if I change the memory mapping in my linker file from:

FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K

to

FLASH (rx) : ORIGIN = 0x08008000, LENGTH = 96K

and thereby skip the pages I previously mentioned, there is no ''hole'' in the flash memory! Some additional information: I'm compiling a slightly modified firmware (wifi disabled) for the Spark Core from Particle (formerly Spark IO), based on their stock firmware repository. I'm compiling this using the GNU Arm Toolchain version 4.8 on OSX. I use the

st-flash

utility for uploading and

st-util

and

gdb

for debugging. Now I am quite lost at this point, so I have no particular question I want to ask other than: what can this be? Thanks for your help! #gdb #stm32 #firmware #flash #gnu

[Nickname5522_O]

Posted on August 20, 2015 at 17:36

Hi tomdeboer,

1-In your code, are there routines that modify the contents of pages

0x8004000

-

0x80047FF?

2-Are there other empty pages? 3-Dump and program your code in the RAM ( Boot0=1, Boot1=1), so you can check if the root cause is the flash or your own code. -Shahrzad-

[Tesla DeLorean]

Posted on August 20, 2015 at 20:57

[tom239955]

Posted on August 20, 2015 at 23:03

Hi everyone, I found the culprit today, but I'm left with one other question. The problem was very well hidden: it was in Spark Core's EEPROM class. The class emulates EEPROM on-flash, at, you guessed it: 0x8004000 and is 2k long. In the constructor of that class, it erases to two pages if it doesn't find that it needs.

This leads me to the next question: why does it's constructor get called? Because I couldn't find any calls or instances to the class and if I delete the .cpp and .h file, nothing complains. So it seems like the constructor is called even though there there is no instance?

[Nickname5522_O]

Posted on August 21, 2015 at 13:45

Hi tomdeboer,

May be there is a linker file that contains a table of initilization functions. I can not help you more as I do not have the code, have a deep look at it. -Shahrzad-