2020-05-28 11:51 AM
Hello,
I'm relatively new to embedded development and have been taking a driver development course that uses STM32CubeIDE. The the board I am using is STM32F407VG Discovery Kit. Basically, I have been creating multiple src main files to test out my driver code and have been using the Properties->C/C++ Build-> "Exclude resource from build" to decide which code to use.
My issue started when I forgot to remove one of the src files and tried to build the project with 2 src files with a lot of overlapping code. After I removed one of them from the build, I started getting the follow message during attempts to build:
12:37:34 **** Clean-only build of configuration Debug for project stm32f4xx_drivers ****
make clean
rm -rf *
rm: can't remove 'stm32f4xx_drivers.elf': Permission denied
make: [makefile:65: clean] Error 1 (ignored)
When I try to interact with the stm32f4xx_drivers.elf file outside of the IDE, it appears that it is open somewhere. I am able to fix the problem temporarily by closing the IDE and then removing the file. But after the first subsequent build, I am getting the same error. I also noticed that the stm32f4xx_drivers.elf appears as a drop down that contains all .h and .c files. When I try to exclude a resource, let's say fileA, from the build and include fileB, I can see that fileA is no longer included in the drop down (it's grayed out), but it appears that fileB is not added.
I'm not extremely familiar with the compile process or make files, and I don't really know what the .elf file is used for or if what I am seeing is related to the error I am getting.
I'm looking to understand what's going on, what might have caused it, and/or how I can fix the problem so that I don't have to close and re-open the IDE every time I want to use a new src file.
Thank you!
UPDATE/SOLVED: It seems like after deleting the .elf file again and rebuilding, it appears to be working again. I'm not exactly sure what I did differently, however, previously, I was able to use Process Hacker to locate a handle to the .elf file, meaning that it was open somewhere. Now the file is handle can't be found. All this to say, it seems like the file was in fact open somehow. Thanks to TDK for the help.
Solved! Go to Solution.
2020-05-28 12:20 PM
Sounds like the IDE has the file open somewhere. Some solutions here. Note that STM32CubeIDE is built on Eclipse, so you may include that term when trying to find a solution.
https://stackoverflow.com/questions/2660961/eclipse-could-not-delete-error
2020-05-28 12:20 PM
Sounds like the IDE has the file open somewhere. Some solutions here. Note that STM32CubeIDE is built on Eclipse, so you may include that term when trying to find a solution.
https://stackoverflow.com/questions/2660961/eclipse-could-not-delete-error
2020-05-28 01:54 PM
Thank you for the tip and for the form! Not sure exactly what I did differently, but deleting the file again, seems to have fixed the problem.
2021-05-23 01:03 PM
I have always been getting this problem, with the error message usually appearing when I do a Clean Project (which is necessary occassionally because Cube gets itself confused sometimes). One has to come out of Cube (close it) and delete the file in Explorer.
The file is NOT being marked read-only, so another process is owning it.
Win7-64.
Quite annoying.
2021-05-23 01:21 PM
Either the IDE or the debugger has a handle on the file. Perhaps a resource leak.
In Win32 API see this also when people hold a Mapped View of File (basically adds it to the page file), Keil had an issue ~5.25 where they syntax check task had a race condition vs the save/compile.
Wouldn't have thought this would be difficult for the Software QA team to chase to ground.
2021-05-23 01:56 PM
Yes; I believe this is the same issue with the debugger sometimes disappearing, until one exits Cube and kills the process in windows task manager (the only other way is a whole PC reboot).
I probably have one of those process explorer utils which can tell you which process owns a file; will try to remember that next time. Had to delete the .elf file manually 3x this evening!
Could well be the debugger; I will try next time if killing its process frees up that file.
2021-05-24 01:11 AM
Yes, stopping the stlinkserver.exe process seems to do the job.
If I use a Segger debugger, instead of STLINK, will the same process be created?