IOC file ordering

[Ian Day]

Hi, we use Git for source control and have notice that each time STM32CubeMX 6.1.1 saves the IOC file, the ordering of all the entries is changed. This makes it impossible to deal with in pull requests as you cannot tell if genuine changes have been made.

I've seen this reported before, and it was claimed that the IOC file should be saved in alphabetical order. It is not. The first few lines (after sorting the file before loading it) show as this after saving (and making NO changes):

#MicroXplorer Configuration settings - do not modify
PF7.GPIOParameters=GPIO_Label
PB13.GPIOParameters=GPIO_Label
PD12.GPIO_Label=PON_B9

[Khouloud OTHMAN]

Hello @Ian Day​ ,

Thanks for your feedback. Actually I can't reproduce the issue from my side, the IOC file is alphabetically sorted.

Could you please detail more how did you reproduce to get this misbehavior. Also you can attach your .ioc and the .log files, they may be helpful to find root-cause of the issue.

Thanks in advance,

Khouloud.

[Peter BENSCH]

@Ian Day​ Would you please also provide information about the Java version you are using with the tools incorrectly saving the IOC?

Regards

/Peter

[Ian Day]

Currently JAVA_HOME points to JDK 15.

java 15 2020-09-15

Java(TM) SE Runtime Environment (build 15+36-1562)

Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

[Ian Day]

Simply loading it up and hitting Ctrl-S. Not sure where you keep your logs?

[Peter BENSCH]

Java 15 is currently not supported.

The Release Notes RN0094 state:

• Minimum JRE version is 1.8_45 (known limitation with 1.8_251)
• Version 11 is supported
• Versions 7, 9, 10, 12 and upper are not supported

Please recheck with a version of Java that is known to work.

Regards

/Peter

[Ian Day]

Ok Thanks. Surely if its so dependent on a specific version set, it should check at startup and warn you.

[Ian Day]

Changed to JDK 11 and its still behaves the same.

[Khouloud OTHMAN]

Hi @Ian Day​ ,

Sorry for my late reply, be sure that I did not let go this issue, but even with trying different use cases and scenarios, this problem wasn't reproduced from my side ( as well as some of my colleagues from STM32CubeMX development team).

The latest STM32CubeMX version 6.2.0 is officially available, could you please retry with it ?

If the problem is still there, please attach the STM32CubeMX.log file that you'll find under <C:\Users\...\.stm32cubemx> directory, it may reveal something about this misbehavior.

Thanks in advance,

Khouloud.

[Ian Day · Accepted solution]

Hi, Just tried 6.2.0 and I can tell you that this version fixes the issue.

Thanks for coming back to me with that