• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 296 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2355: Interrupt Enables getting turned off after a hard power on??

Steve Wenner
Genius 3240 points
Part Number: MSP430FR2355


Good afternoon.....

I have code where I initialize P1 interrupts with 0xF8.  Code is working as expected.  If I power down the unit and re-power however I notice after I place the debugger on the unit (symbols) that the P1 interrupts = 0x80.  I have no where in code where I set all interrupts as such.  My ISR is very clean...

#pragma vector=PORT1_VECTOR
__interrupt void P1_Sw(void)
{
    p1flags = (P1IFG & 0xF8);
    switch (__even_in_range(P1IV, 16))
    {
        case 8: //R - Switch 2
            P1IE &= ~BIT3;
            break;
        case 10: //R - Switch 4
            P1IE &= ~BIT4;
            break;
        case 12: //R - Switch 1
            P1IE &= ~BIT5;
            break;
        case 14: //R - Switch 3
            P1IE &= ~BIT6;
            break;
        case 16: //R - Switch All
            P1IE &= ~BIT7;
            break;
        default:
            break;
    }
    debounce();
}

I have other IRQs on other ports and verified that debounce is working .  This is the only place I disable each IRQ and it is supposed to happen ONLY after a button push.  Can someone point me in a direction to look with respect to what is happening?  I have found that with the debugger connected I can write 0xF8 to the PI1E (just as the configuration does) and I am up and running with code working properly.  I also have a reset button on the unit P2.4 and if I hit that I reboot and code works as expected.

Thank you

  • 0
    Guru 100785 points

    Are you using the initialization sequence for the IEs described in UG (SLAU445I) Sec 8.3.1?

    My observation is that if you don't it sometimes sorta-kinda works anyway, so you don't always notice immediately that it isn't right. Also, a debugger reset is much lighter than a POR.

  • 0 in reply to Bruce McKenney
    Genius 3240 points

    Yes I am.....

    I am having a terrible time trying to track it down.  I've wired the debugger to be powered from the board and after I flip the power on switch I am connecting the debugger via loading symbols only and I'm seeing 'sometimes' incorrect fields both registers and variables.  I just can't seem to track it down.  The variables are based from reading PxIN values which in turn are hard-wired to DIP switches....These variables along with ISR flags determine the conditions in main.  I find that reading PxIN (this happens at the front end during initialization) isn't always consistent (based on me powering up the board, then connecting the debugger via symbols and after connection I stop the debugger to see the state of registers/variables.

    I am running at 16MHz and thought about slowing down but I wonder if powering up things happen to quickly for PxIN to be stable???  sounds pretty silly and I am grasping at straws here.

  • 0 in reply to Steve Wenner
    Guru 100785 points

    If you're wondering about the pins wiggling at startup, try jamming something like "__delay_cycles(10000);" right at the beginning. (If that has an effect, you can refine it later.)

    If any of those pins is unconnected, apply the REN resistors before the enable sequence.

    Are you setting NWAITS=1?

  • 0 in reply to Bruce McKenney
    Genius 3240 points

    The boot sequence prior to those pins getting read is a good 200ms (I have an LED indicator after boot and the last thing I do is read the pins).

    I already have REN on all the signals and NWAITS is 1

**Attention** This is a public forum