no IOC file for a published U585i-IOT02a example?

[kent-dorfman]

Given that it is very easy to cause signal conflicts when configuring an MCU using the CubeMX initialization program, it is extremely important to include the IOC file for any particular example published.  This being for comparison when trying to use an example as a base and extrapolate additional functionality.  Since the CubeMX program is cryptic about about signal conflicts, being able to inspect the IOC is the only/best way to quickly determine how things are set up.   Also, it is needed if using the example project as a base for further experimentation.

U585i-IOT02A BSP example does NOT contain the IOC file used to initialize the MCU for the project.

 

 

[STTwo-32]

Hello @kent-dorfman 

Some of the examples provided on our Packages are not based on a .ioc file since they are not using CubeMX for basic configurations.

Best Regards.

STTwo-32 

[Pavel A.]

@kent-dorfman 

>Since the CubeMX program is cryptic about about signal conflicts, being able to inspect the IOC is the only/best way to quickly determine how things are set up.  

What is the problem with signal conflicts? You just open the .ioc in CubeMX/IDE and it shows assigned (green) vs. free (gray) pins. Also it can find alternative pins for selected function. Assignment of pins for "peripherals" requires to enable the "peripheral" first, otherwise the pins will go to limbo state. In multi-core chips pins can be assigned to cores. Cube won't allow pin conflict.

Of course having .ioc files is better than no ioc, but for some example projects they are unavailable. You can try and create the .ioc file for your project, based on the initialization code (reverse-engineer the code to .ioc, so to say).

 

[kent-dorfman]

OK. I'll accept that not all examples are based on an IOC file.  I don't like it, but I'll accept it. LOL

re conflicts. I'm using one of the more complex MCUs U585...Consistently, trying to set up the unit in CubeMX, conflicts arise in the OCTOSPI and/or USBPD subsystems, even thought I'm not using them, and in fact, don't even configure those components, but mark "make all unused pins analog".  Cannot tell you how many times I've tried to set up a USART and am told that the pins conflict with one of the other subsystems, only to go to that subsystem and it's marked as disabled and the documented pins are "grey".  Frequently get the "partially configured" error with no logic way to resolve.  I'm not convinced the IOC generation ruleset is correct for my particular MCU model.

Thus the reason an IOC file is important: to compare against what the GUI is showing.

 

 

 

[Pavel A.]

Some peripherals IIRC have unique pins that do not have alternatives (FMC, some OSPI, Ethernet...) If their pins are taken, this indeed is a conflict. Then one of conflicted things must be disabled. I don't understand how the .ioc file can be used or abused to resolve a genuine conflict.