LPC23xx

Kernel
1

oxo147 wrote on Monday, November 19, 2012:

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

2

rtel wrote on Monday, November 19, 2012:

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.

3

oxo147 wrote on Monday, November 19, 2012:

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
4

oxo147 wrote on Wednesday, November 21, 2012:

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?

5

davedoors wrote on Wednesday, November 21, 2012:

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

6

oxo147 wrote on Wednesday, November 21, 2012:

This is frustrating. :wink: … 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??

7

rtel wrote on Wednesday, November 21, 2012:

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.

8

oxo147 wrote on Friday, November 23, 2012:

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