On 8/27/2015 3:58 PM, Daniel Gutson wrote:
On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
<sudarshan.rajagopa...@vecna.com> wrote:
Hey guys,

I was working on the exception handler for the CPU hard fault. Managed to
register the fatal error user extension to RTEMS and call the user defined
function when an exception occurs. But the pointer to the stacked frame
didn't have the correct register values(esp. the PC register). So I looked
into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c,
where it decides which stack pointer was used (MSP or PSP) before the
exception occurred depending on the error code returned in the Link
Register. After carefully examining all the assembly instructions, I guess
theres a little bug in the code.

The instruction "cmn r2, #3\n" in line 31 basically compares the Link
Register(lr) to value 0xFFFFFFFD (negative #3, because CMN negates the RHS
and compares with LHS) and chooses MSP or PSP in the following IT block.
This is pretty cool! But, it will not work if you have the floating-point
unit (FPU) enabled in your processor, which is enabled in mine. With FPU
enabled, the error code returned is either 0xFFFFFFE9 or 0xFFFFFFED, for
which the above assembly instruction will not work out and MSP will be
selected always.

Better way to do is to check the 2nd bit of the error code to determine
which stack pointer was used before the exception happened - "tst lr, #4\n"
and change the IT block from "itt ne" to "itt eq" and the "mov" and "add"
within this IT block.

Have tested this with the above changes and it works. I have sent the patch
"0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel mailing
list that fixes this problem. :)

Nice. Have you tested this without FPU support too?

Daniel .. when you are happy, we can push it.

Should this go on the 4.11 branch and master? If so, it needs a ticket.

Thanks and Regards,
Sudarshan
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel




--
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherr...@oarcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to