2016-06-27 01:53 PM
So I've spent two entire days trying to figure out why STM32CubeMX v4.15.1 would not generate my project properly (which had been working under v4.14). It would totally mess up an existing project, would not create the startup assembly file, and my TrueStudio project would no longer compile any of my application-specific code.
I finally figured it out (sort of), but have no explanation for why this worked. I already sent this information to Atollic (although it is ST's problem), and I will repeat it here:I finally figured out what was wrong (sort of) by comparing two different .ioc files. One was from a project that worked, and the other was from my non-working project.
There was no Toolchain Location specified in the non-working .ioc file, although it was properly shown in the Settings dialog (go figure). So I copied the information from the working project to the non-working project.The working project had a line in this format:
ProjectManager.ToolChainLocation=C\:\\Development\\STM32CubeMX\\MyWorkingProject
However, when I copied it to the nonworking .ioc file and changed the project name, I ACCIDENTALLY copied an extra ‘=’ sign. So I had:
ProjectManager.ToolChainLocation==C\:\\Development\\STM32CubeMX\\MyNonworkingProject
Here’s the strange part – THAT WORKED.
I then modified it again to be as follows, so that it was exactly like the other project that works:
ProjectManager.ToolChainLocation=C\:\\Development\\STM32CubeMX\\MyNonworkingProject
I tried to generate the code, but that DID NOT WORK!
I then did it again with the two equals signs, and it worked, and then I saved the 'Cube project and opened the .ioc file. The line now contained:
ProjectManager.ToolChainLocation=\=C\:\\Development\\STM32CubeMX\\MyNonworkingProject
When I tried to regenerate code, I got a failure again.
I then tried a different format just for grins:
ProjectManager.ToolChainLocation=\\C\:\\Development\\STM32CubeMX\\MyNonworkingProject
Note that this format is different than the one from the MyWorkingProject. Guess what – this one worked, and when I closed the project it remained the same, and when I opened it and regenerated it, it worked again. Both of the projects were using the same STM32CubeMX version, so why the difference in the toolchain location format is beyond me.
I don't know what's going on, but I posted this in case anyone else runs into this problem when upgrading their CubeMX to 4.15.1. FYI, I tried migrating the F7 library to the latest version, and it broke my program (see my post about the broken UART), so I had to also manually go into the .ioc file and change the firmware version back to v1.3.1 from v1.4, since STM32CubeMX only lets you migrate in one direction. This is a problem ST, especially when your 'upgrades' cause working programs to fail. I hereby request that you allow the user to select from any of the installed firmware versions in the Settings dialog.Solved! Go to Solution.
2016-11-03 01:40 AM
Hello,
STM32CubeMX 4.17 is out and should fix your issue. Can you confirm you no longer encounter the problem?
Thank you
2016-06-27 02:03 PM
Damn, I spoke too soon.
It did generate the code without giving me an error dialog, but the TrueStudio program will not compile anything other than the STM32CubeMX-generated code and drivers. All of my application-specific files are ignored. This is really aggravating, not to mention costing my project a lot of money.2016-11-03 01:40 AM
Hello,
STM32CubeMX 4.17 is out and should fix your issue. Can you confirm you no longer encounter the problem?
Thank you