Responding in new thread since other thread is dead. http://www.keil.com/forum/21199
So, anyone else with this problem? It seems to be a general Keil issue...
Anyone else with what problem? Forgetting to use the correct keyword to tag an ISR as an ISR?
What general Keil issue? That the compiler needs to adapt to the hardware?
Lots of compilers for lots of processors have needed a special keyword to let the compiler know when it should generate prologue/epilogue for an ISR instead of for a normal function.
A number of processors have a normal "RET" instruction and a special "RETI" instruction. Or need to name specific registers to reload PC with the correct return address depending on if the processor did use the normal stack or an interrupt stack.
And an ISR often need to save extra registers compared to a normal function, since the interrupt can happen asynchronously - breaking in in the middle of other code execution.
So if you Google and finds lots of mentions of Keil, it is just because Keil works with compilers for embedded use. So the majority of users of Keil tools will create interrupt handlers.
Only OS or drive routine coders need to care about any interrupt handlers if you write code for a modern PC. So you don't see lots of threads about interrupt handlers for Visual C++.
Of course - a processor can be implemented in a way where an ISR do not need any special prologue or epilogue. In that case, there will be no need for any extra keyword to tag the ISR as different from a normal function. ARM did add extra logic in the Cortex chips to allow 100% of the code to be written in C, and without any special keyword for ISR. But that is an exception to the rule that interrupt service routines are different from normal functions.
Thanks for your elaborate.
Yes, I saw all that in the startup code(s) sources, but when I started RT debugging my project, there was something completely different on the debugger screen. It was clear that it's not linking all the code there is, but I couldn't imagine why. I was also having random configuration issues with the Keil Wizard (probably also due to the compiler was "finding" another startup code on some other location because of inproper path setup)... So I jumped on the problem "from the top" - why should I bother with assembler when the FW is provided....even a generic ISR is sourcef... and that part basically started working, except that the IRQ handling was still inproper until I managed to make it compile the correct startup and IRQ handlers.
Don'know about other products (moving on to some NXP ARM7 MCB too these days), but about Keil - some hint to "mind the include paths!" would help a newbie Keil design kit user.
"but about Keil - some hint to "mind the include paths!" would help a newbie Keil design kit user."
Yes of course. But if you do try Google, you will find that this world is full of developers who have run full-speed into the wall because the compiler or linker have picked up the wrong version of files. And that it happens with almost any compiler and for almost any build platform or target platform.
I bet almost all visitors on this forum have once or twice been burned by similar issues. With Keil or with other tools. So the only really good solution would probably that every GUI in existence should regularly pop up such a warning - and repeat it until the developer answers "Yes: have been burned. Now will do my outmost to not suffer this one again". And even then, the GUI would need to maybe once/year bring back that warning again :D