stbenn opened a new issue, #16417:
URL: https://github.com/apache/nuttx/issues/16417
### 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`:
```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:
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
- [x] I have verified before submitting the report.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
