I have a general question about the MSP430 GCC port. The ISRs calls the taskYIELD() macro when there is a need for a context switch. Eventually in the macro, portRESTORE_CONTEXT() is called which provides the neccessary assembly instructions to restore the context for the next task. However, from what I can tell, it fails to clean up the stack as modified by the entrance into the ISR. For the Tick ISR this seems to be acceptable because the ISR is given a “naked” atrribute, and hence, I assume the gcc compiler does not modify the stack upon entry to this function. However, the serial ISRs are not declared as “naked”, so won’t this cause a memory leak (as the stack manipulation peformed by the compiler entering this ISR is not cleaned up)?
I am actually not using gcc but the CCE Pro version offered by TI so I can’t look at the assembly that gcc creates upon an non-naked ISR entry. I believe I have everything ported except for this ISR issue.
For those who are interested, some simple things I have done to port gcc to CCE:
1. Use the #pragma FUNC_NEVER_RETURNS() to make an ISR "naked"
2. Put a space between the " and the first assembly mneumonic of each asm() instruction
3. Use mov.w R1,0(R12) in place of mov.w R1,@R12
4. Define inline as nothing "#define inline" (taken from Westmoreland port)
5. removed "volatile" keyword from all asm() instructions
6. Added "asm(" .global pxCurrentTCB");" underneath pxCurrentTCB declaration as the compiler was not adding this because there was not statement in C (other than some asm() statements) that used this variable.
7. Added TIMERA0_ISR(prvTickISR); for Tick ISR
8. Added an "#include "portmacro.h"" to portable.h - a better fix would be to create a symbol for the CCE build and place this include inside of an #ifdef
9. I have not yet found that I needed any special compiler or linker settings - the default has worked thus far.