CCSv4 Beta 5 Available

John,

A somewhat related problem but under CCS4.0 where after many successful debug sessions, the Debug Active Project will Load out the Target on the USB but not Run to Main.This condition is not transitory. The CCS window does not show any memory, nor register contents (essentially remaining at the Load state) The target board will not respond to any run commands but after a USB unplug/replug will flash the LED's like everything is otherwise OK. This occurred after a major rewrite of my RF2500 _ED application to modularize the code. I cannot recall modifying any files other than my project files. I added about 12 .c files and corresponding .h files, but these all compile and link without error (of course after many tries to get the code syntax correct  "as the machine reads it"! I then tried to debug the first successful compile when the Run to Main problem was first detected.

 I have tried the following diagnostic tests;

Tried a different EZ430 USB stick without success.

Tried a different RF2500 Target board without success.

Tried to use the _AP  project as the Active Project with a Target board whose LED flashes were different than the current _AP. After _AP Target load, still without Run to Main functioning, and after USB unplug/replug  the board's LED flashes reflect a correct _AP sequence.

Uninstalled and reinstalled CCSv4.0.1.01001 with no change.

Then I found this post and followed the path of breadcrumbs to .ccxml files (both _ED and _ap  are unique and both still say Run to Main and still have the same Target configuration), and to msp430.gel file which leads me to an apparent deadend.  File msp430.gel says OnRestart() if PC==0  run GEL_Reset (). Searching both CCS files and my project files reveals no clue to the location of the OnRestart() routine.

Also based on the launches topic, I found an unusual location for the _AP.launch, it is stored in the _ED.launches directory along with the _ED.launch. However I found in the LaunchConfigurationHistory.xml file that the _AP path reflects this unusual location. I attempted a novice review of these .launch files and can not detect a possible source of my problem.

Where do I look next or go back and re-look?

Bruce

 

While still persuing a problem resolution, I learned of spraa74.pdf and am learning about the Code Composer Startup Process. They say a little knowledge is dangerous; so I must now be dangerous! [ I sure would like a TI Thesarus for all of these great support pdf's that I only seem to stumble on. A lot of time spent searching would be eliminated. ]

The GEL_Reset() callback in msp430.gel now makes sense. But from what I can learn has remained unchanged between successful debug sessions and failing debug sessions.

Another possible problem source is the USB driver. The uninstall and reinstall should (?) have reinstalled the driver. In case it is the problem and was not, I reviewed the MSP_FET430UIF JTAG Tool  USB driver in Device Manager and regedit and in USB Device Viewer and found nothing apparently amiss.

Still looking and still need help.

Bruce

Even a blind squirrel can find an acorn!

Did two things; don't know which one worked.

First I Removed all Terminated Launches (via Console XX icon). I faintly recall a terminated Launch Message that I may have replied incorrectly.

Then retried Debug Active Target. Looked the same, did not Run to Main. Gosh Darn!

In desperation did Window->Show View->Debug.

Viola! Target Ran to Main!  As Kermit said (with literal license)  " it's great being green" !

 

Bruce

 

 

Bruce,

GEL is the debuggers expression language.  The "On" functions in the GEL file are callback functions.  i.e. when there is a restart initiated from CCS it will call the GEL OnRestart() function and the debugger will execute the commands that are in it.  Essentially they are a way to tweak the behaviour for a particular device.  

So even loading the blink example on the eZ430 stick fails to run to main?  A quick way to try this is create a new project for F2013.  Add a source file, in the source file type b and then Ctrl-Space.  Select the Blink macro from the popup that appears.  This will insert the Blink example code.  Save the file and click the bug button.

John

 

I think my replies are getting lost in the Ether somewhere.  Looks like you figured the GEL stuff before my message finally got on the server.  We should take that app note you found and create a wiki topic out of it or at least put a link on the wiki to it.  It is a bit old but is pretty good at explaining those GEL startup files.  In general for MSP430 you should never have to touch it.

So you had the Debug View closed and then opening it may have resolved the problem?  We really recommend keeping that open.  I am wondering if the problem was that CCS didn't have the right context.  i.e. the debug view is what determines the debug context of the rest of the views in CCS, it could be that it was set to one of your old terminated launches and by clearing them and then opening the view the context got set correctly.  Just a guess at how you tripped over the acorn.

 

John

John,

Thanks.

I think the Debug view may have been accidently deleted by my Screen Power Saver and my wireless trackball. After a while, the wireless trackball goes into battery saving mode and requires a button press to restore. And if the Screen Power Saver Blank Screen happens to have the cursor positioned on an action, then sometimes the wireless wakeup gets transmitted to the PC and the action is taken, However, the blank screen won't let you know what just happened. A possible scenerio for the missing minimized debug screen.

A possible CCS future improvement to test for a Debug window and restore if missing?

Bruce

Bruce, When someone closes the debug view we open a view, called a cheat sheet, that explains that closing the debug view is not recommended. We started doing that as a number of people would close the debug view thinking that it would end the debug session. Others just like to close it as it takes up space. CCSv4/Eclipse has a lot of views so I can understand why they want to do it. We have an FAQ that talks about how to get the debug view back: http://tiexpressdsp.com/index.php/FAQ_-_CCSv4#Q:_My_.27Debug.27_view_is_gone.21_Where_did_it_go.3F We have made some changes to the cheat sheets in 4.1. People found them a little too annoying so now they are easier to say don't show me this anymore... Regards, John

John,

Thanks for the clarification about the cheat sheets. Count me as one who found it annoying; disruption of a chain of problem resolution thought, and taking up space are the causes. At times in the debugging process, an awareness that a significant rewrite of a section of code will be required; the mental process of what must be changed is already underway. The desire is to get back to coding and compliling is strong. Debugging may not even be needed again during this session, so why not just "kill" it?  And I have a triple display monitor setup, yet I can't seem to get CCS to use more than one monitor. If you have ever used Photoshop on a single monitor, you will recognize why I have three; but two sit unused with CCS.

I am a relatively new CCS user but have an extensive computer background including computer design. CCS is just a tool that I am using for developing an embedded application. I am reminded of the conceptual differences of the original Macintosh versus the DOS PC; DOS PC was designed by people, such as myself before learning Macintosh philosophy, who thought they were building a computer, Macintosh was designed by people who recognized that they were building a tool. So learning CCS is like concentrating on my new hammer when I am just trying to build a house.

For instance, the FAQ you reference is pretty adamant that the Debug view is essential, yet the close button is not dimmed. The debug cheat sheet does reference using Control-Alt-T for closing the debug session, with some additional comments that it is not necessary to close the debug session. Then why provide a keystroke shortcut? The use of Clean is also touted, yet no keystroke shortcut or icon  is provided for Clean.

Please take my comments positively,

Regards, Bruce

Bruce Horvath said:

And I have a triple display monitor setup, yet I can't seem to get CCS to use more than one monitor. If you have ever used Photoshop on a single monitor, you will recognize why I have three; but two sit unused with CCS.

Bruce,

There seem to be some tips out there for using multiple monitors with the Eclipse IDE. Googling around:

http://stackoverflow.com/questions/318940/any-tips-on-how-to-organize-eclipse-environment-on-multiple-monitors

http://aspectprogrammer.org/blogs/adrian/2006/02/tips_for_using.html

etc..

You can see if some of the them work for you.

With my multiple monitor setup, I like to open multiple workbench windows, with one on each screen. I find this really handy. You can have one window for the projects perspective and one for debug. Or you can have both in debug perspective but with different window layouts. And for multi-core debugging you can have each workbench window have the context of different cores.

Ki-Soo Lee,

Thanks for the tips.

When I tried to drag a window to a second monitor it justs snaps back to the primary window. I think if I work with my NVIDIA nView Desktop Manager settings I can get multiple monitors working for CCS. I should have remembered that!

Bruce