Hello,

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)
============================================
portRESTORE_CONTEXT()
...
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:
lr=0x40000a20
pxCurrentTCB->pxTopOfStack = 0x40000a18
pxCurrentTCB->pxStack = 0x400003a0




#define portRESTORE_CONTEXT()
...
/* Set the LR to the task stack. */
LDRR0, =pxCurrentTCB
LDRR0, [R0]
LDRLR, [R0]

/* The critical nesting depth is the first item on the stack. */
/* Load it into the ulCriticalNesting variable. */
LDRR0, =ulCriticalNesting
LDMFDLR!, {R1}
STRR1, [R0]

/* Get the SPSR from the stack. */
LDMFDLR!, {R0}
MSRSPSR, R0

/* Restore all system mode registers for the task. */
LDMFDLR, {R0-R14}^
NOP

/* Restore the return address. */
LDRLR, [LR, #+60]

/* And return - correcting the offset in the LR to obtain the */
/* correct address. */
SUBSPC, LR, #4
...


MCU:LPC2148
FreeRTOS: 4.7.0
GCC: 4.2.2


Source/portable/GCC/ARM7_LPC2000/portISR.c
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?

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?

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:

#ifdef THUMB_INTERWORK
{
/* We want the task to start in thumb mode. */
*pxTopOfStack |= portTHUMB_MODE_BIT;
}
#endif

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.

Regards.