Jump to content
Sign in to follow this  
Fabinhou

Debug and Release mode

Recommended Posts

Hello, everyone.

 

I have some problems. I need to finish my final project until this week, and I realized that my program only start when I press the reset button on my LaunchPad MSP430G2553. The Launchpad is going to be on a closed box and the reset button wouldn't be reachable. 

I did some researchs, and I find out that my program was in debug mode. So I changed to release mode on CCS and the program start running as soon as power on my LaunchPad, but  everything that was working perfectly on debug mode, isn't on release mode. It seems that my program only works on debug mode. My code has something like 3000 lines, and it's hard to search for some tiny mistakes.

The question is: Is there a way to run my code on Debug Mode but make it start as soon as I power on my Launchpad instead of needing to press the reset button ?

 

 

Thank you, advance.

Share this post


Link to post
Share on other sites

While I know the problem of new bugs appearing in Release mode, the Debug mode program should start without pressing reset.

 

Did you forget a breakpoint? Or is there an external peripheral that requires some time after power-on? For the latter, a quick&dirty fix would be to busy-wait a few 100ms at the start of your program (after turning off watchdog timer and setting up clock frequency).

 

For the Debug vs Release bugs, check any places where data is passed between interrupts and the main thread. Make sure that the volatile modifier is used declaring those variables. Also think about race conditions if the interaction is more complex than one 8 or 16 bit value in one direction.

Share this post


Link to post
Share on other sites

While I know the problem of new bugs appearing in Release mode, the Debug mode program should start without pressing reset.

 

Did you forget a breakpoint? Or is there an external peripheral that requires some time after power-on? For the latter, a quick&dirty fix would be to busy-wait a few 100ms at the start of your program (after turning off watchdog timer and setting up clock frequency).

 

For the Debug vs Release bugs, check any places where data is passed between interrupts and the main thread. Make sure that the volatile modifier is used declaring those variables. Also think about race conditions if the interaction is more complex than one 8 or 16 bit value in one direction.

I'll check here for some breakpoints, and yes, there is a external peripheral that requires some time after power on. I'm gonna check it and post here later.

Thanks!

 

Edit.: Well, I removed all breakpoints and didn't work. So I decided to add the delay as you said, after holding watchdog and after initializating the clock frequency and it worked. Probably was my OLED display that needed some power up time before inializating.

Thank you! This forum is being so useful.  

Share this post


Link to post
Share on other sites

No surprise about the display. Most of the displays I have run across over the last 4 decades (Ya, I'm old....) have pretty funky startups. Less so now than then, but even the Noritake units I picked up recently want a couple hundred ms. I tend to put in a delay at startup by habit unless I KNOW things will be ok without or I ABSOLUTELY need instant startup.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×