uVision 5 crashes/freezes when closing

Sorry, my last message was wrong concerning asm("...").

Inline assembly by asm("...") also will block the code completion functionality / lead to this strange crashes if you close uVision 5.

(yesterday I installed 5.12, and at first I thought that asm("...") works, but now I just recognized that it does NOT work too... so you have to kill all inline assembly in your project if you want to use uVision 5).

Sorry, I have to correct the situation once more.

So from my experience so far:
If you use __asm{...} in any header file, then Code completion in uV5 will stop working quite immediately, latest on the next compile / make. Then the uVision 5 will crash on closing. On next restart you will get this message that "...uV crashed due to Code completion ... this functionality will not be used ...".

If you replace by asm("...") then it works.

But in a larger project now (about 20 cpp files, many classes, compiles to 42kB Code), I get this "code completion crash" even sometimes when just normally working (with or without asm("...")).

What helps then:
1. close uV5 (it will crash).
2. Restart (it will give the strange message).
3. Close again uV5 (it will work / no crash).
4. Restart again uV5 - now no strange message and code completion will work (until at some time it will stop working again ...).

For God sake, if you close uV5, then first all source files are saved nicely before the crash occurs... .

Hello bt,

And many thanks for responding to my thread. It seems you are experiencing quite
strange behaviour too, similar to mine. I find it difficult to reproduce any failing
sequence of actions with any consistency. I thought it seemed due to my Stellaris ICDI Debugger Interface on TI TM4C123GXL Launchpad, but you seem to strongly suggest the inline
assembly stuff. I am baffled at present and near exasperation - I have been struggling with this whole hardware and software system for days now and I think I'm going backwards !!!!

John O'C

But I do not have problems with the hardware - it works very nicely and I like the uVision system very much - the code completion is a great new feature since a later version of V4. (my system is a STM32F4 system with a multitude of interrupts, it is working very nicely and very impressive).

You just have to be careful of the following things:
- you have this problem with the code completion stuff (but to my experience this does NOT concern the compiler / code generation - it is just the editor which has problems with this code completion stuff - which elsewise is phantastic).
- ARM is very sensitive on correct chip setup - the compiler e. g. will NOT give you a warning, if you specify in the project settings "Use FPU", but in your chip setup FPU is not enabled. In this case you will just run into a NMI trap. It is VERY important that all NMI traps are enabled and that you catch them with an endless while loop - check the forums how to do this. When the controller somehow stops then, and you press STOP in the debugger, you will recognize that you ended up into such an endless while of a trap. Then in the window "Peripherals" "Core..." you get all the critical processor states - if anything strange has a checkbox there, then you should check why. Always best start with a safely running project, and then very carefully step further and further.
- The debugger is very impressive, but already in optimization level 1 this Keil compiler is optimizing extremely well. So well, that the debugger during debugging has severe problems to see the connection between c code and disassembly code. If you set a breakpoint in c, and this breakpoint is hit, then always be very cautious - it might very well be, that the c line contains of a register initialisation line and an "action line" - and due to optimisation these 2 lines are completely torn apart - e. g. the initialisation line might be some register init which the optimizer placed at the start of some interrupt routine. Then typically the breakpoint will be reached on the init line already (thus on any jump into the interrupt routine - not only on the action line - this of course is quite stupid behaviour of the debugger - it should recognize such a situation and place the breakpoint to the "action" assembly line). This can be extremely disturbing and misleading. Thus if you see some strange breakpoint coming, then best always have a close look at the disassembly and best place the breakpoint in the disassembly window, not in the C window. (or use the software breakpoint intrinsic __breakpoint()).

Another easy and straight forward way to get the code completion of uVision 5 to crash:

If you are inside a function and insert the following code at start of the function:

  const static BYTE ab[8]={ 0, 1, 2, 3, 4, 5, 6, 7};

After this the code completion will not work any more and uVision5 will crash on program end.

(I use cpp, STM32F407 with ST-Discovery, uVision 5.12, my PC is running WinXP).

bt and all others,

This is a problem with Windows XP. uVision5 is known to sometimes exhibit this behaviour if installed on a PC running Windows XP. Keil recommend upgrading to a newer version of Windows such as Windows7 or Windows8.

John O'Connor

That doesn't seem to compute.

It's more much, much, much more likely to still be a bug with uVision, even if that bug might not trig on Windows 7.

Per,

You may very well be correct, but Windows XP is a "dead" OS now and I doubt if Keil will be very bothered about correcting any bug in uVision to enable us to run with Windows XP. I have the few IDEs, programmers, debuggers, etc I use, all running very OK on Windows XP now for a few years. I just quake in my boots at the thought of upgrading to a new Windows OS......

JO'C

Correct - no new development for XP.

But the post sounded like the issue was with XP when the issue is most probably with uVision or one of the libraries that Keil is designing uVision around.

In this case, it's well known that developers tends to like to keep older machines, just because older machines has better support for older hardware. Remember how people kept their Win95/Win98 machines for a very long time because lots of PROM programmers etc didn't work with Win2k.

Two important things.
1) Bugs are "easy" when they can be reproduced.
2) Products that are vital to the organization (uVision is for Keil) should be designed in a way where there is access to all source code just to allow bugs to be fixed without need for external support.

So it should be quite easy/cheap to take a look at the issue and release a fix. And if Keil does not have all required source code, then it's time to take two steps back and consider risk factors.

Try to disable "Dynamic syntax checking" in Configuration->Text completion tab. I have disabled this feature and my Keil is not freeze now

Yes of course - then it will be fine.

Just this "Dynamic syntax checking" is so terrificly nice. With V4.74 it works, so I still use V4.74.

PS: I am quite sure that I already tested it also on a Win7 some months ago, and there I had the same problems with V7. Therefore I cannot believe that it is due to the operating system.

I have a same problem with uVision 5.15. I'm working on Windows XP SP3. Very frequently when closing ARM-project, uVision IDE just hang and to do something next it's need to kill uVision process from task manager.
But this is not the end. It's just the beginning. I found similar another problem.
I have simple ARM-project. If I try to complicate project, for example, make one more output target, using #ifdef #else #endif syntax and creating this target in Manage Project Items dialog, then when I try to save project, then close project and uVision and open project again.
At this moment uVision crashes with message box "uVision IDE has encountered a problem and needs to close.
We are sorry for the inconvenience
If you were in the middle of something, the information you were working on might be lost.
For more information about this error, click here"

If I click the link "click here", I see next information.
AppName: uv4.exe AppVer:5.15.0.0 ModName: unknown
Modver: 0.0.0.0 Offset c737594e
To view technical information about the error report, click here

Link "click here" show me next info:
Exception information
Code: 0xc0000005 Flags: 0x00000000
Record: 0x0000000000000000 Address: 0xffffffffc737594e
................
and so on

Can anyone something tell or help?