MSP430 LauncPad: ignores wait for button line of code

[jproject]

Hello everyone,

I'm in this weird situation and google won't give me the right answers. So... I made a robot that moves in a square area and it works perfectly except for one damn thing! The robot isn't suppose to move until I press the button.
It works perfectly fine when it's powered by the usb and the computer but when I plug in a 3V battery as its power source, the code for the "wait until the fricken button is pressed" is ignored. This is the line of code for wait until button is pushed:

while((P1IN & 0x08) == 0x08);   //Wait until button is pushed

Another program that I use, which uses the exact line of code, does not show any problems when I run it using the 3V battery source. But, the hold button line works if it has some coding in front of it like flash some pretty LEDs, etc. My guess is the initial power up of the LaunchPad makes the line skip for some reason.
Helppppppppppppp pleaseeeeeeeee


Thank you.

[joelby]

I haven't seen anything like this, but could it be some sort of power settling/glitching thing?

You could try the following:

• Add a start-up delay before doing anything (tens of milliseconds)
• Implement debouncing for the button in software. Using a simple state machine, detect a button press, wait for a few milliseconds, check if the button is still depressed, and only proceed if it is.

[TheDirty]

You're looking for a high value for the push button?  Don't you have it pulled up and push to ground?  It's not floating, is it?

[baljemmett]

You're looking for a high value for the push button?  Don't you have it pulled up and push to ground?  It's not floating, is it?

Unless the MSP430 inverts the input bits or something, that's waiting for a low, isn't it?

[jproject]

The switch button uses the pin P1.3 and I have not modified it in any way. The only time the 0x08 is used is in the line for the one I showed it.

[TheDirty]

Unless the MSP430 inverts the input bits or something, that's waiting for a low, isn't it?

For some reason I assumed it was an 'if', rather than a while.  I just scanned the condition.  My fail at reading.

[tsmz]

Please describe the circuit you're using and the port setup in your program.
Programs will seldom mysteriously stop working, so there has to be a problem somewhere. My first guess would be incorrect signal levels, i.e. configured pull-up instead of pull-down, floating switch etc. You could also use the debugger to check the registers while the program is running to see if it's a signal level problem or a code problem.

[jproject]

I made a hotfix by flashing some pretty LEDs first before the while statement for the button. Also, in debugging mode, the program works perfectly.

[alm]

Maybe the compiler optimizes the while loop away since it not actually doing anything, just like the famous for (i=0; i<1000;i++); loops for delay, which won't work either with any optimizing C compiler.

[insurgent]

Maybe the compiler optimizes the while loop away since it not actually doing anything, just like the famous for (i=0; i<1000;i++); loops for delay, which won't work either with any optimizing C compiler.

This could be a possibility, though if he's using TI's header files, P1IN is defined as volatile and the compiler will not optimize out the loop. If, however, he has it defined himself for some reason the it would definitely be optimized out if lacking the volatile indicator.

[jproject]

I put this into a possibility as well but Code Composer Studio usually tells me if that happens. For example, certain int variables will give me warning signs after I build and compile because it is not volatile.

[tsmz]

Have you looked at the generated assembler code? It's a bit messy, but you can probably tell if something goes horribly wrong. Another way is to actually look at the assembler instructions on the device, which I find much more useful because you can actually single-step through the program.

[TheDirty]

Please describe the circuit you're using and the port setup in your program.
Programs will seldom mysteriously stop working, so there has to be a problem somewhere. My first guess would be incorrect signal levels, i.e. configured pull-up instead of pull-down, floating switch etc. You could also use the debugger to check the registers while the program is running to see if it's a signal level problem or a code problem.

You never answered any of this.  If it's not a programming thing, it has to be a hardware issue.  You've checked the voltage on the input line when running from 3V?