GUIComposer crashes on import/export/install (GNU/Linux)

Hi Sebastian, 

Sebastian,

Unfortunately, this escaped our testing. If you are willing to do a few steps manually, then you can create the equivalent  of what export does. As a first step I would download the linux version of the runtime from here

http://processors.wiki.ti.com/index.php/Category:Gui_Composer#Linux

Once you run the installer inside InstallRoot\guicomposer\webapps\modem_m3 directory is the example application. We will use this as an example of files that are necessary. 

Second important directory that contains the output of your design is located in CCSWorkspaceRoot/.GUIComposerWS/YourAppName. By default you should see .settings directory app.css,  app.html, app.json and app.js. 

If you compare this to what is in Runtime's sample application, you will notice that there are some additional files. appConfig.ccxml, appInit.js, appProgram.out, index.html and modem_m3_gc_app (there are also equivalent windows binaries). 

appConfig.ccxml => This is the configuration file for the device/emulator that you are targeting. Create one in CCS Setup editor, then copy created .ccxml file to your appDirectory and rename to appConfig.ccxml

appInit.js : This is a DSS script that performs targetdevice initialization. You can try to just copy this file as is to your application. You may need to adjust this script a bit dependening on your HW. Particularly, line 10 might be important. This call enables ability to temporarily halt the execution to perform target access for HW that does not support non-intrusive access. The sample app is using a simulator, thus it also requires this mode to function. 

appProgram.out : This is your program(CCS Project generated .out) renamed to appProgram.out

index.html: boiler plate html, you can just copy this file. 

modem_m3_gc_app : Linux executable that starts the file, you can just copy this file to your application and rename it as necessary

modem_m3_gc_app.exe : Windows version of the same executable. 

modem_m3_gc_app.ini : Configures some inital settings for the windows size. It is only supported on Windows today. 

Once you have created this directory, you can just copy it to runtimeimes \guicompser\webapps folder and start your app with launcher (executable). Please note that runtime today only supports C2000, TMS570 and Stellaris devices. 

Martin

Hey there!

Thanks for the quick help! I'm struggling with the appConfig.ccxml for my F29069 controlSTICK:

The generated ccxml references the file "boards/controlStickF28069.xml" which is not found. I noticed that the "css_base/common/targetdb/"-directory within the CCSv5 installation contained such a file and copied it into, but this file in turn references the file "devices/f28069.xml" which to my understanding as well references a bunch of other files.

Any help?

Best regards

Sebastian

Hi Sebastian, 

Unfortunately, we had a few issues with our linux installer for GC Runtime. These should be now corrected and newer version is available from GUI Composer Wiki. It should be versions 1.7.0.1. It should not properly install C2000 and Stellaris support. 

My appologies for these issues. 

Martin

Happy new year everyone!

I was able to get the software running! :-) Looks and works very nice!

Now I have a small problem:
I have a float variable holding the amplitude of a sine wave which is used to compute the HRPWM duty cycle. I also implemented a mechanism which sets some predefined amplitudes one after another to be able to perform THD-measurements. It essentially sweeps the amplitude from 0% to 100% logarithmicly.
This variable is read by the GUI and bound to a vertical slider. At first the amplitude was set directly during the sweeps, leaving the "amplitude" variable unchanged and everything worked fine. Then I copied the value to the variable to give some graphical feedback of what's going on, which lead to strange results:
When I run the program through the Preview Mode of GUIComposer, the PWM duty cycles are set correctly, but the vertical slider gets updated only once on 1.0 (100%).
If I launch the same program as a stand-alone GC-application, the PWM stops about once per second and the slider doesn't get updated at all.

Any ideas?

Kind regards.

Sebastian

Hi Sebastian,

The slider's value is an integer type. Are you setting the slider's range from 0 to 1? If this is the case, then you need to have a post processing function that converts decimal to integer.

Perhaps you can use the dial instead of the slider, I believe the dial accepts decimal values.

Regards,
Patrick 

Hello,

that solved the problem in CCS / Preview.
I had been able to set float values through the slider but the other way around obviously doesn't work or at least not always: I have a second slider which sets the maximum amplitude of the sweep. If I set the corresponding variable through the debugger the slider quantizes to 0 or 1, but when I drag the slider around, it sets the correct float value and after I did that a few times, it also works in the opposite direction, so now the slider gets updated correctly after a new value is entered in the debugger. Very confusing.

Anyway... After introducing a new long variable that holds the amplitude float * 1000000, the amplitude slider gets updated correctly and everything is working really fine in the Preview.
The stand-alone version still has the flickering PWM and is VERY unstable. Here the console output of the application:

2013-01-04 00:34:21.149:INFO:oejs.Server:jetty-8.0.4.v20111024
2013-01-04 00:34:21.176:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:7272 STARTING
Initializing target : /home/haggl/software/ti/guicomposer/webapps/pwm4audio/appConfig.ccxml

flxInitLoad: client has not been protected.
flxInitLoad: client has not been protected.
Connecting target: Texas Instruments XDS100v2 USB Emulator_0/C28xx

Loading program: /home/haggl/software/ti/guicomposer/webapps/pwm4audio/appProgram.out

Running Program...

SEVERE: C28xx: Error: (Error -150 @ 0x0) One of the FTDI driver functions used during configuration returned a invalid status or an error. (Emulation package 5.0.872.0) 

exiting keepAlive for connection=WSFrameConnectionD08@127.0.0.1:7272<->127.0.0.1:36286
Initializing target : /home/haggl/software/ti/guicomposer/webapps/pwm4audio/appConfig.ccxml

exiting keepAlive for connection=WSFrameConnectionD08@127.0.0.1:7272<->127.0.0.1:36306
Connecting target: Texas Instruments XDS100v2 USB Emulator_0/C28xx

Loading program: /home/haggl/software/ti/guicomposer/webapps/pwm4audio/appProgram.out

Running Program...

SEVERE: C28xx: Trouble Halting Target CPU: (Error -150 @ 0x0) One of the FTDI driver functions used during configuration returned a invalid status or an error. (Emulation package 5.0.872.0) 

SEVERE: C28xx: Can't Run Target CPU: (Error -1041 @ 0xFFFFFF6A) The emulator reported an error. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.0.872.0) 

SEVERE: C28xx: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.0.872.0) 

SEVERE: C28xx: Power Failure on Target CPU 

SEVERE: C28xx: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xa8ae156f, pid=7739, tid=3076794048
#
# Java VM: Java HotSpot(TM) Client VM (11.3-b02 mixed mode linux-x86)
# Problematic frame:
# C  [libxul.so+0xd5056f]  _ZN16gfxAlphaRecovery16RecoverAlphaSSE2EP15gfxImageSurfacePKS0_+0xc9
#
# An error report file with more information is saved as:
# /home/haggl/software/ti/guicomposer/eclipse/hs_err_pid7739.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Also the programming is taking a very long time in both CCS debug and the stand-alone application. All in all it takes about 3-5 minutes!?

Greetings

Sebastian

If it works in preview but not in the stand-alone application, it sounds like you have two different version of the javascript libraries. Can you tell me the version of CCS and the standalone application that you are using? I'll try to track it down to see if this is the case.

You might get better support if you open a new thread regarding the load time for your application. This is not related to GUI composer, but the debugger itself. There are other experts that can help you on this issue.

thanks,
Patrick 

Hello Patrick,

these are the names of the installers:

CCS5.3.0.00090_linux
GUI_Composer-1.7.0.1-Linux-x86

Thanks

Sebastian

Hi Sebastian, 

You have correct versions of installation packages. 1.7.0.1 should contain the same driver/debugger files as 5.3 RTM (i.e. build 90). GUI Composer by default has about a 1s refresh cycle to update GUI Components. Thus if your test sweep is short you might not get the resolution that you are looking for. There is a way of adjusting it, but depending on the volume of data the application might not be able to keep up. Particularly, graphing data arrays in graphs can use a lot of data. Let me know if you would like to know how to adjust refresh cycle. It requires a bit of manual tweaking. 

Jerky updates in standalone might be caused by differences in how debugger is configured. By default appInitScript.js has a configuration line that works well with simulator's, but not so well with HW, particularly C2000 HW. In motor control type applications this is manifested by motor not spinning smoothly as debug engine halts the CPU to perform access. This difference is mentioned in topic below. I have also attached appInitScript.js that we used for an internal  application that is using 28069. 

http://processors.wiki.ti.com/index.php/Category:Gui_Composer#Application_Export_.C2.A0Important_Notes:.C2.A0

Lastly, I don't think C2000 supports float's natively, thus you are most likely using Q math library to represent floats. There is a way of showing Q values in GUI, but it does require specifying pre/post processing functions that in essence perform the Q value conversion. We also used pre/post functions to control other display type formatting such as how many decimal digits to display in text boxes. There is no GUI designer way of specifying these functions today, but I'll create a wiki topic if this is of interest to you. 

Martin

importPackage(Packages.com.ti.ccstudio.scripting.environment)

function initTarget() {
	var debugServer = ScriptingEnvironment.instance().getServer("DebugServer.1");

	print("Initializing target : " + appConfigFile+"\n");
	debugServer.setConfig(appConfigFile /* internal variable */);
	var session = debugServer.openSession("*", "*" /* TODO: */);

	/*session.options.setBoolean("UseLegacyStopMode", true);*/
	
	if (!session.target.isConnected()) {
		print("Connecting target: "+session.getName()+"\n");
		session.target.connect();
	}
	
	print("Loading program: "+appProgramFile+"\n");
	session.memory.loadProgram(appProgramFile /* internal variable */);
	
	print("Enabling Realtime\n");
	session.expression.evaluate("ST1.DBGM = 0");
	session.expression.evaluate("GEL_EnableRealtime()");
	
	print("Running Program...\n");
	session.target.runAsynch();
}

initTarget();

Hello there,

that did it! The GUI is now running smoothly, it's just awesome! :-D

The F28069 has a FPU, so it does support native floats. I already wrote pre-/postprocessing routines, so everything gets displayed correctly.

Now the only problem that remains is the slow initialization process. I'll try to gather some more information on the phenomenon (it's very slow on my machines at home, but I think it works well on the computer in the office) and open a new thread.

Best wishes,

Sebastian

Hi Sebastian, 

I am glad to hear that it is working well for you. Slow load time might be related to slow debugger start under certain conditions, rather than long load, see forum post below:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/219478.aspx?pi70789=2

Could you try temporarily removing/disabling your network connections to see if the problem improves? Also, if it does, could you try reconnecting network connection and adding following line to ccstudio.ini file in "CCSInstallroot\ccsv5\eclipse" directory. You would need to add it anywhere after -vmargs line. 

-DFORCE.REG

Thanks,
Martin

Hey,

disabling the network connection works in both CCS and GC standalone application. Adding the VM argument works in CCS, but unfortunately not with the GC application. I added the line to GUIComposer.ini in the guicomposer/eclipse directory. Is that the wrong place?

Greetings

Sebastian