RTX kernel app doesn't work with relocated entry point

I've got a program using the RTX Kernel that needs to use address 0x20000 as its entry point (a reprogramming application starts at address 0).

I've relocated the exception/interrupt vectors and have a working version of a simple RTX application. The problem is with the real application. The program has eight tasks and it works just fine when I was running it without a relocated entry point, but after relocation it fails... after starting the eighth task. I can start seven of the eight tasks in any order and it works just fine, but if I start the eighth task, the task switching SWI always jumps to the same bad address and then the Reset_Handler is called.

I have no idea why it won't work. I've compared the memory maps for the two versions and everything in RAM is the same. I looked at the stacks for all the tasks and they all have the MAGIC_NUMBER used to detect overflows.

I was using a customized startup file, but I've replaced it with the default for the LPC2468 and I manually place the PC at 0x20000. The same problem occurs.

Here is the scatter-loading file I'm using:

LR_IROM1 0x00020000 0x00060000
{
        ER_IROM1 0x00020000 0x00060000
        {
                *.o (RESET, +First)
                *.o (BOOT)
                *(InRoot$$Sections)
                .ANY (+RO)
        }

        RW_IRAM2 0x7FD00000 0x00004000
        {
                .ANY (HCD_DMA)
        }

        RW_IRAM1 0x40000040 0x0000FFC0  {  ; RW data
                .ANY (+RW +ZI)
        }
}

RESET consists of nothing more than a jump command to the Reset_Handler. BOOT contains the rest of the startup file. I had to do this b/c the compiler would otherwise place __main (not to be confused with main) at address 0x00020000.

In the end, though, two of the eight tasks are used for debugging purposes and if I disable them, the application works just fine. However, I'm inclined to believe that I'm doing something wrong and that the code just happens to work right now. I'm not going to says the program is "working" until I understand what's going on.

I've been stepping through disassembly for three days now and I'm getting nowhere, so if anyone can give me any insight on what's happening, I'd greatly appreciate it.

Thanks,

Jon