I have a custom board with an STM32F103VE MCU. I can connect to it fine using ST-Link Utility, and I even had code downloaded to it a few times (in ST-Link Utility as well as CooCox), but today I started having problems erasing the MCU's internal flash memory.

When performing a mass erase (Target -> Erase Chip in ST-Link Utility), the log reads "Flash memory erased.", yet when reading back the memory, the old contents are still there, even after rebooting the MCU, reconnecting the ST-Link adapter, and even rebooting the computer. If I try to erase individual sectors (Target -> Erase Sectors... in ST-Link Utility), this is what I get in the output log having selected all sectors to erase:

17:55:27 : Flash page 0 @0x08000000 is not erased. Verify the memory protection.
17:55:27 : Flash page 1 @0x08000800 is not erased. Verify the memory protection.
17:55:28 : Flash page 2 @0x08001000 erased.
17:55:28 : Flash page 3 @0x08001800 erased.
17:55:28 : Flash page 4 @0x08002000 erased.
17:55:28 : Flash page 5 @0x08002800 erased.
17:55:28 : Flash page 6 @0x08003000 erased.
17:55:28 : Flash page 7 @0x08003800 erased.
17:55:29 : Flash page 8 @0x08004000 is not erased. Verify the memory protection.
17:55:29 : Flash page 9 @0x08004800 is not erased. Verify the memory protection.
17:55:33 : Flash page 33 @0x08010800 is not erased. Verify the memory protection.
17:55:33 : Flash page 34 @0x08011000 is not erased. Verify the memory protection.
17:55:33 : Flash page 35 @0x08011800 erased.
17:55:33 : Flash page 36 @0x08012000 erased.
17:56:07 : Flash page 254 @0x0807F000 erased.
17:56:07 : Flash page 255 @0x0807F800 erased.

Just to be clear, this is not an option bytes issue -- those related to memory protection are all clear ("No Protection"), and in fact when trying to update the option bytes, I get an error stating "Could not set Option bytes! Please reset the target and retry!"

It turns out that I only had code written to the first page (0x0800000 - 0x080007FF) and then to pages 8 through 34 (0x08004000 - 0x080117FF). So the pages that were supposedly erased were in fact blank to start with.

Now, as shown above, there is a problem erasing page 1 as well (0x08000800 - 0x08000FFF). Originally this was a blank page, which when attempting an erase as above indicated a successful erase, but I decided to perform an experiment that convinced me this is a hardware fault: I wrote a small .bin file starting at 0x08000800. The first few words from this 32-bit file are:

0x20000808 0x08000255 0x08000251 0x08000251
0x08000251 0x08000251 0x08000251 0x00000000
0x00000000 0x00000000 0x00000000 0x08000251

Yet, after writing this to the originally blank page 1 and reading back from the memory, I get this:


From this moment on, when trying to erase page 1 (via Target -> Erase Sectors...), it reported a failure in this page, exactly as shown above.

With this in my mind, I have two questions:

  1. Is this MCU irrevocably bricked indeed? This isn't just a question of penny-pinching, but this is a BGA MCU that was reflow soldered, and reworking it is not my idea of fun. Hence I'm open to any suggestions to try unbricking it.

  2. If this is a hardware failure, how did it come about, so I can try to prevent it in the future? Here I should mention that this board has a weird power architecture, and due to some incorrectly soldered parts, it appears that it may have been subject to especially low voltages supplied from a coin cell (CR1220), which was fully discharged (from 3.0 V to 2.4 V) in the span of a few hours (normally it is powered from USB or a rechargeable Li-Ion battery). A second coin cell was put in place, and by the time I realized this power issue, it was already down to 2.7 V. I have a theory that the STM32 has some internal circuitry to generate the required programming voltage, but it needs a minimum voltage to work properly, and possibly it was subject to a lower voltage which overloaded and permanently damaged the circuit. Note that I have no data to back this up, it's just wild speculation.

EDIT: there is one detail I forgot to mention, which I don't think is the source of the issue, but perhaps it's worth mentioning: one of the last things I did before the MCU was bricked was to inadvertently program a .bin file at the wrong address (0x200 beyond the correct starting address) and hence it may have tried to write beyond the end of the flash memory (i.e. in addresses 0x08080000-0x080801FF). If anyone thinks this may be what eventually bricked the MCU, please let me know.


3 Answers 3


First the programming voltage, it is given in the data sheet under the operating conditions of the memory (page 63):

Vprog Programming voltage 2 - 3.6 V

So if I read your suggestion correct it might have been powered only by that coin cell during programming? This might be very very bad indeed. The controller draws a maximum current during write operation (just the flash) of 7 mA. A small coin cell really doesn't cope well with higher currents and it's voltage as well as the capacity dropped probably really fast. Given the datasheet of a CR1220, the voltage drop on a full battery would be at least 0.5 V if you draw 7 mA from it, so it starts out at about 2.35 V, not much headroom.

But I also wonder if your circuit is fine now - have you measured the current it draws and checked all the voltages and their stability if you draw current (connect a resistor decade and vary it a bit)?

Now a possibility on how you might be able to salvage the part. I guess it won't work as you have no trouble connecting to the device, but anyways:

The F103 has a built in bootloader which is accessible if you pull the BOOT pin high during power up. You will also need access to UART1 to be able to communicate with the bootloader. Have a read of section 3.4 of the reference manual. Another good resource is this document.

If you can connect to it, there is a tool (STSW-MCU005STM32 and STM8 Flash loader demonstrator (UM0462)) available from ST which allows to interface with the bootloader and erase or program the chip.

  • \$\begingroup\$ Using the bootloader is about the only thing I haven't tried yet, but just for closure I will do that one of these days. Not that I'm expecting anything different by now, but it's worth trying. \$\endgroup\$
    – swineone
    Aug 26, 2015 at 21:58
  • \$\begingroup\$ @swineone it sounds rather dead and it being BGA, I can feel your pain :-( \$\endgroup\$
    – Arsenal
    Aug 26, 2015 at 22:06

Just unpower the board, pull the boot pin high, power the board, load a program to it using SWD, then unpower and pull the boot pin low before repowering.

  • \$\begingroup\$ Tried that already, no luck. It appears to be an issue of the MCU's internal programming hardware having been damaged. \$\endgroup\$
    – swineone
    Aug 27, 2015 at 15:26

Programming flash requires higher voltages than what you normally supply. In the old days you could only program a device by providing vpp externally. Nowadays cpus generate that voltage internally from VDD.

Programming flash is a finicky process. The algorithm goes soomething like: measure the time it takes for the bit to read back as the wanted value and then continue programming twice as long. Again, in the old days a programmer would have to implement this, but now it is all integrated in the cpu. In the stm, programming with insufficient vpp will result in a timeout. Usually, the vpp generating circuit simply does its best but does not die. So... my guess is that there is another cause for the flash hardware failure....


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.