Closed rob-the-dude closed 8 months ago
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 https://github.com/STMicroelectronics/stm32u5xx_hal_driver/pull/7
Thank you again for your contribution. We are looking forward to reading from you again. With regards,
Thanks very much! Cheers!
In trying to get Zephyr RTOS working on the Nucleo U545RE-Q board, I discovered header inclusion issues building the HAL for the STM32U545 SoC.
Zephyr RTOS makes use of the "stm32u5xx_hal_driver" for some interactions with the ST hardware, and builds the HAL by copying the default "stm32_hal_conf_template.h" to "stm32_hal_conf.h", leaving all options enabled.
However, some of the modules (specifically HAL_SRAM_MODULE_ENABLED, HAL_NAND_MODULE_ENABLED and HAL_NOR_MODULE_ENABLED) do not compile for the STM32U545. Based on recommendations from a engineer in the Zephyr forums, I modeled changes to four files ((stm32u5xx_hal_sram.h, stm32u5xx_hal_nor.h, stm32u5xx_hal_nand.h and stm32u5xx_ll_fmc.h) with appropriate "#ifdef" checks using the example for the "stm32g4xx_hal_driver", and this allows the code to build for the U545 series. Clearly, I'd appreciate ST (and others) review of these changes to ensure correctness.
I'll submit a PR shortly so the changes can be reviewed.