I am encountering a persistent flash programming issue on the STM32L452RE microcontroller using STM32CubeIDE and STM32CubeProgrammer. The device is connected via an ST-LINK V2 debugger using the SWD interface. The problem occurs during firmware flashing: although the flash erase operation completes successfully, the subsequent write operation fails consistently with the error message “Error finishing flash operation”. This issue is reproducible across multiple boards of the same model.
Development Environment:
MCU: STM32L452RE
IDE: STM32CubeIDE v1.15.1
Debug Probe: ST-LINK V2 (latest firmware)
Debug Interface: SWD at 3.3V
Tools also used: STM32CubeProgrammer v2.x
RDP Level: 0xAA (Debug enabled, fully open)
Boot Configuration:
Linker scripts: verified for non-overlapping memory sections
Firmware size: well within the flash limits of the device
Observations:
Using STM32CubeProgrammer:
The chip is correctly detected.
Full chip erase operation completes successfully.
Attempting to program the same ELF or HEX file immediately afterward fails with a write error.
Using STM32CubeIDE:
The debugger successfully connects to the target.
Upon flashing the firmware, the process fails with:
Error finishing flash operation
Failed to execute MI command: load <project.elf>
Using ST-LINK GDB Server:
I have tested this across multiple identical boards and observed the same issue on all of them.
Actions Taken:
Verified SWD wiring, target voltage, and VCAP connections.
Tested with BOOT0 held high to force entry into the system bootloader; the issue still persists.
Reduced SWD clock speed to 1.2 MHz.
Updated ST-LINK firmware to the latest version.
Used STM32CubeProgrammer to perform full chip erase prior to flashing.
Cleared all flash error flags in code using __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS) before programming.
Reviewed and confirmed linker script alignment and section sizes.
Validated flash write code uses aligned double-word writes as per STM32L4 flash programming requirements.
Attempted flashing with both the bootloader and application binaries individually.
Request:
I am looking for assistance in identifying the root cause of this flash programming issue. Given that the erase operation succeeds and the flash is not write-protected (RDP is set to 0xAA), it is unclear why all subsequent write attempts fail. Is this a known issue with STM32CubeIDE or the ST-LINK GDB server in relation to the STM32L4 series? Are there any specific errata or configuration registers that could interfere with flash write access even when protection levels are open? Would switching to an external programmer such as a Segger J-Link provide better reliability for STM32L4 devices?
