STM32U575I-EV Demo project has no CubeMX .ioc file There is no CubeMX .ioc file for the STM32U575I-EV Demo project. Other example and application projects provided by STM do have .ioc files. Why? Is there a CubeMX limitation?

[adiroot]

..

[Imen.D]

Hello @adiroot​ ,

There is no .ioc files provided for STM32U575I-EV Demo project.

You ought to develop your own project using the CubeMx tool and based on ioc file of NUCLEO-U575ZI-Q.

You can use the available ioc file and migrate from the MCU1 to MCU2 followed this FAQ: MCU1 to MCU2 migration option within STM32CubeIDE.

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Imen

[Harvey White]

The demo projects use BSP drivers, which rather ignore the IOC framework.

The basic problem is that none of the demo software is designed to be a part of a project.

There is a way around it, though, which requires a bit of work, but does work.

I have a 469I_disco board. I took the LTDC drivers from the demo, and added a standard IOC framework.

This will be an iterative process:

Find a demo that works for you. In my case, I wanted LTDC to work. That required the touchscreen driver, the SDRAM driver, and the DSI driver

.

When you create the project, be sure to set up defaults for connections. This sets up (connections to on board hardware according to the schematic of the board. You'd want to verify that with the schematic. Setting up the processor without the defaults, then adding the default connections will not account for the differences in the schematic.

The first, and easiest part, was to find the parameters for the SDRAM. With a copy of the SDRAM software (in main.c), I used the FMC part of IOC to create an instance of the FMC. IIRC, the connections should still be checked.

Next, go through the initialization in main.c, and compare it to the SDRAM driver that's part of the demo. This should give you the appropriate parameters for the board's memory.

Note that there is more to the initialization of the SD memory (as gotten from the SD memory data sheet). Once you set up the FMC, additional commands need to be sent to the chip. You get these from the complete data sequence in the SD driver. These additional pieces get added in the user sections of the main.c. Once this compiles and runs, you should have duplicated the same sequence of instructions in the demo.

For something like the LTDC, I was unable to split the DSI driver out with the LTDC part. I had to transplant the entire sequence of setups into my user program (again, main.c in the user sections). You can use their test routines to make sure that it works.

A word of warning: There may be some dependencies you MUST put in in CubeMX. For instance, I do not remember exactly, but I think you cannot use DMA2D without first having setup the LTDC (or something to that effect). The workaround is to add the required subsection (say LTDC), use the default setup parameters, then de-initialize the LTDC and run the routines you copied from the demo. The setup in main.c may be successful, it may not. However, the code generated (and I did try this) is insufficient to make the DSI and LTDC work. The demo code did work afterwards.

Depending on how you wish to use the driver itself, you may copy the low level LTDC drivers (line, square, fill, etc) and use them.

I put a C++ high level graphics structure on top of all this, which calls standard named routines in the low level (in this case, ST written) drivers. For driving another display type, I have the same named routines which are adapted to a different graphics chip (LTDC, S1D13517, and ILI9341). It does require a careful structure. The ST written (and my own) are not in C++, the are in C, and can easily be called from C++ routines.

So yes, you have to develop the IOC file yourself, but the board definitions can help you set it up.

The ST demo project can provide software, with the provisions that it was designed completely standalone,

Once you get the structure (with the ST software), you can easily add standard functions to the IOC file and it's your choice to use either the ST drivers or your own. Note that (for instance), the HAL drivers are encapsulated in drivers I have written, which are thread safe, structured to work with FreeRTOS, and match the rest of my software.