2025-10-24 9:36 AM
I may have found a CubeMX migration bug. I'm using version 6.14.1.
I am developing a product based on the STM32G0B1 subfamily. The original MCU is STM32G0B1KBU6 which has 128K Flash.
I need more flash, so I need to migrate the source code to the STM32G0B1KEU6, which has 512K Flash. The other functionality (e.g. pin outs, peripherals) are identical.
To migrate the CubeMX project, This procedure was followed:
https://community.st.com/t5/stm32-mcus/how-to-switch-from-one-stm32-to-another-using-stm32cubemx/ta-p/49884
That post, which was posted by an ST Employee, was updated on August 6, 2025 (less than three months ago).
I was able to import my existing KBU6 CubeMX project into a new project that targeted the KEU6 MCU. When I clicked GENERATE CODE, it eventually gave me this error dialog:
Eclipsec
An error has occurred. See the log file
C:\Users\XXXXX\.stm32cubeide\workspace_7364571360629961633\metadata\.log.
That log file fairly short, it's at the bottom of this post. I was still able to compile, link, and flash my device; however, the linker files, "STM32G0B1KBUX_FLASH.ld" and "STM32G0B1KBUX_RAM.ld" still had the same name and the contents of those linker files didn't change at all. I also did a file-by-file comparison of the entire project's files and every single one of them were identical to the original project.Wouldn't the contents of the linker files reflect the size of the flash in the new part (KEU6)? The two FLASH and RAM linker files have this line in it:
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K
They should look like this:
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
I figure that at least some file names would been changed to reflect the new part and have new names like, "STM32G0B1KEUX_FLASH.ld" and "STM32G0B1KEUX_RAM.ld". These issues tell me that CubeMX encountered an error such that it was not able to complete the migration.
I see that there is a new version of CubeMX, version 6.15.0. I looked in the release notes for v6.15.0 and there is no mention of this bug. I upgraded to v6.15.0 but the problem remained. Also, there were no updates to the installed STM32Cube MCU package. The version of STM32Cube MCU Page for STM32G0 Series is v1.6.2.
The project's directory name has no spaces or other weird characters. The path contains only letters and the entire path is less than 20 characters.
Thanks.
P.S. Here is the error log, "C:\Users\XXXXX\.stm32cubeide\workspace_7364571360629961633\metadata\.log":
!SESSION 2025-10-21 00:32:58.508 -----------------------------------------------
eclipse.buildId=unknown
java.version=21.0.3
java.vendor=Eclipse Adoptium
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -application com.st.stm32cube.ide.common.services.mx.rcpApp -rmiServerPort 63354 -projectUpdate -buildType exec -src cube -cubeScratchFile C:\XXXX\YYYY\mx.scratch
Command-line arguments: -os win32 -ws win32 -arch x86_64 -application com.st.stm32cube.ide.common.services.mx.rcpApp -data C:\Users\XXXXX\.stm32cubeide\.workspace_7364571360629961633 -rmiServerPort 63354 -projectUpdate -buildType exec -src cube -cubeScratchFile C:\XXXX\YYYY\mx.scratch
!ENTRY org.eclipse.osgi 4 0 2025-10-21 00:33:02.827
!MESSAGE Application error
!STACK 1
java.lang.NullPointerException: Cannot invoke "org.eclipse.core.runtime.IPath.toOSString()" because the return value of "org.eclipse.core.resources.IResource.getLocation()" is null
at com.st.stm32cube.common.projectcreation.core.ProjectUtilities$ProjectRessourceVisitor.visit(ProjectUtilities.java:845)
at org.eclipse.core.internal.resources.Resource.lambda$1(Resource.java:154)
at org.eclipse.core.internal.resources.Resource.lambda$0(Resource.java:122)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:90)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:90)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:90)
at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:127)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:131)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:92)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:154)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:142)
at com.st.stm32cube.common.projectcreation.core.ProjectUtilities$ProjectRessourceVisitor.getResources(ProjectUtilities.java:852)
at com.st.stm32cube.common.projectcreation.core.ProjectUtilities.removeProjectOrphanLinkResources(ProjectUtilities.java:825)
at com.st.stm32cube.ide.common.services.project.ProjectUpdateService.doProjectUpdate(ProjectUpdateService.java:76)
at com.st.stm32cube.ide.common.services.project.HierarchicalProjectTreeSetupService.HierarchicalProjectTreeSetup(HierarchicalProjectTreeSetupService.java:170)
at com.st.stm32cube.ide.common.services.project.HierarchicalProjectTreeUpdateService.doProjectUpdate(HierarchicalProjectTreeUpdateService.java:51)
at com.st.stm32cube.ide.common.services.adapted.core.project.ProjectUpdateRcpServiceProcess.doProjectUpdate(ProjectUpdateRcpServiceProcess.java:275)
at com.st.stm32cube.ide.common.services.adapted.core.project.ProjectUpdateRcpServiceProcess.doProjectUpdate(ProjectUpdateRcpServiceProcess.java:269)
at com.st.stm32cube.ide.common.services.adapted.core.project.ProjectUpdateRcpServiceProcess.doProjectUpdate(ProjectUpdateRcpServiceProcess.java:173)
at com.st.stm32cube.ide.common.services.adapted.core.project.ProjectUpdateRcpServiceProcess.run(ProjectUpdateRcpServiceProcess.java:120)
at com.st.stm32cube.ide.common.services.mx.core.project.ProjectUpdateRcpService.doProjectUpdate(ProjectUpdateRcpService.java:171)
at com.st.stm32cube.ide.common.services.mx.core.project.ProjectUpdateRcpService.run(ProjectUpdateRcpService.java:166)
at com.st.stm32cube.ide.common.services.mx.update.MxUpdateProjectRcpService.run(MxUpdateProjectRcpService.java:116)
at com.st.stm32cube.ide.common.services.mx.update.MxUpdateProjectRcpService.run(MxUpdateProjectRcpService.java:108)
at com.st.stm32cube.ide.common.services.mx.rcp.CubeIdeServices.start(CubeIdeServices.java:96)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:208)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:143)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:109)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:439)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:271)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:668)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:605)
at org.eclipse.equinox.launcher.Main.run(Main.java:1481)
!ENTRY org.eclipse.core.resources 2 10035 2025-10-21 00:33:02.924
!MESSAGE The workspace will exit with unsaved changes in this session.
2025-10-27 12:05 AM
Hello @JimBlankenship
First let me thank you for posting.
Your request is under investigation, and I will get back to you ASAP.
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-10-30 7:23 AM
Hello @JimBlankenship ,
The issue was not reproduced with STM32CubeMX 6.15.
For more investigation I suggest that you provide your original Ioc.File created with STM32G0B1KBU6.
I will be waiting for your feedback.
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-10-30 12:30 PM - edited 2025-10-30 1:19 PM
I tried again to upgrade CubeMX to 6.15.0. This time the MCU migration worked; CubeMX migration to a new MCU occurred without error.
However, when generating code, the linker filenames did not change. The contents of the linker files did not change, either. They still have the size of the KBU6 flash, 128K, not 512K of the KEU6. They are still named, "STM32G0B1KBUX_FLASH.ld" and "STM32G0B1KBUX_RAM.ld". Shouldn't be named with "...KEUX..."?
I checked all the source files and they didn't change at all either, not even the .s startup file. The assembly startup file is still named "startup_stm32g0b1kbux.s"; the contents thereof are the same as before. I figured that it would be renamed to something like, "startup_stm32g0b1keux.s".
Perhaps it's easier to migrate only the CubeMX .ioc file to the new MCU and under CubeIDE, port the user code manually.
2025-10-31 2:02 AM
Hello @JimBlankenship ,
The behavior described was not reproduced by my side. By creating a project with STM32G0B1KEU6 and importing STM32G0B1KBU6 settings, STM32G0B1KEUX_FLASH.ld and STM32G0B1KEUX_RAM.ld are generated.
Could you provide the Ioc.File with which you are experiencing problems?
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.