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.
"Thank you for a (finally) answer that makes sence"
The goal was for you to wonder about how/were the processor would save the required state before starting to run your functions.
Basically the difference between having the startup file look like:
LDR PC, [PC, #-0x0FF0]
where the processor directly picks up the vector address from the VIC and jump to the correct ISR (but requiring the ISR to be compiled with the __irq keyword so it has the proper prologue/epilogue). Or being written in assembler with explicit prologue/epilogue.
Or a startup file looking like:
LDR PC, IRQ_Addr EXTERN IRQHandler IRQ_Addr DCD IRQHandler
And where there then exists a special function IRQHandler that does something like:
IRQHandler SUB LR, LR, #4 ; Update Link Register STMFD SP!, {R0-R12, LR} ; Save Workspace & LR to Stack LDR R0, =VectorAddr LDR R0, [R0] ; Read the Routine Address BLX R0 ; Branch to the IRQ Handler LDMFD SP!, {R0-R12, PC}^ ; Restore Workspace & PC from Stack
I.e. a common function that performs the same magic that __irq would have done, but shared betweeen all ISR to save space. But instead costing a bit of extra time compared to the first solution where each ISR have their own interrupt-specific prologue/epilogue. Both because of the extra jump and that too many registers are sometimes saved.
In the end, we have lot to gain by actually digging down and trying to understand the inner workings.
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