Skip to main content
YIshi.1
YIshi.1
Associate II
October 22, 2026
Question

Erasing internal memory sectors

Title: STM32L431 debug launch fails every other time depending on odd/even number of Flash pages

Hello,

I would like to report a reproducible issue with STM32CubeIDE and an STM32L431 device.

Environment

  • MCU: STM32L431CBT6

  • STM32CubeIDE: Version 2.2.0

  • Build: 29186_20260626_0934

  • Debugger: ST-LINK / SWD

  • Flash page size: 2 KB

Symptom

For a long time, I had an intermittent problem when starting a debug session.

Approximately every second debug launch failed.

Depending on the failed attempt, I observed one of the following:

  • The program appeared not to be loaded correctly.

  • The CPU ended up somewhere in System Memory, for example at an address around 0x1FFFxxxx.

  • The program started, but did not stop at the configured breakpoint.

  • In some failed sessions, peripheral registers could no longer be read from the debugger.

Initially, I suspected BOOT0, reset timing, SWD speed, or hardware noise.

However, the same physical PCB worked reliably when I programmed another firmware project into exactly the same MCU.

This led me to compare the Flash programming size.

Reproduction result

I found a very clear correlation with the number of Flash pages erased/programmed.

When CubeIDE reported:

Erasing internal memory sectors [0 22]

this corresponds to 23 Flash pages.

With this image, the debug launch failed approximately every second time.

I also tested another build:

Erasing internal memory sectors [0 26]

This corresponds to 27 Flash pages.

Again, approximately every second debug launch failed.

However, after completely removing power and powering the board again, the application itself started normally every time. Therefore, the programmed Flash contents appeared to be valid, while the debug-start sequence immediately after programming was not.

On the other hand, with:

Erasing internal memory sectors [0 25]

which corresponds to 26 Flash pages, the problem disappeared.

Workaround

I then modified the linker script so that the Flash image is padded to a 4 KB boundary.

Since the STM32L431 Flash page size is 2 KB, this guarantees that the programmed image always occupies an even number of Flash pages.

I added the following after the .data section:

__flash_image_end = LOADADDR(.data) + SIZEOF(.data);

.flash_pad __flash_image_end (READONLY) :
{
    FILL(0xFFFFFFFF)
    BYTE(0x00)
    . = ALIGN(0x1000);
} >FLASH

After rebuilding, CubeIDE reported:

Erasing internal memory sectors [0 27]

which corresponds to 28 Flash pages.

Since applying this workaround, every debug session has stopped correctly at the breakpoint. I have not reproduced the previous every-other-launch failure.

So far, my observations are:

23 pages (odd)  -> intermittent debug failure
26 pages (even) -> no failure
27 pages (odd)  -> intermittent debug failure
28 pages (even) -> no failure

This behavior appears strongly related to the odd/even number of programmed Flash pages.

Request / suggestion

Could ST please investigate the Flash programming / debug-start sequence for STM32L4 devices, especially the handling of the Flash empty state / FLASH_SR.PEMPTY after programming?

The linker padding above is only a workaround. Ideally, this should be fixed in the Flash loader / STM32CubeProgrammer side so that application size does not affect whether the MCU starts correctly under the debugger.

As an interim workaround, would it also be possible for STM32CubeIDE to automatically generate a linker script that pads the Flash load image to an even number of Flash pages for affected STM32L4 devices?

For STM32L431, for example, aligning the final Flash image to a 4 KB boundary would ensure an even number of 2 KB Flash pages automatically.

This would prevent the problem from unexpectedly returning whenever a small source-code change causes the binary to cross from an even number of Flash pages to an odd number.

Possibly related reports

I found several existing ST Community reports that appear to describe the same or closely related PEMPTY / System Memory boot behavior:

  1. “STM32L4 only boots every other flash – CubeProgrammer PEMPTY bug with odd number of flash pages”
    This report is especially similar: the issue occurs every other programming attempt, depends on an odd/even number of Flash pages, and the failed boot enters System Memory with PEMPTY set.

  2. “Flash Loader resets State Register incorrectly.”
    This report also describes failure with an odd number of Flash sectors and points to incorrect handling of the PEMPTY bit by the Flash loader.

  3. “Possible bug report: PEMPTY Flag Issue with STM32L431CCT6 in STM32CubeIDE v1.19”
    This is particularly relevant because it involves an STM32L431 and intermittent boot into System Memory after programming.

  4. “Bizarre bootloader invocation every other debug session”
    This also describes an STM32L431 unexpectedly entering the bootloader every other debug session.

There is also an older ST Community report in which ST support identified incorrect clearing of the PEMPTY flag by Flash loaders as the cause of intermittent boot into System Memory.

Considering these previous reports and the reproducible odd/even page behavior above, this appears likely to be a Flash loader / PEMPTY handling issue rather than a hardware BOOT0 problem.

I can provide additional logs or perform further tests if required.

Terms & ConditionsAccessibility statement