Corrupted Flash in Vector Table area - sector 0

[OVeli.1]

Dear community, 

I have faced with the problem in our developed boards with STM32F407 MCU. The firmware is based on FreeRTOS, vector table is located as usually in the beginning of 0x08000000 (see part of list file below).   

Idx Name Size VMA LMA File off Algn
0 .isr_vector 00000188 08000000 08000000 00010000 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA

Boards with MCU are flashed with USB-UART adapter and STM32 Flash loader demonstrator https://www.st.com/en/development-tools/flasher-stm32.html

Boards have some parameters (configuration of sensors), stored in the Flash memory, so we used sector 7 for these data, and customer can update the information about these sensor parameters. Mainly boards works well, but some of them were returned from the customer as "works well, but now don't works at all". After reading the memory damp and comparison with reference board with the same firmware that works perfect, I have found that some memory area is corrupted, and it is only in vector table area - sector 0.

Some observations:

1. Corrupted Flash memory in the initial part of the memory (addresses starting from 0x08000000 – see Figure 1). All corrupted bytes are located in the area of flash memory, called “Vector table”, that is responsible for the initial position of the addresses for interrupt. The first 16 bytes (0x08000000…0x0800000F) in Flash memory are ok, but all three boards has corrupted bytes in the range from 0x08000030…0x08000108.
2. All corrupted bytes are located consequently (see Figures 2…4), and forms “corrupted range”, e.g., for the board 3 this range is 0x08000010…0x0800012B, for the board 2 this range is 0x0800002C…0x0800010A, and for the board 1 this range is 0x08000030…0x08000117. No any corrupted bytes in other flash memory addresses, except this corrupted range were found.
3. In many cases, inside this corrupted range, all bits from one byte in Flash memory were set to 0x00 (so all bits are set to 0), but in some cases, only some bits are set to 0, such cases shown in Excel table with blue background. Some examples of such bytes are: correct data byte that should be is 0x3F – 00111111B, and corrupted byte is 0x1A – 00011010B, or correct data byte that should be is 0xD9 – 11011001B, and corrupted byte is 0xD8 – 11011000B.
4. In all three cases, corrupted zone has “central” part, where all byte is corrupted (set to 0x00), but on the “border” zone (firsts corrupted bytes in memory), close to non-corrupted Flash memory, only some bits are corrupted (such cases shown in Excel table with blue background), or, corrupted and not corrupted bytes are alternate one after another (corrupted byte – non-corrupted byte – non-corrupted byte – non-corrupted byte – corrupted byte), shown in Excel table with green background. Taking into account, that some bytes in the correct Flash should be 0x00, it is not possible to investigate this alternation deeper, because such bytes, even in case of corruption, will not change the content.

It seems to me, that it is not a problem with my software, but rather some problems with the microcontrollers. Have any faced with the same issue?

 

[Tesla DeLorean]

Writing blocks of zeros, whilst leaving original content elsewhere is very odd.

The write functions as a write-once, so unlike more classic FLASH chips you can't keep knocking down ONE bits.

Double check your VCAP capacitors.

Remove your flashing code and see if you can replicate.

[Ywang.3]

We also experenced exactly the same issue. The starting part of the flash is set to be all 0, as shown below,

as the vector table is filled with 0, the mcu cannot be booted now.

[OVeli.1]

Hi all,

I will try to use the solution proposed here https://community.st.com/t5/stm32-mcus-products/powering-cycling-stm32f4-board-corrupts-flash-programming/m-p/552257/highlight/true#M208631, it looks like the issue is not new, but it is strange that ST has not paid attention to it. Anyway, it is not so easy to represent this issue with corrupted flash in a lab, because not all boards from customers returned with it, many work well during a long time...

[OVeli.1 · Accepted solution]

It looks like the source of the problem has been identified, and some solution was found. I have thoroughly investigated three boards with the issue of corrupted flash in sector 0. I have re-flashed them, firstly with the normal procedure that was used in the company ("STM32 Flash loader demonstrator" https://www.st.com/en/development-tools/flasher-stm32.html) with default parameters - no flash protection, BOR level not set (I assume, in this case it has level "off"). Then I have used STM32 CubeProgrammer software, and used the same parameters. You can find the results in the table below - they are marked as "attempt 2". As you can see, the boards were "broken" (corrupted sector 0 with set to "0" of some bits in the part of vector table). In the beginning, all three boards work, but then I have started to set the power on and off (I have used just rocker switch for power supply). The number of power on-off cycles, which board works was different - from 10 to 58. In the end, all three boards were with corrupted flash in sector 0. I have played with the software (I have used CubeProg as well as Demonstartor), and with option bits (the write protection of sectors, as well as brownout reset BOR level). It become clear, that  solution proposed here https://community.st.com/t5/stm32-mcus-products/powering-cycling-stm32f4-board-corrupts-flash-programming/m-p/552257/highlight/true#M208631 (set BOR level to 3 and protect it from writing Flash sectors) is only partially correct. In fact, writing protection doesn't help at all - with BOR level OFF the boards were broken even with protected sectors. The only solution is to set BOR level to 3 - in this case all three boards survived 200 cycles of power on-off and then I have not continued testing to not waste a time.

So, it means that STM has some issue with at least STM32F407 MCU (in my case as well as in the case described by the link above the MCU was the same - STM3F407). The Flash memory can be corrupted in Sector 0 (default vector table) when the BOR level is off, and reset of MCU become at low voltage. To solve the issue, BOR level should set at level 3, with minimum threshold voltage 2.75...2.85 V. Maybe it will also work to set lover level (1 or 2), but I have decided that in my case it works and have not analyzed it further.

Brd.	Attempt	Software	BOR value (level)	WP Sectors 0…6, 8…11	On-off #	Result
1	2	CubeProg.	3 (OFF)	Not active	58	Corrupted sector 0
1	3	Demonstrator	3 (OFF)	Not active	78	Corrupted sector 0
1	4	Demonstrator	3 (OFF)	Active	11	Corrupted sector 0
1	5	CubeProg.	0 (3)	Active	200	Ok
2	2	CubeProg.	3 (OFF)	Not active	10	Corrupted sector 0
2	3	CubeProg.	3 (OFF)	Not active	40	Corrupted sector 0
2	4	CubeProg.	0 (3)	Active	200	Ok
3	2	CubeProg.	3 (OFF)	Active	48	Corrupted sector 0
3	3	CubeProg.	0 (3)	Not active	200	Ok