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.

MSP430FR5738: P2.2 False interrupt detection

Part Number: MSP430FR5738

Hello, 

we used the MSP430FR5738 uC for a project in volume production. Now we received few pieces back from customers complaining about a false functionality. After debugging in the lab we have found the root of the problem. 

We use ISR on P2.2 for falling edge detection. Pin Initialization is listed below.

Well when we scope the line, the voltage remains on 3.3V and there is no real ongoing action on the input of the P2.2 (trigger level on scope is ~2V). While this the uC jumps all the time into ISR. This happens I would say on 1 of 1500 devices. We could think it may be an ESD damage, but this line is used just internal ans has no connection to some external pins. Do you have an idea?  

Best Regards

//main.c
P2DIR = 0x00;
P2OUT = 0x00;

void init_p22(void) {
    P2IFG &= ~BIT2;    
    P2OUT |= BIT2;
    P2IES  |= BIT2;		
    P2REN |= BIT2;      
    P2IE   |= BIT2;	
}

#pragma vector=PORT2_VECTOR
__interrupt void P2_ISR(void)
{
	if(P2IFG && BIT2)  //  P2.2  Interrupt?
	{
         // some action here
	}
	P2IFG = 0x00;    // delete all IR flags
}


  • > if(P2IFG && BIT2) // P2.2 Interrupt?
    This is checking all the bits in P2IFG. Unrelated activity might be setting some of the other bits. Try:
    > if(P2IFG & BIT2) // P2.2 Interrupt?
    --------------------------------------
    Unsolicited:
    > P2IFG &= ~BIT2;
    > P2OUT |= BIT2;
    > P2IES |= BIT2;
    > P2REN |= BIT2;
    > P2IE |= BIT2;
    This clears P2IFG too early. Any/all of the subsequent manipulations could cause P2IFG.2 to be set, resulting in a (single) false trigger. Move the IFG clearing to just before the IE setting:
    [...]
    > P2IFG &= ~BIT2; // Clear stale
    > P2IE |= BIT2;
  • Just an additional info. All devices we received back passed our final test (which takes ~ 30 minutes) successfully. The problem appeared first on the customer site.
  • Hi Bruce sorry about double && happened my while typing here. Furthermore there a no other IO interrupts initialized on port2.
  • Bruce's suggestions are correct. Especially manipulations on the interrupt edge select register bits are critical and can result in setting the interrupt flag. Thus the interrupt flag clearing should happen as last instruction before enabling the respective interrupt.

    Best regards
    Peter
  • Thank you and Bruce for this suggestion, but it will not solve the problem that the interrupt appears all the time. Maybe it appears once on edge selection than cleared in the isr itselft, but just in the initialization phase which is not a critical situation in my case.
  • Hello Artur,
    so if I understand you right, the P2.2 is not connected to anything outside of the MSP430, and still, though with a scope probe you do not see any triggers, the interrupt occurs.
    Could you please apply the following tests:
    1. Switch the pull-up to pull-down instead and see if you see still interrupts occurring.
    2. Switch the device instead to Pull-Up and input to Output e.g. low and see whether the interrupt still occurs.

    Best regards
    Peter
  • Sorry, you are correct. The test only matters if the interrupt is triggered in the first place.

    Is the pin connected to anything at all? The internal pullups aren't very strong (20K?).

    What else is the program doing?
  • Hi Peter,

    the P2.2 is connected to an other IC within the product and has no connection to some external PIN, so it's not possible to customer to apply wrong voltage or electrostatic discharge to this pin. The other IC is supplied by the same voltage (3V3). This wire has an external 10k pull-up.

    Tried to switch to internal pull-down = the same situation.
    Tried to configure Interrupt for this PIN on falling edge, but set the pin to OUTPUT = the same situation.

    uC is still going into ISR several times in a second. 

  • Hi Artur,
    thank you very much for the additional information.
    Just to make sure my understanding is correct. The repeated interrupts, do they occur with a certain, maybe varying occurrence rate, or is the device permanently looping through the P2_ISR? The reason why I am asking is, if the interrupt flag could, for what ever reason not be reset, then the device would immediately after finishing one execution of the P2_ISR jump again into the same after RETI. If it takes some time, until the device jumps into P2_ISR, and executes code in-between, this would mean the interrupt flag was at least for a certain period cleared, before it gets set again.

    The other thing I would like to ask you to do, is to program the device with LPM3/or LPM4 mode only, configuring of course the GPIOs in a way avoiding cross currents, means avoiding floating nodes, and then measure the MSP430 current consumption, to verify, whether the device still operates according to the datasheet values. If the current should be exceeding the datasheet values, this would be an indication, that the affected device is damaged.

    In your initial post you have mentioned an occurrence rate of the behavior of 1 : 1500. This indicates you have multiple devices with the same behavior. Do all of them behave the same, and how many do you have identified?

    Many thanks in advance.

    Best regards
    Peter
  • Hi Peter,

    I don't know the rate of the interrupt, but I'm able to communicate with the device via I2C interface, so I thing they are some time slots between interrupts. I've used a byte variable which is incremented by each interrupt

    #pragma vector=PORT2_VECTOR
    __interrupt void P2_ISR(void)
    {
    if(P2IFG & BIT2) //
    {
    Mem.reg.reserved19[0] += 1;
    //shortage = 1;
    }
    P2IFG = 0x00;
    }
    Sure I see here register overflows, so the rate is high. But i will go to try to toggle a pin within the interrupt routine.

    I can not measure the power consumption of the uC separately, except there is a register I haven't seed before I could read while debugging. The Problem was identified on customers site, we delivered up to 3k devices and received 3 back, where 2 are showing the same behavior. But how I mentioned above, all devices passed successfully the 30 minutes final test before.

    This uC has on Port2 only P2.0, P2.1, P2.2. Two pins, P2.0, P2.1 are static inputs connected externally either go GND or VCC use 10k pull-ups. Can a electrostatic discharge applied to P2.0, P2.1 have a such influence on P2.2? I've aslo checked P2SEL1 and P2SEL0 registers for P2.2 there are 0, which is correct.

    Thank you.
  • Hi Artur,
    port interrupts have low priority, thus if the I2C and port would be pending at the same time, the I2C would be serviced first. So this is not a safe method. You need to see some CPU related activity outside of ISRs, or select another interrupt source with a lower priority.

    Unfortunately there is no possibility to measure the current on the device itself by debug information. An electrical over stress can cause any strange behavior though I would expect seeing a transition or strange levels on the affected GPIO. But you never know. That's why I recommended the current measurement. Probably you will have to pull the MSP430 device off the board carefully, to be able to test it e.g. in a socket board.

    Best regards
    Peter
  • Hello Artur,
    what is the status on your side? Is there something we can still do for you?

    Best regards
    Peter
  • Hi Artur,

    Since no feedback from you for some days we will close this thread temporary, you can still reply with update.

    More comments here: maybe you can try to verify the issue is coming from MSP or other IC as you mentioned the P2.2 is connected to the other IC.
    A quick way is cut the connection to the other IC but keep the pull high resister on P2.2 and see if there is still fault Interrupt triggered.

    regards
    KC
  • Hello Peter,

    sorry had some busy days. Finally I could run some test today. Tried to initialize this pin to an output, still receiving interrupts. Than also used internal pull-up/pull-down (external 10k pull up is still in place), the same situation. Than I wrote some code to toggle a pin within the ISR which is connected to external interface and I could measure a stable frequency of 363.6kHz, which means that the interrupt is called with the double frequency of 727kHz. 

    #pragma vector=PORT2_VECTOR
    __interrupt void P2_ISR(void)
    {
    	if(P2IFG & BIT2)  
    	{
    		PxOUT_INTL_DCDC_DIS 	|=	DCDC_DIS;				
    		PJDIR ^=  INT;  // INT = 0x0010
    	}
    	P2IFG = 0x00;   
    }
    

    Any Ideas?

  • Without this line of code:
    PxOUT_INTL_DCDC_DIS |= DCDC_DIS;
    The ISR call frequency is ~ 440kHz * 2 = 880kHz.
  • Hi Artur,

    Thanks for the test and update, may I know the test you have done is using a simple test code which only enable the port interrupt or base on your original application code? Is the frequency you have measured has some relation to your application like interface communication rate?

    As Peter suggest, is it possible to pull the MSP430 device off the board carefully, to be able to test it e.g. in a socket board? If this issue still happened on a socket board with a port interrupt enable only code, it's more like a silicon broken issue.

    regards
    KC
  • Hi Artur,

    We will close this thread temporary but you can still reply with any update then we will keep follow up. Thanks.

    Regards
    KC

**Attention** This is a public forum