portRESTORE_CONTEXT crashes on LPC2148 in Thu

paul20 wrote on Monday, January 14, 2008:


I’ve been working with FreeRTOS in ARM mode successfully for a while
but Thumb mode always crahes when portRESTORE_CONTEXT() is called
in vPortISRStartFirstTask() to start the scheduler:

Disassembly (portISR.c compiled in ARM mode)


ldr   r0, [pc, #684]    ; 0x780
ldr   r0, [r0]
ldr   lr, [r0]
ldr   r0, [pc, #676]    ; 0x784
ldm   lr!, {r1}
str   r1, [r0]
ldm   lr!, {r0}
msr   SPSR_fc, r0

// it crashed on the next line with "data abort exception"
ldm   lr, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr}^

nop   (mov r0,r0)
ldr   lr, [lr, #60]
subs  pc, lr, #4    ; 0x4

At the point of the crash:
pxCurrentTCB->pxTopOfStack = 0x40000a18
pxCurrentTCB->pxStack        = 0x400003a0

#define portRESTORE_CONTEXT()

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

MCU:        LPC2148
FreeRTOS:     4.7.0
GCC:         4.2.2

arm-elf-gcc -c -mtune=arm7tdmi-s -mthumb-interwork -I. -gstabs -DRUN_FROM_ROM  -DGCC_ARM7
-DYES -D__WinARM__ -DTHUMB_INTERWORK -O0 -Wall -Wextra -Wimplicit -Wpointer-arith -Wswitch
-Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wbad-function-cast -Wsign-compare
-Waggregate-return -fno-strict-aliasing -Wa,-adhlns=Source/portable/GCC/ARM7_LPC2000/portISR.lst
-ISource/include -ISource/portable/GCC/ARM7_LPC2000 -MD -MP -MF .dep/portISR.o.d -std=gnu99

Any ideas?

davedoors wrote on Monday, January 14, 2008:

I cannot see anything wrong. It is odd as I normally run in THUMB mode myself.

I think lr=0x40000a20 is a valid address.

Your compiler options look fine. Small comments would be I use -mcpu=arm7tdmi but I don’t think this is the problem as you have the -mtune option, and this does not look like a code generation problem anyway.

I have never used winarm, but this is assembly code so I don’t see how the compiler could make any difference.

What does the -DYes do?

Are you using the same linker script for ARM and THUMB compilation?

Does this problem just happen when using the debugger or all the time?

rtel wrote on Monday, January 14, 2008:

This is curious, there is nothing on that line to cause offence, provided your processor is in Supervisor mode.  I recall somebody else mentioning this a while back, unless that was you?

In port.c, there is the following code:

        /* We want the task to start in thumb mode. */
        *pxTopOfStack |= portTHUMB_MODE_BIT;

Can you check that this definately gets included in the build by placing a break point on the *pxTopOfStack line.

I’ve just tried on an LPC2138 and have the following status when the line “ldmia lr, {r0-lr}^” is executed:

lr = 0x40004380
pxCurrentTCB->pxTopOfStack = 0x40004378
pxCurrentTCB->pxStack = 0x400041c0

Are you using both the same startup file and the same linker script when switching between ARM and Thumb modes?

What is the value of the CPSR immediately before the execution of the line that crashes?  Mine is 0x000000d3.