I just upgraded from version 3.80 RL-ARM, RVMDK to version 4.0 and all of the sudden some of my software interrupt functions have stopped working.
My problem seems to be an issue with a SWI function that has a return value. [NOTE: I had no issues with this in 3.80]. What ends up happening is that the stack pointer gets corrupted and SWI_Handler( ) is not able to properly restore the CPSR
This is my swi function:
unsigned int __swi(0x08) pmalloc (int size) ; unsigned int __SWI_8 (int size) { NUMpmalloc++; return ((unsigned int)malloc(size)); // Protected malloc }
Here's where the problem occurs in SWI_Handler( )
{ . . . L250: MOV LR,PC ; Return Address L251: BX R12 ; Call SWI Function L252: LDMFD SP!,{R8,PC}^ ; Restore R8 and Return }
L251 is where the SWI function gets called. The problem is that the stack pointer value at L251 does not equal the stack pointer value at L252, so when the function attempts to return back to my code things don't work properly. This version 4 SWI_Handler( ) function is the same as the SWI_Handler ( ) function from version 3.8
Any thoughts you might have would be greatly appreciated!
Thanks, Eric
UPDATE:
The problem seems to be that I am calling malloc from a software interrupt, (rather than having anything to do with returning a value).
My supervisor stack is set to 0x400 -- plenty large. I am at a loss for how this is happening. Shouldn't calling a malloc from a supervisor context work fine? Keil must have changed something in their library......
UPDATE 2:
I have been able to reproduce this problem in the RTX_Blinky example project for the MCB2400 board: dl.getdropbox.com/.../RTX_Blinky_MallocProb.zip
To create the problem I made the following changes: -> Switched to the standard library (instead of MicroLIB) -> Added my SWI_Table.s file ->In Blinky.c: --->Created unsigned int __swi(0x08) pmalloc (int size) at the top of the file --->Inserted a function call to pmalloc in the init task (line 173)
If you set a break point on the line after the pmalloc call (line 174), you will see that the ARM is still in supervisor mode, using the supervisor stack.
I have noticed the following details about this problem: ->Calling pmalloc in the main() function before starting the RTOS does not cause this problem ->If the MicroLIB library is used instead of the standard library, this problem goes away. (Unfortunately, our application requires the standard library)
Eric,
This sounds pretty serious to me. Have you reported this to Keil technical support? They will most definitely be interested in your test program. I, for one, am not going to install 4.0 until this issue is clarified.
View all questions in Keil forum