I am using uVision V18.104.22.168 running under Windows 10, building code for various STM32F parts.
My problem is that the IDE stops responding at various places for a long time, sometimes over 5 minutes, occasionally over 10, but eventually recovers.
This happens mostly at the completion of a build, occasionally on entering a debug session and occasionally when leaving a debug session.
While it isn't responding, a quick look at the Windows task manager shows the IDE is still consuming processor time, around 20%, and using a lot of memory, anything up to 2 GB!
It is becoming an issue that I have to wait for so long after running a build, and I would really appreciate a fix to this problem.
V5.28 is downloadable now, perhaps start with that?
Unfortunately I'm not permitted to do this by my client. They started with 5.18 and have to stay with that version for the life of the project. :(
Then you'll have to live with whatever quirks that are present. You could use a faster or multi-core system, more memory or an SSD.
V5.28 does seem to have a short dwell after build completion, but that's only a few seconds on a QC Xeon as the IDE collects itself. Perhaps as the entire memory space has been tainted by the build and translation/generation on transient data held in cache or write-back queue.
You could still try the new version - that could help to determine whether it's something to do with that old version, or some problem due to your build machine.
Have you tried disabling virus scanner, Windows indexing, etc ... ?
People don't often appreciate it, but AV can be a huge drag
Also, is all your project entirely on local drives? Network stuff could slow things down unpredictably ...
Do you have version control or any other such stuff "hooked-in" which could be slowing things down?
This client is particularly driven by the IT department, so no option to download or install any updates. It is holding the project back, however it is their policy and I have to abide by it. The strange thing is that when I started working on this project the issue wasn't there, it seems to have 'grown' over the last few weeks.
No, all local and no version control hooked into uV.
No permissions to do that unfortunately.
jartim said:This client is particularly driven by the IT department
So get the IT department to help!
jartim said:It is holding the project back
That's something you need to flag to project management!
jartim said:when I started working on this project the issue wasn't there
So if you pull a version of the project from back then - does it have the problem now?
If you have (or your client has) a licence, you should contact Keil support direct.
I think Andrew might be thinking of Windows Explorer (Shell) Extensions, the sort of thing Tortoise CVS/SVN do. Where as AV is probably at a filter driver level.
Another thing to watch is the generation of Browse information, this has been a complete dog in uV for years, not sure if it was written by an intern using bubblesorts, but it turns the compile exercise into one where you can go brew a pot of tea/coffee waiting for it. Feels very 1986 TBH.
You mentioned issues when entering and leaving a debug session. That could be a separate issue. What debug adaptor are you using with your STM32F board? A ST-Link? A J-link?
If so, those debug adaptors use a 3rd party dll. If you have too new of a debug adaptor, the firmware on it might not play nice with the old dll.
See " Downgrade the firmware of the ST-LINK debug adapter:" on this page http://www.keil.com/support/docs/3662.htm to see if that would help. Ditto fora J-Link.
If you are using a ULINKpro, ULINK2, and CMSIS-DAP, you should ask your IT group if you can update to 5.18a, since they fixed an issue with the drivers in that small patch. See: www.keil.com/.../MDK518a.htm
View all questions in Keil forum