• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 409 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.

Unable to change P1IFR using the debugger

Fred Carter
Intellectual 515 points
Other Parts Discussed in Thread: MSP430F2618

Hello "Twilight Zone" experts,

   While debugging a "frozen processor" problem, I discovered that the neither my application nor the debugger could clear the P1IFR register. Curiously, I could clear the P1IE register.   I could breakpoint on the P1IFG &= ~BIT0, and open the registers window.  Neither single-stepping nor manually clearing P1IFG worked.  Here's the code:
----------

unsigned flags = static_cast<unsigned>(P1IFG);

if (flags & BIT0) {
  P1IFG &= ~BIT0; /* Clear Interrupt */
  if (Trigger1retriggerable == false) {
    P1IE &= ~BIT0;
  }
Event_post (MassSpec_Event, TRIGGER1_RECEIVED);
}

---------- 

Tools:

CCS  5.2.0.00069 
C++ Compiler: 4.1.0
Emulator: 5.2.0.9
RTSC/XDCtools: 3.23.3.53
BIOS6: 6.33.4.39
MSP430.dll: 3.2.1.9

Target: MSP430F2618

Any ideas?

Thanks,

Fred

  • 0
    Guru 58965 points

    It could be caused by hardware -- something is flipping P1IN up & down.

  • 0
    Guru 227245 points

    Fred Carter said:
    I discovered that the neither my application nor the debugger could clear the P1IFR register. Curiously, I could clear the P1IE register.

    P1IE is set and cleared by software only. But P1IFG is changed by hardware as well as by software. And hardware interrupt events won't stop because of a breakpoint in the debugger.

    Single stepping or manual register acces through the debugger is so slow, that anything can happen between two steps. Including another hundred interrupt events.

    As OCY already pointed out, something might continuously triggering interrupts on this port pin. An oscilaltin inpiut, or, when left open, maybe radio waves or crosstalk from other lines, including the crystal.

  • 0 in reply to Jens-Michael Gross
    Intellectual 515 points

    Hello and thanks to OCY & JMG,

       There are few things as prone to oscillate, when you least want it, as un-terminated inputs.  The software fix was to enable the internal pullups in the MSP430.  In my case:

    P1OUT |= (BIT0 | BIT1);
    P1REN |= (BIT0 | BIT1);
    P1IES |= (BIT0 | BIT1);

    Regards,

    Fred

  • 0 in reply to Fred Carter
    Guru 227245 points

    Teh low power advisor recommends setting th em to low output. Or pulldown. THis way, the pullups do not create internal current. Maybe external one, btu that doesn't count forr MSP power consumption :)

**Attention** This is a public forum