tags:

views:

257

answers:

1

Hi, I wrote an an idle hook shown here

void vApplicationIdleHook( void )
{
    asm("nop");
    P1OUT &= ~0x01;//go to sleep lights off!
    LPM3;// LPM Mode -  remove to make debug a little easier...
    asm("nop");
}

That should cause the LED to turn off, and MSP430 to go to sleep when there is nothing to do. I turn the LED on during some tasks.

I also made sure to modify the sleep mode bit in the SR upon exit of any interrupt that could possibly wake the MCU (with the exception of the scheduler tick isr in portext.s43. The macro in iar is

__bic_SR_register_on_exit(LPM3_bits);   // Exit Interrupt as active CPU

However, it seems as though putting the MCU to sleep causes some irregular behavior. The led stays on always, although when i scope it, it will turn off for a couple instructions cycles when ever i wake the mcu via one of the interrupts (UART), and then turn back on. If I comment out the LPM3 instruction, things go as planned. The led stays off for most of the time and only comes on when a task is running.

I am using a MSP4f305438

Any ideas?

A: 

Perhaps the problem is the call __bic_SR_register_on_exit(LPM3_bits). This macro changes the LPM bits in the stacked SR, so it must know where to find the saved SR on the stack. I believe that __bic_SR_register_on_exit() is designed for the standard interrupt stack frame generated by the compiler when you use the __interrupt directive. However, a preemptive RTOS, like FreeRTOS, uses its own stack frame typically bigger than the stack frame generated by the compiler, because an RTOS must store the complete context. In this case __bic_SR_register_on_exit() called from an ISR might not find the SR on the stack. Worse, it probably corrupts some other saved register value on the stack.

For a preemptive kernel I would not call __bic_SR_register_on_exit() from the ISRs. The consequence is that the idle callback is called only once and never again, because every time the RTOS performs a context switch back to the idle task the side effect is restoring the SR with the LPM bits turned on. This causes a sleep mode (which is what you want), but your LED won't get toggled.

Miro Samek state-machine.com

Miro
I was slowly coming to that conclusion as well!My current solution is to accept that reentry into the idle task means switching back to LPM3, and moving any board level power down into its own task which can be managed by other tasks with a counting semaphore. Logically MCU power down and board level power down are two different tasks anyway (not always tied together, and often i will have to change one and not the other).
michael