Skip to content

[BUG] STM32H5 FLASH: Incorrect Bank Reference during block erase #16417

@stbenn

Description

@stbenn

Description / Steps to reproduce the issue

I have discovered an issue in my implementation of up_progmem_eraseblock() for the STM32H5. I am implementing and testing a fix right now, but I am opening this bug report incase someone else finds this issue in the meantime.

The H5 supports dual bank FLASH for some MCUs. The FLASH driver uses a data structure to track the "logical" banks for addressing purposes. These essentially track the bank base address, erase block numbers, and page numbers. However, certain aspects of the hardware do not care about 'logical' banks and need to refer to physical banks.

When flash banks are swapped by selecting SWAP_BANK bit in FLASH_OPTSR_PRG, the 'logical' banks in code still correspond to bank1->base_addr = 0x08000000 and bank2->base_addr = 0x08100000. However, the addresses flip but not the physical banks.

This causes an issue when selecting the bank for erase operations in arch/arm/src/stm32h5/stm32h563xx_flash.c:

ssize_t up_progmem_eraseblock(size_t block)
{
/* ... */
priv = flash_bank(block_address); // Get's 'logical' bank by address

/* ... */

// WRONG: Selects BKSEL bit based on 'logical' bank base address
if (priv->base == STM32_FLASH_BANK1)
  {
    modifyreg32(STM32_FLASH_NSCR, FLASH_NSCR_BKSEL, FLASH_NSCR_SER);
  }
else
  {
    modifyreg32(STM32_FLASH_NSCR, 0, FLASH_NSCR_BKSEL | FLASH_NSCR_SER);
  }

/* ... */
}

From the reference manual [RM0481] pg. 327:
NSCR BKSEL

The code above is incorrect because it selects BKSEL based on the logical bank value, NOT the physical bank.

In my fix, this instance will be corrected and I will make sure any other instances of the bug in the H5 arch files are also addressed.

What happens as a result of this bug

If a bank swap has occurred, and a user application tries to erase the first block of bank 2 (Block 128) they expect to erase the block starting at 0x08100000 but actually the block starting at 0x08000000 gets erased. As you can imagine, this causes issues because this is where the currently executing Nuttx instance is stored....

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu 24.04

NuttX Version

master

Issue Architecture

[Arch: arm]

Issue Area

[Area: Other]

Host information

No response

Verification

  • I have verified before submitting the report.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Arch: armIssues related to ARM (32-bit) architectureOS: LinuxIssues related to Linux (building system, etc)Type: BugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions