Skip to main content
EBotö.1
Associate II
May 2, 2025
Solved

Editing in "Memory & file editing" erases wrong page when bank_swap is set (2MB flash STM32U585x)

  • May 2, 2025
  • 1 reply
  • 377 views

Hi,

I'm using a 2MB flash version of STM32U585x MCU and noticed that when the bank swap bit is set in OB, the wrong page will be erased if I edit flash using the "Memory & file editing". It seems like the page to be erased doesn't take the bank swap bit into consideration.

To elaborate a bit: If bank swap is disabled and I edit some memory at e.g. 0x08006000, it will correctly erase page 3 before writing the new data. But if I have bank swap bit set, and edit the memory at 0x08006000 it will still erase page 3 before writing even though it should be erasing page 3+128 since it's this page that is now available at 0x08006000.

This had me very confused before I understood what was happening.

Best answer by Amine_Jridi

Hello @EBotö.1,

Do you mean that you want the log to display that the tool is erasing sector 131?

The tool here maintains consistent address handling, so with SWAP_BANK enabled the address 0x08006000 still point at sector 3 as part of its original logical mapping. regardless of the physical configuration this is the normal behavior of the tool to ensure expected and clear outcomes.

Thanks,

Amine.

1 reply

Amine_Jridi
Amine_JridiBest answer
Technical Moderator
May 6, 2025

Hello @EBotö.1,

Do you mean that you want the log to display that the tool is erasing sector 131?

The tool here maintains consistent address handling, so with SWAP_BANK enabled the address 0x08006000 still point at sector 3 as part of its original logical mapping. regardless of the physical configuration this is the normal behavior of the tool to ensure expected and clear outcomes.

Thanks,

Amine.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
EBotö.1
EBotö.1Author
Associate II
May 6, 2025

Hi,

I realized I was not running the latest version of STM32CubeProgrammer (I was on 2.16), and it seems like this bug has been corrected from 2.17 and newer. Sorry for the unneccessary noise.

Cheers,

Erik