I’m just starting a new project with freertos on LPC2387, Code Red tools. I’ve used their wizard to make a new shell freertos project. It builds and loads fine, but vectors to program abort         LDR   pc,_pabt                  // program abort when portRESTORE_CONTEXT() in vPortISRStartFirstTask() is called. It’s using freertos v 7.0.1

As your project was created by somebody else’s tool I can’t support it directly, but suspect your problem will be that the MCU is in the wrong mode.  Make sure the MCU is in Supervisor mode when main() is called. Regards.

Thanks for the fast reply Richard, but I’ve already tried that. main is called:-

        LDR   r3, .def__main
        CMP   r3, #0
        BEQ   .newlib_main
        LDR   r10,=__main
        B     .call_app
.newlib_main:
        LDR   r10,=main
.call_app:
        // Change to user mode (interrupts enabled) before calling main application
        //MSR   CPSR_c,#MODE_USR
        // change to Supervisor mode
        msr   CPSR_c, #MODE_SVC|I_BIT|F_BIT
        MOV   lr,pc
        BX    r10                       // enter main() - could be ARM or Thumb

So, I am over that problem, but now I have that the ticks are not being incremented. Where are the interrupts re-enabled after the disable in  vTaskStartScheduler? Is it the portRESTORE_CONTEXT in vPortISRStartFirstTask?

All the ports disable interrupts before starting the scheduler, then automatically enable them as the context of the first task to run is restored.

This is frustrating. ;) .. as always in embedded … So the code is running, and I can break in and it’s in the idle task. looks good. But the xTickCount is not incrementing. So, check the timer setup. That’s correct and the TCR is changing. VICIrqStatus is 0x10, which means that the interrupt is triggered but not serviced. cpsr is 0x6000001f, which I interpret to mean that the interrupts are enabled. So what could be wrong??

If interrupts are not disabled, then it sounds like the tick interrupt is simply not executing for some reason.  Put a break point in the vPreemptiveTick() function (portISR.c).  If it never gets hit, but other interrupts are executing, then check the function vPreemptiveTick() (port.c) is correct for your derivative of the chip. Regards.

It’s all working now. The interrupt issue turned out to be a problem with the Red Probe debug pod.