Bug: STcubeIDE - CubeMX completely destroys project

[Dave Nadler]

I have a working project in Atollic 9.1 with the CubeMX 5.0 plugin.

I imported the project into STCubeIDE per instructions in UM2578.

The import process reported no errors.

The release config is gone - destroyed during import (see separate bug report here: https://community.st.com/s/question/0D50X0000AnuVOVSQ2/stm32cubeide-import-from-atollic-deletes-release-configuration)

However, the debug configuration properly builds and loads/debugs.

In the CubeMX perspective, I can open the IOC file from the project (written by the CubeMX 5.0 plug-in), but...

'Generate Code' completely obliterates the entire contents of the project (everything is deleted from disk and IDE).

To help you debug this problem, the IOC file is attached.

Are you aware of this problem? @Markus GIRDLAND​ ?

Is there going to be a version of this software that actually works any time soon?

Thanks!

Best Regards, Dave

[Tesla DeLorean]

https://community.st.com/s/question/0D50X0000B07u7USQQ/how-do-i-report-a-critical-bug-to-st

I hope ST starts taking this stuff a lot more seriously, it is account losing dysfunction.

@Dave Nadler​ does the stuff go to the Recycle Bin or is it totally wiped?

[Dave Nadler]

@Community member​ - It's totally wiped (though of course I made a backup before I tried this)...

[Markus GIRDLAND]

I've done some testing when this first came up and wrote a ticket for it, so it's in the hands of the CubeMX team at the moment.

In my tests I found that older versions of CubeMX (5.1.0 and older) that generates a TrueSTUDIO project and then gets imported to CubeIDE will delete release config and if you use Ctrl + S -> Generate code it will delete the user code and replace it with standard MX code. It did not remove the entire project in my tests, still a very bad result though.

However, if I used Project -> Generate Code (Alt + K) it did work as intended and kept user code.

I tested with various versions of CubeMX and various ways of converting the project and the only time I could get it to work like expected was when CubeMX version 5.2 generated a TrueSTUDIO project that was then imported through CubeMX, that let me keep my release config. Still had to use Alt + K to generate, though.

tl;dr: Big problem, ticket written

[MFend]

I converted an Atollic TS 9.3 project to STM32CubeIDE.

Everything seems to have gone smoothly - EXCEPT that after compiling the project, I can't debug using the STM32CubeIDE - and when i load the binary file with a JTAG, it behaves differently (the times are all off - noticed in the blink of the LED and the time it spends in Start-up mode)

Now that I converted the project, I'm having a hard time going back to Atollic TS. Of course I saved a backup, but I get the following log from Atollic TS (which never appeared before) :

!SESSION 2019-06-26 12:02:53.878 -----------------------------------------------

eclipse.buildId=unknown

java.version=1.8.0_181

java.vendor=Oracle Corporation

BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US

Framework arguments: F:\work\FlameDetectors\4040D - TrueSTUDIO\4040D_TS\.project

Command-line arguments: -os win32 -ws win32 -arch x86 F:\work\FlameDetectors\4040D - TrueSTUDIO\4040D_TS\.project

!ENTRY org.eclipse.osgi 4 0 2019-06-26 12:02:57.260

!MESSAGE Application error

!STACK 1

java.lang.NoSuchFieldError: url

at org.eclipse.jface.resource.URLImageDescriptor.createImage(URLImageDescriptor.java:258)

at org.eclipse.jface.resource.ImageDescriptor.createImage(ImageDescriptor.java:224)

at org.eclipse.jface.resource.ImageDescriptor.createImage(ImageDescriptor.java:202)

at org.eclipse.ui.internal.Workbench.initializeImages(Workbench.java:1892)

at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:800)

at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:160)

at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:173)

at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:116)

at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)

at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)

at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)

at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)

at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)

at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)

at org.eclipse.equinox.launcher.Main.run(Main.java:1519)

[Tesla DeLorean]

This is perhaps Off-Topic, consider starting a new thread describing problems unrelated to the one the thread is discussing, that way each specific issue can be addressed distinctly.

[Tesla DeLorean]

Thanks.

More generally one would want to identify ALL routines where files/folders can be wiped indiscriminately, and perhaps a) alert the user to the impending action, and scope there of, and b) do so in a way that Windows can undo/unwind the operation.

This might include operations where a "Create Always" type flag causes unanticipated damage.

In terms of scope of the action, have some expectations about how many files/folders will be impacted, check for that, and if that breaches sane limits, bugcheck or assert so you can find and isolate these problems in testing.

[Dave Nadler]

@MFend​ - This looks like a different problem; please start a separate thread!

Thanks,

Best Regards, Dave