How to reduce the full build times of STM32CubeIDE?

[JJ.Lin]

Hi,

The STM32CubeIDE verison is v1.7.0, and now I found it perform full build every time when I click the build button, but I have just built it and didn't modify the source file.So how to do the settings?A full build takes too much time!

Thanks!

[Pavel A.]

The Eclipse CDT builder has at least two annoying bugs, IIRC.

One is as you've found, if you start build and nothing is modified, it hangs at 13% for very long time.

Another is that it always rebuilds whole project (or most of files).

Apparently they are hard to fix, else they would be already fixed.

Try to switch from external builder to internal or v.v. Sometimes it helps.

[TDK]

Are you working on a shared drive, or a dropbox folder or similar where files are touched externally?

Eclipse should do an incremental build on a normal local file system. That's how it works for me for both internal and external builder. Hit Ctrl+B twice and the second build should not involve any compilation steps.

[thundertronics.com]

Turn off windows defender real-time protection and tampering protection (it will turn on automatically after a while, so need to keep an eye on it, or decide if you disable it permanently) and/or other antivirus software. Also check binary size. Often project\Debug\project.bin size may be around 500 megabytes (0.5GB !), and it is being rewritten during each build. You can avoid this by adding (NOLOAD) to linker script (*.ld) files, for example

.ram_d1_axi_sram (NOLOAD):
{
  . = ALIGN(4);
  *(.ram_d1_axi_sram)
} >RAM_D1
 
.ram_d3_sram4 (NOLOAD):
{
  . = ALIGN(4);
  *(.ram_d3_sram4)
} >RAM_D3

Reduced my binary size from 500mb to 100kb. Some windows systems may have invisible error logs rewritten 100 times per second in background (for example, twain error of an old Panasonic multifunction printer on win10), and it significantly slow downs writing operation of empty 500mb firmware binary. Check for such logging and other unnecessary activity using Event Viewer and Task Manager (cpu, disk activity), also can use Process Monitor utility: filter out all build activity and record what's going on in parallel.

To sum up, 1) add "NOLOAD" to linker script, 2) disable win10 defender real-time protection; and if it does not helped, 3) check CPU/HDD activity in idle and build state.

[Pavel A.]

If you're asking me, the 1st buggеr occurs for me on a local drive, not shared with dropbox or anything. But some paths referenced in the projects are symbolic links (also to local drives), and windows defender is enabled.

Still using v 1.7.0, not updating to 1.8 yet.

It is probably related to parallel build enabled.  

[Markus GIRDLAND]

Yeah, as TDK mentions STM32CubeIDE inherits the behavior of Eclipse and should do an incremental build each time... it does it on my computer at least.

Usually you would need to explicitly tell the builder to do a clean build in order to rebuild the entire project.

If you have any step-by-step instructions on how to make CubeIDE do a clean build each time even on a local drive then please let me know and I'll be sure to submit a ticket to the devs.

[mattias norlander · Accepted solution]

@thundertronics.com​, the issue you mention is a known one. The bin-file format does not contain address information, so the linker fills the space between the memory regions with some pattern. In CubeIDE 1.9.0 we disable default generation of bin-files. It is a more sane default option in our opinion.

CubeIDE relies only on elf-files anyway.

Another known issue is that each time you do the following cycle:

1. update the ioc-file (with CubeMX integrated or stand-alone)
2. save the ioc-file
3. click generate code to update the files in the project

At this point the tools does not only update the few files that were modified. The whole HAL_Drivers folder and probably a lot of other folders are completely overwritten. This is far from optimal...

...When you inside CubeIDE click build, the Eclipse/CDT build system checks all source folders and include paths for files that has been touched since last build.

Since MX touches tons of files --> CubeIDE will be forced to re-build all of them.

To me, this is the main bottleneck for users modifying the ioc-file a lot.

Internal ticket references# 96485, 42230

[RS009]

I also stuck in the same problem , I tried many ways but finally I changed the workspace and it worked for me. May be I had a different problem I am not sure.