Kernel aborting during startup code, STR730

johughes2002 wrote on Monday, July 28, 2008:

I’m having some issues getting the kernel running on my STR730 board. I started with the STR75x GCC port and demo, modified for the differences in periferal api to provide the tick interrupt, and have everything compiled and flashed to the board. The problem I’m having is on when starting the scheduler. I’ve stepped through the code, and invariably I get an abort exception in vPortISRStartFirstTask() which from the STR75x port contains some inline ASM which I think sets the MCU registers up for starting the first task:

<pre>
void vPortISRStartFirstTask( void )
{
    /* Simply start the scheduler.  This is included here as it can only be
    called from ARM mode. */
    asm volatile (
    "LDR        R0, =pxCurrentTCB       \n\t"   
    "LDR        R0, [R0]                \n\t"   
    "LDR        LR, [R0] \n\t"            \

    /* The critical nesting depth is the first item on the stack. */   
        /* Load it into the ulCriticalNesting variable. */           
    "LDR        R0, =ulCriticalNesting    \n\t"   
        "LDMFD    LR!, {R1}            \n\t"   
    "STR        R1, [R0]        \n\t"   
                           
    /* Get the SPSR from the stack. */       
    "LDMFD    LR!, {R0}            \n\t"   
    "MSR        SPSR, R0        \n\t"   
                           
    /* Restore all system mode registers for the task. */           
    "LDMFD    LR, {R0-R14}^            \n\t"   
        "NOP                    \n\t"  
                                                       
    /* Restore the return address. */       
    "LDR        LR, [LR, #+60]        \n\t"   
                               
    /* And return - correcting the offset in the LR to obtain the */
    /* correct address.                        
    "SUBS PC, LR, #4            \n\t"   
    );
}
</pre>

The MCU aborts after the last line, which sets the PC to somewhere whack out of range.
I dumped the registers after it loads them from the stack. These look like the values set on the stack in pxPortInitialiseStack(). It looks like something isn’t right with LR. Am I right in thinking it’s somehow loaded LR with data in the wrong position on the stack, or should it look like that?

<pre>
r0             0x0      0
r1             0x1010101        16843009
r2             0x2020202        33686018
r3             0x3030303        50529027
r4             0x4040404        67372036
r5             0x5050505        84215045
r6             0x6060606        101058054
r7             0x7070707        117901063
r8             0x8080808        134744072
r9             0x9090909        151587081
r10            0x10101010       269488144
r11            0x11111111       286331153
r12            0x12121212       303174162
sp             0xa00002d0       0xa00002d0
lr             0xaaaaaaaa       2863311530
pc             0x80000f28       0x80000f28 <vPortISRStartFirstTask+40>
fps            0x0      0
cpsr           0x400000df       1073742047
</pre>

Any hints would be appreciated. I’ve been tearing my hair out for the past few days on this.

Thanks

rtel wrote on Monday, July 28, 2008:

It is (very) highly likely that you have not put the processor into Supervisor mode before starting the scheduler.  The easiest thing to set the processor into Supervisor mode prior to calling main() from the crt0 file.

Regards.