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.

MSP430FR2111: P2.0 Interrupt dependent on state of eComp Output

Part Number: MSP430FR2111

Running in LPM3. Have 2 ISRs enabled. One ISR is for the RTC. In this routine I update a time keeping register and check the state of the eComp output (internal). If it is high I clear a flag. If it is low I set a flag. It sees a normal RTI. The second ISR is for P2.0 which is set for high to low transition interrupt. I find when the eComp output is high the P2.0 interrupt does not occur. If the eComp output is low the P2.0 interrupt works just fine.

Are there any known issues with P2.0 pin interrupt when eComp is on and the output is high?

ConnectP1   mov.b   #001h,&P1SEL0           ; Connect TimerB to P1.6 Comp P1.0**
                     mov.b   #041h,&P1SEL1           ; Connect TimerB to P1.6 Comp P1.0**
ConnectP2   mov.b   #000h,&P2SEL0           ; Connect Oscillator to P2.6,7    **
                     mov.b   #0C0h,&P2SEL1           ; Connect Oscillator to P2.6,7    **
SetupP1       bis.b   #0FEh,&P1DIR                ; P1.1 - P1.7Output, P1.0 Input   **
SetupP2       bis.b   #0FEh,&P2DIR                ; P2.1- P2.7 Output, P2.0 Input   **
Part of RTC ISR that is affected
                mov.w   &RTCIV,R15
           
                bit.w      #CPOUT,&CPCTL1        ; Is Comparator Output Set?
                jc          BatGood               ; Yes
                bis.w     #LVTActive,flagreg    ; No
                bis.w     #CPDACSW, &CPDACCTL   ; Turn On DAC Output 2
                jmp       Chk24
BatGood     bic.w   #LVTActive,flagreg   
                bic.w   #CPDACSW, &CPDACCTL   ; Turn On DAC Output 1
Chk24       bit.w   #mode24,flagreg
                jnc     RTCDone
  • Hi David,

    Not that I am aware of, according the the most recent errata document.

    You indicate for your second ISR for P2.0 you have it set go generate an interrupt when transitioning from high to low.  You describe that when the eComp output is high, no interrupt occurs and when eComp goes low, the interrupt works fine.  Based on the "high to low" transition you have setup for P2.0, it's working as expected, unless I misunderstood something.

    Are you intending to capture interrupt when transitioning from either state, in which case the eComp (see section 18.3) can generate an interrupt to do that.

  • Dennis,
     Maybe I need to strip it down to the basic issue I described and test it and see if the problem persists. But on the off chance I say something that rings a bell, here is what is going on:
    I have an RTC interrupt, it updates a 24 hour timer and checks if it is 0 if 24 hour flag is set. This occurs every 5 seconds. My problem came up after adding a comparator check of the battery voltage via P1.0 as + input and DAC as - input. I previously did this comparator check in another ISR (timerb ISR) where I turned on the comparator made the check and turned off the comparator.
    I have a P2.0 input tied to a switch with an external pullup and it has a high to low transition interrupt routine. This routine simply clears the Interrupt flag and then clears the LPM3 bit settings before returning.
    I have a timerb setup as a PWM and I use its 10mS period as an interrupt which drives the main operation of things.
    Most of the time the unit is asleep in LPM3, it wakes up for the RTC interrupt and when the switch is pressed that interrupt switches to LPM1/AM while the unit is running. It then returns to LPM3.
    If ran the debugger through the RTC routine with the comparator high and low on its output. It goes back to sleep immediately afterwards. If the comparator was high the switch interrupt would never occur. It always occurred when the comparator was low.
    I tried to turn on the comparator and leave it on and only read its output during the RTC routine.
    David Martin
  • Hi David,

    Thanks for the detailed information.  Let me dig into this a bit deeper.  I'm going to set up same on my side to test.

  • Hi David,

    I think I may have discovered the issue.  According to the users guide:

    If I read this correctly, as long as you select the COUT function on P2.0 (P2SEL1=1, P2SEL0=0) then you won't see interrupts on P2.0 caused by your switch. In your code somewhere do you switch the functionality of P2.0 between GPIO and COUT?

  • Dennis,

    [1] I do NOT have COut tied to P2.0. P2.0 is a digital input pin. I sent you the code snippet that set the select registers. Here it is again:

    ConnectP1   mov.b   #001h,&P1SEL0           ; Connect TimerB to P1.6 Comp P1.0**
                mov.b   #041h,&P1SEL1           ; Connect TimerB to P1.6 Comp P1.0**
    ConnectP2   mov.b   #000h,&P2SEL0           ; Connect Oscillator to P2.6,7    **
                mov.b   #0C0h,&P2SEL1           ; Connect Oscillator to P2.6,7    **
    SetupP1     bis.b   #0FEh,&P1DIR            ; P1.1 - P1.7Output, P1.0 Input   **
    SetupP2     bis.b   #0FEh,&P2DIR            ; P2.1- P2.7 Output, P2.0 Input   **
    As you can see P2.0 is a digital input. P2SEL =00
    I will strip this code down to simplify it to just this issue today. I went through and rechecked things via debug mode yesterday and saw the same thing. I sent you the pertinent section of the RTC interrupt routine previously that showed the battery test and the good/bad paths. The P2.0 interrupt works when the comparator is low and it doesn't work when it is high. Likewise, If I turn off CPEN the interrupt works because the output is low. I appreciate your support on this issue. Hopefully, I/We can get to the bottom of the issue today.
    Thank You
  • Here's a shot in the dark: Try setting SYSCFG2:TB0TRGSEL=1 [Ref data sheet (SLASE78C) Table 6-13]. You don't seem to be using P1.2, and I think since P1SEL.2=00b this effectively disables TBOUTH, and more generally will keep CPOUT far away from any of those pins. (I personally find the descriptions of the CPOUT routing a bit murky.)

    If nothing else, this will keep your PWM on P1.6 from stopping.

    I have no particular reason to suppose this will fix your symptom, but it should be (?) a quick experiment.

  • Bruce,

    Thank You very much. It may have been a shot in the dark but I think you hit the target. I need to do some more testing but it looks like it may have resolved the problem. I doubt that I would have found (stumbled across) this.

    David Martin

  • Now all we need is a hypothesis (:-)).

    I'm glad you got it working.

  • Thank you Bruce for saving the day.

    This is most certainly a case where the documentation is totally vague or missing.

    I will work with the product team to get the documentation revised to make it much more clear.

    David - unless you had any other issue, it sounds like you are good to go.

**Attention** This is a public forum