Hello, I am trying to port TouchGFX Designer generated code into an STM32 Project that is built in a different build system (i.e. not STM32CubeIDE).
So I started at `TouchGFX/Core/Src/main.c` and trying to port over what was done as far as HW Initialization and testing. My platform is the STM32H735G-DK devKit.
I noticed quite a difference between MX_OCTOSPI1_Init vs MX_OCTOSPI2_Init in the TouchGFX generated code (i.e. the USER CODE sections)
MX_OCTOSPI1_Init pretty much undo all the CubeMX generates and relies on BSP_OSPI_NOR_Init
MX_OCTOSPI2_Init kept what CubeMX generates cal cals a couple of HAL_OSPI functions
Questions:
- Why was this approach taken? In a way I understand MX_OCTOSPI1 a bit more since the BSP code ends up calling the component specific functions. With MX_OCTOSPI2_Init, I am not clear how it maps to the S70KL1281 component functions? There are BSP_OSPI_RAM functions provided, why does the TouchGFX generated code choose to use it for OCTOSPI1 but not OCTOSPI2 ?
- I am also hoping to do some sanity check access to the components before adding the rest of the code. I am able to use BSP_OSPI_NOR_ReadID on OCTOSPI1 (only if memoryMapped mode is off)
but calling the equivalent S70KL1281_ReadID() always returns an error for OCTOSPI2
I am not clear if setting MemoryType as HyperBus during HAL_OSPI_Init() prevents using ReadID ?
- If there is a sample code on how to do sanity access to the OctoSPI2 memory mapped region, that will be helpful as well. so far direct access (similar to OCTOSPI1) causes the board to reboot. I sense I maybe missing some other parts of init beyond what is done in MX_OCTOSPI2_Init() ?
Thank you for everyone's time.
