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 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.
There is no need to protect malloc with SWI because it is already thread-safe.
Some additional lock mechanisms were introduced in RL-ARM 4.0 (to remove interrupt blocking problem in rare situations as described in the release notes). This currently prevents execution of malloc from SWI handlers.
If SWI protection of malloc is still required (for example using malloc in interrupt handlers) then contact Keil support for an updated RL-ARM.
Hi Robert,
Thanks for your insightful post. I have filed a support request yesterday and will need an updated RL-ARM.
I have read carefully through the release notes and have seen mentions of fixing the interrupt blocking problem. However, nothing indicates that mallocs can no longer be called within a SWI.
We have been burned by Keil library functions that claim to be reentrant-safe in the past--so we feel that we need to protect certain functions--especially since they do not provide the source code for library functions. It is frustrating that Keil would make not disclose a potential incompatibility in their release notes. I am sure this was simply an oversight, but still frustrating.
-Eric
please send your support request to: support.intl@keil.com
Hi Franc,
I just sent it to the mentioned address. Any idea when they will get a chance to look at this?
Thank you, Eric
Wow--this is great. They have already gotten me a fix, and things are working flawlessly so far.
Thank you!