Linux CCsv5.1 M5 termination on Connect Target...

Joe,

There is a known issue that causes CCS to vanish without trace, both in Linux and Windows. Whenever the Java Virtual Machine reaches its memory allocation limit (close to 2GB of RAM for the 32-bit version used by CCS) it fails to catch this condition and report the out of memory error condition.

Although we are not able to "fix" the JVM, we have been working to reduce memory usage in CCS end to minimize this condition. This implementation is not yet released as of today but will be in one of the next versions of CCSv5.1.

I apologize for the inconvenience,

Rafael

I hit Post too fast.

If the condition above does not apply in your case - i.e., the JVM is nowhere near the 2GB limit - you can check the usual suspects and perform a cleanup of your system. Check the sections General IDE and Debugger of the troubleshooting page below.  

http://processors.wiki.ti.com/index.php/Troubleshooting_CCS

If you are hitting the memory limit, try to use the configuration TI814x (no STM, ETB only) and see if you get a more stable operation - it uses less memory as it does not have the STM module.

Hope this helps,

Rafael

I'm already using that configuration for the 8148EVM.  Not exactly sure about JVM usage under Linux, but under Windows it's a seperate process and you can kill it from the process explorer.  Once killed there shouldn't/wouldn't be a problem unless when CCS is started it allocates all the memory your speaking about...

In my case, all I'm doing is starting CCS, launching a target configuration and then I do a Connect Target.  If this allocates and uses 2GB of ram then you folks may have a tough time to "minimize this condition"...;)...

Also, I forgot to mention that my problem occurs even when I run CCS with the command line option -clean...doesn't seem to make any difference.

Does this issue only occur on 32-bit systems? (i.e. if I were running a 64-bit system would this still occur)?

I tried deleting the .metadata directory but to no avail.  As soon as I do a "Connect Target" it still disappears. 

I had been working with some of the TI folks in the CCS group over the last week or so (privately arranged via TI webex sessions).  I didn't mention it before in this post, but I'm doing Linux Kernel development, so I'm loading just symbols & source code files for Linux and my kernel modules.  At this point I'm at a total standstill...I've been attempting to work with CCS for more than a week...that's more than a week not writing code, but instead spent debugging problems in this development environment.  I'm about ready to toss this thing out the window...it's clearly not ready for prime time...if I sound like I'm frustrated I am!

Also, the same sort of thing occured on Linux CCSv5.0.2...it just disappeared off the screen.

Joe,

Joe Cossette said:

I'm already using that configuration for the 8148EVM. Not exactly sure about JVM usage under Linux, but under Windows it's a seperate process and you can kill it from the process explorer. Once killed there shouldn't/wouldn't be a problem unless when CCS is started it allocates all the memory your speaking about...

Running CCSv5.1 in my Ubuntu box shows only an eclipse process (no java) and its memory usage in real time can be seen by opening a command prompt and running top.

Command line said:

user@ubuntu10:~$ top

top - 16:55:39 up  8:41,  2 users,  load average: 0.29, 0.31, 0.16
Tasks: 166 total,   1 running, 165 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  1.7%sy,  0.0%ni, 95.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1023784k total,   940860k used,    82924k free,   149004k buffers
Swap:  1951888k total,     8740k used,  1943148k free,   246092k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 1160 root      20   0  176m  63m  20m S  1.7  6.3  16:51.97 Xorg              
 3155 user      20   0  923m 254m  50m S  1.7 25.5   2:00.95 eclipse           
 1726 user      20   0  207m  15m  10m S  1.0  1.5   0:04.04 gnome-terminal    
 1612 user      20   0  290m  14m  10m S  0.7  1.4   0:01.51 metacity          
 1659 user      20   0  250m  14m  10m S  0.3  1.5   0:01.05 wnck-applet       
 4237 user      20   0 19224 1412 1028 R  0.3  0.1   0:00.43 top               
    1 root      20   0 23844 1792 1180 S  0.0  0.2   0:00.43 init              
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.01 kthreadd          
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0       
    4 root      20   0     0    0    0 S  0.0  0.0   0:00.05 ksoftirqd/0       
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0        
    6 root      20   0     0    0    0 S  0.0  0.0   0:00.24 events/0          
    7 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cpuset            
    8 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper           
    9 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr         
   10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm                
   11 root      20   0     0    0    0 S  0.0  0.0   0:00.01 sync_supers 

Unfortunately I don't have a DM8148 EVM to try to reproduce this, but some coworkers haven't seen similar issues.

Joe Cossette said:

In my case, all I'm doing is starting CCS, launching a target configuration and then I do a Connect Target.

In this case, would you mind collecting the Debug Server Log information as stated in the link below? This will give us a clearer idea on what may be happening in this case.

http://processors.wiki.ti.com/index.php/Troubleshooting_CCS#Debug_Server_Logging

Joe Cossette said:

Does this issue only occur on 32-bit systems? (i.e. if I were running a 64-bit system would this still occur)?

The memory limit is tied to the Java Virtual Machine, not the PC or OS itself. Since CCSv5 uses a 32-bit version of the JVM, the limit is still there even if the OS is 64-bit.

Joe Cossette said:

I had been working with some of the TI folks in the CCS group over the last week or so (privately arranged via TI webex sessions). I didn't mention it before in this post, but I'm doing Linux Kernel development, so I'm loading just symbols & source code files for Linux and my kernel modules.

I really didn't know there was already history there, but I apologize for the issues. I talked to the "TI folks" and we are trying to arrange another webex to try to get down to the bottom of this issue once and for all. If you can send the Debug Server Log information before the webex (mentioned above) it would greatly help to do a pre-analysis.

Joe Cossette said:

it's clearly not ready for prime time...

Yes, you are right. The exact cause of the issue may be a combination of factors: CCSv5.1 is still in beta and (I think) the DM8148 EVM is still in pre-production phase.

Best regards,

Rafael