## MSP430G2553: Problems while running without debugger.

Started by 1 year ago6 replieslatest reply 1 year ago126 views
Hello!I have a school project where MSP430G2ET launchpad measures soil moisture and runs a pump when soil is dry. It's also measures light and save some data to flash but I have commented those lines out. Problem occours when I try run launchpad without IAR debugger. Launchpad will freeze and program will not run. I have blinking led control in my timer interrupt (1 s cycle) so I know when the program will run. Led will not blink and stays on when I exit from debugger. When I press reset same thing happens.  I think the problem is in times interrupt routine, but I can not figure that out.

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;

This code:

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

[ - ]

This here:

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.
[ - ]