header inclusion issues for STM32U545xx

[rob-zeno]

I'm trying to get Zephyr RTOS working on Nucleo U545RE-Q board, with an STM32U545RET6Q part on it.

Zephyr RTOS uses the STM32U5xx_HAL_Driver for certain functionality. According to engineers there, it copies the stm32_hal_conf_template.h file to stm32_hal_conf.h, leaving all of the options defined.

Unfortunately, the HAL_SRAM_MODULE_ENABLED, HAL_NAND_MODULE_ENABLED and HAL_NOR_MODULE_ENABLED definitions include files that do not compile for the STM32U545 family.

According to one of the engineers on the Zephyr team, the problematic included files (stm32u5xx_hal_sram.h, stm32u5xx_hal_nor.h and stm32u5xx_hal_nand.h) need to have:

 #if defined(FMC_BANK1)
 ...
 #endif

around the contents. As an example, he points to the STM32CubeG4 where this approach is used.

I can prepare a PR with these changes, but thought I would bring the issue up here first.

[ALABSTM]

See also stm32u5xx_hal_driver#6

[ALABSTM]

Hi @rob-zeno,

Thank you for this report. It looks like there is a typo in the title. I suppose you mean "U545" instead of "H545". Would you mind correcting it please to avoid any confusion?

Thank you,

[TOUNSTM]

Hello @rob-the-dude,

Thank you for your contribution. You are absolutely right about this point.
Actually, the point you raised has already been dealt and fixed internally. The fix will be made available in the frame of a future release.
please allow me to close this issue and ensure that our conversation remains focused on this pull-request STMicroelectronics/stm32u5xx-hal-driver#7

Thank you again for your contribution. We are looking forward to reading from you again.

With regards,

[rob-zeno]

Thank you for this report. It looks like there is a typo in the title. I suppose you mean "U545" instead of "H545". Would you mind correcting it please to avoid any confusion?

Whoops, you're right! Been working with too many different chip families!

Thanks for everyone's help here!