Here is the code:
There are several things you can start to do to identify what is happening:
1) Add some serial printf statements or blink an LED in your main code to verify the processor is running.
2) Make sure that your vector interrupt table and start-up code are running. Some debuggers will set these up for you even if your project doesn't! This can result in a functioning debugger program and a halted release program.
Well, I glad to see state machine programming, :-) I would recommend using enumerations for your states. Now as to you question;
while ((ADC10CTL1 & ADC10BUSY) == 0x01);
Has the potential to lockup the system should the ADC have an failure ie always busy. I'd recommend using an if statement or at least use some kind of counter to allow exit after some iterations. Look into run to completion state machines.
AverageM() this function, which contains the above line, is being called from and interrupt service routine(ISR) and has auto variables. Generally I don't like calling functions from an ISR, but if you are going to do that make sure your stack is large enough to hold the call plus the auto variables. Consider setting a flag in the ISR then reading the ADC from main. Again I recommend looking into run to completion state machine.
Since your code runs in debug mode, then the above comments may not be what is causing the observed behavior, but there's no guarantee since debugging the code generally changes the timing. I recommend you address the above issues.
Another thing to consider is; often times these build environments insert code or define code when built in debug mode that waits for the debugger to attach. These tactics are used to ensure the debugger can get hold of the MCU (Micro-controllers)
should there be a catastrophic coding error that causes the program to
enter a tight loop or be stuck in an ISR. This is especially true for MCU's that do not have hardware break-point capability.
Ensure you are building the code in release mode when you want to run without the debugger. If you are building the release mode, then read through the manual for the development environment. See if there is a #define that removes the wait for debugger code.
These issue can be tricky to find, but each success hones your skills.
Check the compiler options for both standalone and debugging. Usually the compiler options when debugging don’t include optimisations where the standalone compile does. If you can compile a non optimised standalone version that works then the problem is in your code. The compiler needs to know what is safe to optimise and what is not. The volatile keyword needs to be used on variables that change inside an interrupt otherwise the compiler optimises the code for those variables in the main code, which is not what you want
averageFloat = 100 - (sumM / 10 - 400) * 0.25641; //Calculation average moisture from array sum. Converting 0-1024 range to 0-100. Calibrate average value so that sensor in the air(dry) is 0 and in the water is 100.seems to be wrong and can return negative values. Check this averaging.
Adding to the valuable review comments by @tcfkat and @hodgec:
Always check for ranges of parameters used in functions - either those that are passed to the function or those that are computed. If you know the minimum and maximum limits of these values prior to implementation, then put checks for these limits and park them to safe limts if they go over or under.
Thanks to all for your answers!
My 32kHz crystal circuit was disabled so it couldn't work.
I changed line CSCTL3 |= LFXT1S_0; to BCSCTL3 |= LFXT1S_2; (ACLK = VLO) and now program works.