Page 5 of 5

Re: ctxp corrupted in _port_irq_epilogue

Posted: Sat Aug 30, 2014 6:57 am
by Giovanni
Hi,

Can you submit a patch? or just post on the forum the modified code. I need to modify the test application to trigger the problem also.

Giovanni

Re: ctxp corrupted in _port_irq_epilogue

Posted: Tue Sep 02, 2014 3:21 pm
by jbrandmeyer_bwp
Change to the context switching code:

Code: Select all

Index: chcore_v7m.c
===================================================================
--- chcore_v7m.c   (revision 670)
+++ chcore_v7m.c   (working copy)
@@ -166,6 +166,7 @@
        populate it fully.*/
     ctxp--;
     ctxp->xpsr = (regarm_t)0x01000000;
+    ctxp->fpscr = (regarm_t)SCB_FPDSCR;
     asm volatile ("msr     PSP, %0" : : "r" (ctxp) : "memory");
 
     /* The exit sequence is different depending on if a preemption is
@@ -249,6 +250,8 @@
 void _port_thread_start(void) {
 
   chSysUnlock();
+  // TODO: LTO doesn't understand that this code invokes chThdExit().
+  // chThdExit() needs to be marked "used"
   asm volatile ("mov     r0, r5                                 \n\t"
                 "blx     r4                                     \n\t"
                 "bl      chThdExit");


A snippet that enables FPU faults:

Code: Select all

#include <ch.h>
#include <hal.h>
#include <stm32f4xx.h>

static void __attribute__((constructor))
configure_fpu_exceptions(void)
{
   // Enable the FPU_IRQHandler
   nvicEnableVector(FPU_IRQn, 1);
}

CH_IRQ_HANDLER(FPU_IRQHandler)
{
   // Force a hard reset on FPU exceptions
    NVIC_SystemReset();
}

Re: ctxp corrupted in _port_irq_epilogue

Posted: Tue Sep 02, 2014 3:45 pm
by Giovanni
Hi,

Thanks for the patch, the LTO issue has been addressed in 3.0, the whole thing has been moved in a plain assembler module.

Giovanni

Re: ctxp corrupted in _port_irq_epilogue

Posted: Sat Sep 13, 2014 9:19 am
by Giovanni
Hi,

I committed the changes in both 2.6.x and 3.0.0, the test application has been updated as well and is able to detect the problem. 2.6.6 will probably be released next week.

Marked as bug #533.

Thank you for the patch and analysis of the problem.

Giovanni