stm32u585xx.h incorrectly defines FLASH_PAGE_NB

[warasilapm]

While tracking down a flash bug in Zephyr on the STM32U585, I discovered that the stm32u585xx.h header defines FLASH_PAGE_NB based on FLASH_BANK_SIZE rather than FLASH_SIZE, meaning that FLASH_PAGE_NB equates to what was defined on other platforms (or at least in the stm32l5_hal_flash.h) as FLASH_PAGE_NB_PER_BANK. This doesn't make much sense to me.

The most straightforward fix, in my opinion, would be to add the FLASH_PAGE_NB_PER_BANK macro and redefine the FLASH_PAGE_NB macro to accurately represent the total number of flash pages on the platform.

[warasilapm]

Additionally, the usage in stm32u5xx_hal_flash.h in the definition of IS_FLASH_PAGE() would need to be updated from FLASH_PAGE_NB to FLASH_PAGE_NB_PER_BANK.

[RJMSTM]

ST Internal Reference: 137708

[RJMSTM]

Hello @warasilapm

This issue is invalid

The flash memory in STM32U5xx products is divided into two banks, each with n pages depending on the die. For example, in: • STM32U535/545 each bank contains 31 pages, which are organized as follows:

• STM32U575/585 each bank contains 127 pages, which are organized as follows:

and so on.

For more details, see Table 51/52/53 in the RM0476 reference manual: The product reference manual manages the pages indexes depending on bank, not on the whole flash memory. Therefore, it is not necessary to calculate the total number of pages for the whole memory. That’s why the FLASH_PAGE_NB in stm32u585xx.h is based on FLASH_BANK_SIZE rather than FLASH_SIZE, and the drivers are adapted to work with page index in each bank.

With regards, Rania

[warasilapm]

@RJMSTM Sorry for not responding sooner.

I understand where you are coming from. However, I believe this is *inconsistent with the very similar STM32L5 series and other STM32 series which have dual flash banks. This resulted in the issue I resolved in Zephyr here.

[warasilapm]

I did a brief scan of the headers for the [STM32L5 package](https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/STM32L5xx_HAL_Driver/Inc/stm32l5xx_hal_flash.h, the STM32G4 package and the STM32G0 package and it would appear that I am incorrect. It appears that the L5 driver is the special case here, not the U5. I'm on board with this closing now.