I am using KEIL MDK 5 and it is compiling very very slow.
Any ideas ??
I see the same problem when compiling STM32F429-DISCO based projects.
Compilation time in Keil MDK-ARM IDE can be significantly reduced by changing project's options: please uncheck "Debug Information" and "Browse Information" in "Output" tab of project's options. Below I attach picture with these two options highlighted.
This is not good solution. How am i suppose to find definitions now?? if this is the only solution than i cant use KEIL anymore.
This problem is new and it has began after upgrading to new versions. Before that everything was OK.
I think the problem is within the STM32F4CUBE drivers. ST changed something inside and caused the problem.
Many thanks Szymon for the suggestion. In my case a got the following results:
Tested the 'Rebuild' with checked and unchecked 'Browser Information':
-CubeMX v4.23 generated skeleton + 300 lines o custom code: 40s / 6s
-then migrated the project to CubeMX v4.24: 65s / 6s
In both cases I gained a lot for Rebuild process.
Test was performed a few times.
But you cant use the "go to definition" option without the Browse information checked.
True. Just tested the performance.
I confirm, that unchcking each of options, which I mentioned, introduces a drawback or limitation.
When you uncheck "Debug Information", durign debug session you will experience problems with debugging.
When you uncheck "Browse Information", you will experience problems with navigating in the source code.
But having in mind these two options you can decide to switch them on or off depending on the situation if you need them or not.
I don't have an information if latest STM32F4 Cube libraries compile longer than previous releases. But what I see on my side is that that Keil projects with F0/L0 HAL libraries compile much faster then Keil projects with F7/L4 HAL libraries. I guess that it is related to amount of code included in libraries (bigger libraries = longer compilation time).
You may consider to switch from HAL to LL for STM32F4 Cube. It should help a lot to decrease compilation time.
Already tested with ll library, and same problem.
I am talking about more than 2 minutes compiling time for 8k code size!!
This is not reasonable at all and it wasn't like that before.
Try to ask Keil support as well
KEIL is not the problem. Someone already asked it. see this discussion:
KEIL MDK V5 SLOW DURING TARGET BUILT
It can be a bit of a sloth, especially when "browser" information is checked, or your AV software drags.
If you have multiple real cores check options there. Hyper-threads tended to slow things back in the day.
I noticed this problem some time ago for F4 but ignored it because it has the impact only on Rebuild, not on the regular Build process (which actually takes much less time).
I see slightly longer Rebuild time when v4.24 is used.
problem on your side is due to the fact that stm32fxxxxx.h files (files with bit descriptions, peripheral memory addresses) have been enlarged by 2 additional definitions for every bit, and can go up to 20k lines of code in F7 family:
/* These 2 are new for every bit */#define PERIPH_REG_BIT_Pos 1#define PERIPH_REG_BIT_Msk (1 << PERIPH_REG_BIT_Pos)/* This one is old */#define PERIPH_REG_BIT PERIPD_REG_BIT_Msk
Keil cannot handle (apparently) big files for include. Similar problem does not affect GCC or IAR.
Retrieving data ...