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.

MSP430F5524: If-else loop not working properly

Part Number: MSP430F5524

(I am reposting this because the first time I posted it selecting that the problem was in CCS. I am not sure if that is the case and if the former post would be visible to the public at large.)

I am facing a pretty weird situation. I am using a series of if-else loops inside a function to determine the signal going low at different GPIOs. On putting a breakpoint(or when executing in real time), two of those if loops are being entered even when the condition is clearly false. To give you an example,

uint08 val = P6IN & 0x40; // value is 0x40 or 64. The input signal has been verified in the CRO as well. P6.6 is continously high


if(val == 45)


//The program flow enters here



if(val != 64)


//The program flow enters here


Please find the screenshots attached. I have tried various other ways of accomplishing the same, such as just doing if((P6IN & 0x40) != 0x40) but the behaviour doesn't change. Interestingly, the other if-else loops in the function are working fine.

  • I can't really tell anything from your code fragments. But I should point out that:

      keyProjOnOff = 0;
      keyProjOnOff = 1;

    Can be more easily and legibly written as "keyProjOnOff = !keyProjOnOff;

  • 1) Each of those if() blocks is empty. How do you know your program entered them?

    2) I don't see where "val" is assigned. Is it somewhere visible to the code fragment you posted? Try declaring it "volatile".

  • Hi Bruce

    (1)I know that the code entered them because the program was stuck there after putting a breakpoint. You can note the green colour cursor at the end of the if portion. I originally figured out it was entering them because another function was being called from inside the specific if loop portion. This was just a simple scenario for the purposes of posting.

    (2)"val" is visible to the code fragment posted. I will try declaring it as volatile and let you know, but the original code had if((P6IN & 0x40) != 0x40) {  } where the code used to enter despite Pin 6.6 being continuously high which has been verified by me on an Oscilloscope and a  multimeter. There is no other place where P6.6 has been changed. The same behaviour is being observed for P6.2 as well. 

    I think there is some problem while checking the condition for input pins being high or low. Could there be an issue with the CCS optimisation parameter?



  • If you suspect a problem with code generation, examine the code. It is almost certainly a problem with what you have written and not the code generator. Something as simple as using "|" when you meant "!".

  • Hi David,

    I can't find something that is obviously wrong with the code. There could be other ways of writing the same line of code, such as using a switch case statement, but this very manner of code has been used in the other if portions and has been working fine. In almost all the places in our project we are reading the input on GPIOs in this manner:   if((P6IN & 0x40) != 0x40) { } to detect the P6.6 going low. It is only recently that I am observing this not working as expected in a few places. Is there something incorrect/technically inadequate with the line? How could I overcome the problem? A couple of ways I have thought of include using a switch-case statement, saving the value of P6IN register in  a global variable or a volatile variable. P6IN can't be configured for rising/falling edge interrupts or I would have done that.



  • I expect Mr. Schultz was referring to assembly code.

    Try "View->Disassembly" in the debugger, or "Build Settings->Compiler->Advanced->Assembler Options->Generate listing file". 

  • Hello Abhishek,

    I agree with the recommendation, looking into the disassembly, including stepping through the code and applying at the same time the respective signal at the pin, where you expect the response according to the input state. In the register window of the IDE you should at the same time on single step see the state of the P6IN register, which should on every step executed reflect the actual pin signal state, which you can apply externally.

    If you don't see the P6.6 input state reflected correctly on single stepping in the register window of the IDE, then check whether really the GPIO input function is selected. Please consider also a potential HW problem. Could the pin be damaged by ESD?

    At least to dome extent you could check this by using the Comparator function of P6.6. This BTW might be a way to work with interrupts, using the Comparator input for checking the P6.6 input state, in case you're not using it for other application functionality.

    Best regards,


  • Hi Peter, Bruce

    I don't have the said board with me currently. I will update you after receiving it in a day or two.



  • Hi Abhishek,

    any updates on this from your side? Shall we close this?

    Best regards