This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28335: Debug Server Scripting / GEL_System() Interaction

Part Number: TMS320F28335
Other Parts Discussed in Thread: TEST2,

Tool/software: Code Composer Studio

We have a number of legacy automated test scripts that were written in gel.

I am able to run the test inside of Code Composer Studio 7.0 via the GEL Files window, Load GEL, and Run. The test script executes to completion, I see passing results, and a results file is generated.

Because we have many of these, we were looking for a way to batch these test scripts. This lead us to look at the Debug Server Scripting interface.

As a proof of concept, I made a small wrapper script to launch the GEL script that already exists:

//****************************************************************************
//** Load environment
//****************************************************************************

importPackage(Packages.com.ti.debug.engine.scripting)
importPackage(Packages.com.ti.ccstudio.scripting.environment)
importPackage(Packages.java.lang)

// Create our scripting environment object - which is the main entry point into any script and

var script = ScriptingEnvironment.instance()

// Get the Debug Server and start a Debug Session

debugServer = script.getServer("DebugServer.1")
debugServer.setConfig("C:\\workspace\\project\\TMS320F28335.ccxml")
debugSession = debugServer.openSession("*", "*")
debugSession.target.connect()

debugSession.memory.loadProgram("C:\\workspace\\project\\Debug\\project.out")

debugSession.expression.evaluate('GEL_LoadGel("C:/DSP/test.gel")')
debugSession.expression.evaluate('RunTest()')

If I launch this via the "Scripting Console", everything works as expected and the test executes, passes, and generates its result file.

I was able to expand this further, to include multiple tests (test2.gel, test3.gel, etc.).

The next obvious step, then, would be the ability to launch the testing session directly from command line without bringing up the GUI at all. I searched around and thought I had found what I needed:

eclipsec.exe -noSplash -data C:\\workspace -application com.ti.ccstudio.apps.runScript -ccs.script C:/DSP/batch.js

Unfortunately, this only mostly works. I can see the test execute through most of the initialization sequences, I can see a breakpoint get hit, I can see values being checked, but the test does not finish; however, the debug session does end, returning access back to the command prompt.

What ends up happening is something like:

Actual   = 0 (PWM1 TBPRD)
Expected = 0 (PWM1 TBPRD)
Result   : ****** TEST PASSED ******
Actual = 0 (PWM2 TBPRD) Expected = 0 (PWM2 TBPRD) Result : ****** TEST PASSED ******
Actual = 0 (PWM3 TBPRD) Expected = 0 (PWM3 TBPRD) Result : ****** TEST PASSED ******
Actual = 1250 (PWM1 TBPRD)

In the data set above, the last set of data (Actual = 1250) is missing an Expected check and the Pass/Fail determination.

If I turn on GEL_Trace(2), I can see it walking through the various helper functions, ultimately ending at one of the many GEL_System() function calls to help pipe data to log files (due to a bug encountered with Code Composer Studio 6.0 and GEL_EnableFileOutput() not working).

It appears there is some sort of issue/limiting factor, where after so many calls to GEL_System(), execution simply stops without any debug/error information of any kind.

It appears the GEL_EnableFileOutput() bug is corrected in Code Composer Studio 7.0; however, we'd like to avoid changing our large set of automated tests as much as possible.

Has anyone else experienced this? Has anyone identified any workaround?

Edit: After running through a few more tests, with the GEL_System() calls removed, I was able to consistently get them to run to completion - so it appears to definitely be related.

With that said, I did encounter a secondary issue. It appears that the execution of tests is not exactly identical between when it runs inside of Code Composer Studio and when it runs from the eclipsec.exe command line options to launch the ccs.script.

It acts as if the initial variable values are not the same as when the build is loaded through Code Composer Studio itself. Are there specific configuration options that need to be changed to make the two run configurations be the same?

Edit 2: After running one of our longer tests, even with GEL_System() calls removed and replaced with GEL_TextOut(), the script eventually silently terminates.

  • Bumping this. Haven't seen any response/feedback or any other users running into similar issues.

    Still looking for a solution or workaround for this issue.
  • Jamie McPeek said:

    The next obvious step, then, would be the ability to launch the testing session directly from command line without bringing up the GUI at all. I searched around and thought I had found what I needed:

    eclipsec.exe -noSplash -data C:\\workspace -application com.ti.ccstudio.apps.runScript -ccs.script C:/DSP/batch.js

    This should work... but any particular reason why you are calling headless script launcher directly instead of using the recommend dss.bat file?

    In any case, calling the dss script from the command line vs the scripting console *should* be the same. The same scripting engine is used to execute both and I believe that the default debugger options will be the same for both.

    My concern is this:

    Jamie McPeek said:
    We have a number of legacy automated test scripts that were written in gel.

    Jamie McPeek said:
    I was able to expand this further, to include multiple tests (test2.gel, test3.gel, etc.).

    GEL is quite limited for the purposes of full blown automation. There are a lot of limitations for this, which the (semi)asynchronous behavior of many of the GEL calls being an issue. This can cause some inconsistencies, similar to what you experienced. It is why full DSS is recommended, since it is more reliable. The timing could be different when running from the console vs command-line as the former could be a bit slower due to some GUI overhead.

    I can't say that I am aware of the issues you are seeing. But if you can provide a small reproducible test case, that would help with the investigation.

    Thanks

    ki

  • Ki-Soo Lee said:

    This should work... but any particular reason why you are calling headless script launcher directly instead of using the recommend dss.bat file?

    Just following an example I had seen. In looking through the dss.bat file, it appears to be essentially the same call, with a bit of a wrapper around it for old scenarios prior to eclipsec.exe being available.

    To confirm, I ran the same test with the dss.bat wrapper and it resulted in the same results.

    Additionally, I upgraded to the recently released 7.1.00015 and confirmed the same behavior both with eclipsec.exe and dss.bat.

    Ki-Soo Lee said:

    GEL is quite limited for the purposes of full blown automation. There are a lot of limitations for this, which the (semi)asynchronous behavior of many of the GEL calls being an issue. This can cause some inconsistencies, similar to what you experienced. It is why full DSS is recommended, since it is more reliable. The timing could be different when running from the console vs command-line as the former could be a bit slower due to some GUI overhead.

    The asynchronous nature is definitely a burden; however, our framework is simply setup to operate purely on hitting a breakpoint, taking an action, running to the next breakpoint. Because of this, we are able to "synchronize" around the OnHalt() callback within GEL.

    Additionally, a heavy reliance on floating point data in legacy applications, combined with a lack of floating point support in DSS, continues to re-write the setup a hard sell.

    Any plans to add floating point support to DSS? Or, has it been added and we missed it?

    Ki-Soo Lee said:

    I can't say that I am aware of the issues you are seeing. But if you can provide a small reproducible test case, that would help with the investigation.

    I have a very simple example of this behavior put together, but it's a few hundred lines of code and a project for a TMS320F28335.

    The archive can be retrieved from 

    It does not contain any binaries/executables - the project would need to be recompiled.

    With the setup:

    Place "DSP_Test" in the C:\ drive.

    Import "DSP_Test/Example" as a CCS Project into a fresh/blank workspace. Build the project.

    For Auto Run settings, you may need to uncheck "run to label on reset/restart" (some tests must verify pre-C environment configuration).

    Copy the Example.out to C:\DSP_Test. Copy the EZDSPF28335.ccxml to C:\DSP_Test.

    At this point, you can run example.gel inside of Code Composer Studio in the usual way and it should execute to completion.

    You can also use eclipsec.exe or dss.bat to run batch.js and it should execute partially, then terminate silently.

    If there is a better way to get you the example setup, please let me know.