I warn anybody before using ARM Keil 4.13a. It generates defective code. I have spent several hours with debugging a code that has been already worked. The problem affects local variables of functions and passing arguments. Code has been wrongly compiled without any optimization. I have no courage and time to test optimizations.
I also encourage Keil not to publish Keil 4.13a any more.
Keil 4.12 seems to be OK.
It has already been pointed out that there are known issues with the Debugger...
Oops - I guess this happens when you are working on a Sunday @ 1AM.
On preparing my bug report to Kiel, I spotted an extra '&' that was killing my code. The funny thing is that also messed up the Locals window. Go figure.
Cheers.
I think I can second this. I am also having problems with pointers and passing arguments.
Look at this GIF animation:
http://bleyer.org/keil/ptr.gif
The "usbPackBufRx" function receives a "PackBuf" object through the "buf" pointer. It gets the actual object through a FIFO call, and the address value is, correctly, 0x2000_014C.
After that I call the "processBuf" function with "buf" as its argument. However inside that function, the buffer pointer value is passed as 0x0000_0000.
Also, the debugger is giving me some weird information in the Locals window. For example, some return value shows as 0x4C (byte) although it should be zero (int).
I wonder if Keil has proper regression tests when releasing new versions of the compiler. Any decent C test suite should have been able to catch this.
I hope we have a fix soon. I will revert back to 4.12.
I send a full project to the Keil support. I hope it proves useful when solving this problem, whether it is my own code or the compiler.
Regards, Roel
Alexander,
Any luck this time around...?
Hello Roel,
please send a full example project to Keil Support (support.intl@keil.com). As long as Keil Support don't have an example to reproduce the problem we can't say anything about the root cause.
Best regards, Alexander Zaech Senior Support Engineer ARM Germany GmbH
I have a similar experience with Keil 4.13a.
The following code enters an infinite loop when compiling with optimization levels 2 or 3.
unsigned int x = 0x12; while (!((x & 0x02) && (x & 0x10))) {} // turn on LEDs here
I observed the infinite loop by turning on some LEDs after the loop. With O2 and O3 the LEDs remain turned off.
This was tested on the MCB2300 test board with µVision V4.13a.
Hi guys, the source code mentioned by Jaroslav works flawlessly when compiled by V 4.12, but binary compiled by V 4.13a is really defective - may be Jaroslav did not emphasize this clearly enough. So it apparently is not a bug in source code. It's really a basic C/C++ functionality what is not working - for example locally declared object in a method of some other class does not properly execute it's constructor - and thus is not initialize at all. Also parameters are not correctly passed to a functions. I'm a colleague of Jaroslav - I've seen this issues with my own eyes...
Bottom line: May be .13 in the version number is not happy enough number ;-)
"I have spent several hours with debugging a code ..."
Do you think several hours is enough to spend on a problem that is as important as you suggest?
Did you step through the assembler for the function in question to verify what was really happening?
You may be right when you say "it produces defective code", but it might be better for both you and Keil to get as much concrete evidence as possible for Keil to examine. I also have proprietary code, but I managed to narrow it down to just 4 lines of (faulty) assembler that was being generated from 30 lines of C source. When I handed it to Keil I was as sure as I could be that I had actually found a genuine, reproducable problem.
If you look at linked image, you could see two objects ss and ssss. Object ss is an automatic object, and it was not initialized properly.
It is very hard for me to prepare test-case snapshot that reproduces Keil bug from two reasons: A, I cannot send our proprietary code, so I have to write different code that triggers a bug. B, My manager expects me to work and not to debug a Keil.
But anyway, I will look at this issue deeper when Keil hotline answers me something.
The only issue I have found, created a snapshot of, and reported to keil is the debugger reporting the wrong value of automatic variables. It is not easy to reproduce - changing one line of code will correct it! However, I did manage to reproduce a serious failure of the tool chain and and posted it to keil but they somehow failed to get it to run on an evaluation board (I need to do it myself). A function, not being called at all from anywhere in the software, will cause a controller "abort" upon startup. But when the function is removed - again, it has no side effects - the controller will startup correctly. I will try to reproduce it this week - the code is attached to a Keil case.
#It must be at least as likely that the fault lies in your source code?
Believe me, you are lucky because you are not facing this issue.
This has been my original report to Keil Intl before I have found that this issue affect also regular function call. I do not know what triggers this issue.
-------------------------------------------------------------------------- Please look at this image: www.penguin.cz/.../CtorFailure.gif
Dear Keil support,
I am facing a problem that automatic variables are not initialised properly - see attached image
I have debugged a code and ctor is called in both cases. But for a variable on stack it does not initialise object properly.
class string { private: static char Dummy; char *ch; unsigned int maxlen; unsigned int size; void resize(unsigned int NewMaxlen); public: explicit string(unsigned len); //explicit is expanded to private: for obsolette compilers public: string(void) {size=maxlen=0;ch=0;};
...................................................................
#"passed completely different pointer" #What do you mean by that?
When I debugged a code and I let Keil to show &c inside watching and I saw some address. When I have seen contents of "p" it was different address.
The "c" was not changed after returning, so it means that some different memory area has been rewritten.
I am using Keil from 4.10 and I have not observed this issue until 4.13.
Unfortunately, without any specific details, your accusation is just about worthless!
"mis-compiled pointer to variable to a different location"
What do you mean by that: was the pointer itself placed in a "wrong location", or did the pointer's value point to a "wrong location"?
"passed completely different pointer"
What do you mean by that?
"any analysis would take me lot of time"
Yes, of course - but without that proper analysis, it's just speculation...
View all questions in Keil forum