Electronic – STM32 appears to be irrevocably bricked

flashmicrocontrollerstm32

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:

0xFDFFEFFF 0xFBFFFBFF 0xFFFFFFFF 0xDFFFFEFF  
0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xF7FFFFFF  
0xFFFDFFFF 0xFFFFFBFF 0xFFFFFFFF 0xFFFFFFFF
...

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:

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.
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.

Best Answer

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.

Related Solutions

Electronic – How does erasing a NAND-Flash memory work

What you say is more similar to old EEPROM and NOR Flash, in which the erasing process basically consists in the injection of the same amount of opposite charge. The problem is that the cancellation has to be really accurate, otherwise the risk is to not discharge completely the gate or charging it with an opposite value.

The Flash NAND memories use the tunnel release principle, that (if I remember well) basically consists in making the charge flowing away from the floating gate to one of the active regions, avoiding the risk of injecting other charges.

Probably it's not so clear, but the reason why it doesn't discharge with an opposite voltage is because with NAND Flash you discharge the Floating Gate as you would do with a capacitor, simply letting the charge flow away; while the other technologies require the injection of an opposite charge.

(Take this answer with caution, it's not fully accurate but based on what I remember from the course...when I'll get the material again I'll give you a more accurate answer)

Electronic – How to overwrite flash memory on STM32L series

Some types of non-volatile memory device use error-correcting logic which adds an extra few bits to each programmable chunk (e.g. 5 bits per 16, 6 per 32, 7 per 64, 8 per 128, etc.) Generally the error correction code is chosen so that all bits blank is a valid representation; in some cases, but not all, it may also be chosen such that all bits programmed is also a valid combination. For simplicity, I'll assume a code with which guards each group of 4 bits with 3 guard bits. Compute the three guard bits guard bit as being the xor of either data bits 0+1+3, 0+2+3, or 1+2+3. I'll also assume that a blank word is zero.

The 16 possible code values are thus

3210 ABC    3210 ABC    3210 ABC    3210 ABC
0000 000    0100 011    1000 111    1100 100
0001 110    0101 101    1001 001    1100 010
0010 101    0110 110    1010 010    1110 001
0011 011    0111 000    1011 100    1111 111

When a memory nybble is read, the system can see what bits ABC should be according to the table. If one of the seven bits in the word is misread, the combination of ABC bits that don't match the computed value will indicate which bit was wrong.

Suppose a memory system used the 16-bit code shown above, and one wanted to overwrite a byte value of 1110 (ECC bits 001) with a value of 1000 (ECC bits should be 111). The net effect would be that the system would write 1000 with ECC bits of 001. When the data is read back, the system would see that for a value of 1000, the ECC bits should be 111 but are instead 001. The fact that bits A and B are wrong means bit 0 of the data was wrong and should be flipped; the system would thus read the value as 1001 (whose ECC is correctly 001).

In most cases, there should be enough flexibility in the design of an error-correcting code to permit both all-bits-clear and all-bits-set to be regarded as valid combinations. Some systems do not do so, however. If an error-correcting code would require an all-bits-programmed word to have two or more of the ECC bits blank, then an attempt to obliterate a word which has those bits programmed would likely visibly fail; attempts to program many other values would likely yield a state which was only one bit error away from failure rather than two.

I really wish memory designers would allow for data to be obliterated even if they don't allow most other overwriting patterns. Especially with NAND flash, it would make some operations a lot easier.

Best Answer

Related Solutions

Electronic – How does erasing a NAND-Flash memory work

Electronic – How to overwrite flash memory on STM32L series

Related Topic