Skip to main content
olivier.schmitt
Visitor
September 3, 2026
Question

STM32CubeMX hangs during first code generation on network U: drive – FileNotFoundException in MXTmpFiles

  • September 3, 2026
  • 0 replies
  • 17 views

Hello,

I am experiencing a reproducible issue with STM32CubeMX when generating a project for the first time on our U: drive.

Our environment is part of an Active Directory domain, and each user has a U: drive mapped to their personal network home folder.

Error in STM32CubeMX.log

During generation, CubeMX successfully creates several temporary files in:

 
 
U:\FreeRTOS_M2\testv10\MXTmpFiles\
 

For example:

 
 
17:02:54.994 oldGeneratedFile ...\rtos_kernelStart.tmp_save
17:02:55.076 Generated code: ...\rtos_kernelStart.tmp
 

However, during the next generation pass, CubeMX tries to access the .tmp_save file again:

 
 
17:02:56.195 oldGeneratedFile ...\rtos_kernelStart.tmp_save
17:02:56.200 ERROR ProjectBuilder

java.io.FileNotFoundException:
U:\FreeRTOS_M2\testv10\MXTmpFiles\rtos_kernelStart.tmp_save
(The system cannot find the file specified)
 

The relevant part of the stack trace is:

 
 
java.io.FileNotFoundException:
U:\FreeRTOS_M2\testv10\MXTmpFiles\rtos_kernelStart.tmp_save
(The system cannot find the file specified)

    at java.io.FileInputStream.open0(Native Method)
    at java.io.FileInputStream.open(FileInputStream.java:213)
    at java.io.FileInputStream.<init>(FileInputStream.java:152)
    at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:1138)
    at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:1091)
    at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:1038)
    at com.st.microxplorer.codegenerator.CodeEngine.genCode(CodeEngine.java:302)
    at com.st.microxplorer.codegenerator.CodeGenerator.generateOutputCode(CodeGenerator.java:6698)
    at com.st.microxplorer.codegenerator.CodeGenerator.generateSpecificCode(CodeGenerator.java:5484)
    at com.st.microxplorer.codegenerator.CodeGenerator.generateSpecificCodeFile(CodeGenerator.java:1906)
    at com.st.microxplorer.codegenerator.CodeGenerator.generateCodeFiles(CodeGenerator.java:2289)
    at com.st.microxplorer.codegenerator.CodeGenerator.generateDefaultConfig(CodeGenerator.java:11396)
    at com.st.microxplorer.codegenerator.CodeGenerator.generateCode(CodeGenerator.java:1612)
    at com.st.microxplorer.plugins.projectmanager.engine.ProjectBuilder.generateCode(ProjectBuilder.java:3469)
    at com.st.microxplorer.plugins.projectmanager.engine.ProjectBuilder.createCode(ProjectBuilder.java:2272)
    at com.st.microxplorer.plugins.projectmanager.engine.ProjectBuilder.createProject(ProjectBuilder.java:821)
    at com.st.microxplorer.plugins.projectmanager.engine.GenerateProjectThread.run(GenerateProjectThread.java:61)
 

What is interesting is that the rtos_kernelStart.tmp file is successfully generated immediately before the failure, together with the other FreeRTOS temporary files.

Workaround / additional observations

If I kill the STM32CubeMX process after it hangs, reopen CubeMX and open the same project, code generation succeeds on the second attempt.

This behavior is reproducible.

More importantly, if I create exactly the same project in a local directory such as:

 
 
C:\temp\testv10
 

code generation succeeds normally on the first attempt.

Therefore, the problem seems to be related to file handling, temporary file creation or file renaming in MXTmpFiles when the project is located on our network U: drive.

It looks like there may be a timing or file access issue between the creation of:

 
 
rtos_kernelStart.tmp
 

and the handling of:

 
 
rtos_kernelStart.tmp_save
 

Could you please confirm whether this is a known issue in STM32CubeMX 6.18.1-RC2, especially when projects are stored on a mapped network drive?

Is there any workaround that would allow us to continue generating and storing STM32CubeMX projects directly on the U: drive? The U: drive is each user's personal network home folder in our Active Directory environment, and our students are not permitted to write files to other locations.

I have attached the complete STM32CubeMX.log.

Thank you.

    Terms & ConditionsAccessibility statement