[STM32F407]Boot failure and garbage vector fetch upon Power-Off or NRST during Flash Write at -10°C
Environment & Hardware
-
MCU: STM32F407ZET
-
Test Temperature: -10°C to 5°C
-
Application Context: Internal flash memory is actively used for data storage purposes
When the MCU is interrupted specifically during an internal flash write operation (HAL_FLASH_Program)—either by a sudden VDD power-off or a hardware reset (NRST assertion)—it completely fails to boot upon the subsequent power-up or reset release. This issue is highly temperature-dependent and only occurs at low temperatures. If the interruption happens while the flash is idle, or if the board is at room temperature, the MCU reboots perfectly fine.
Observed Symptoms & Measurements
Garbage Vector Fetch: Attaching a debugger via hot-plugging shows that the CPU never reaches main(). Consequently, essential initialization routines like SystemClock_Config() and HAL_Init() are completely bypassed and fail to execute. Instead of fetching the correct reset vector from 0x08000004, the Program Counter is loaded with a garbage address (e.g., 0x01021000), causing an immediate lock-up.
Drastic Difference in Recovery Times: The time required to successfully recover and boot the MCU depends heavily on the recovery method:
-
NRST Recovery: If VDD is maintained and the physical NRST switch is held LOW, it takes at least 2.9 seconds for the MCU to recover.
-
Power-Off Recovery: If we completely turn off VDD, it takes more than 1 to 2 minutes of completely unpowered state before the MCU can successfully boot upon the next power-up.
VCAP Overshoot (Uncertain Impact): Probing with an oscilloscope reveals that when the MCU attempts to boot, the 1.2V core voltage (VCAP) sharply overshoots to 2.0V before eventually settling down. VDD (3.3V) remains completely stable during NRST events. We are not entirely sure if this overshoot is a primary cause of the issue or just a secondary effect.
Yellow : +1.2V VCAP
Blue : VCC(+3.3V)
purple : reset
Troubleshooting Performed
-
Software solutions such as
__HAL_FLASH_CLEAR_FLAG()or placing dummy NOP loops beforeHAL_Init()fail because the CPU fetches a garbage PC and never executes a single line of user code. -
Enabling BOR Level 3 in the Option Bytes does not prevent the issue.
-
Bleeder Resistor Test: We added a parallel bleeder resistor (1kΩ) to the VCAP capacitors to forcibly accelerate the discharge of the core voltage line, hoping it would quickly drain whatever was locking up the MCU. However, despite rapidly discharging the VCAP line, the required delay times (2.9 seconds for reset, 1-2 minutes for power-off) remained completely unchanged. This indicates that discharging the external 1.2V domain does not help resolve the internal lock-up.
Current Hypothesis
We suspect that abruptly aborting the flash write at sub-zero temperatures leaves the internal flash charge pump (12V) heavily charged.
The drastic difference in recovery times supports this: When VDD is ON and NRST is held LOW, some internal active biasing circuitry may remain alive to slowly bleed off this high voltage over ~3 seconds. However, when VDD is completely removed (Power-Off), all active discharge paths are dead. The trapped charge must passively dissipate purely through substrate leakage, which takes over 1 to 2 minutes due to drastically reduced semiconductor mobility at cold temperatures.
We theorize that this trapped high voltage blinds the flash sense amplifiers, causing the garbage vector fetch. We also suspect this charge might be leaking backward to cause the VCAP overshoot, but we are uncertain if the overshoot itself is fatal to the boot sequence.
