DSS - Gel - Javascript: Who's on First?

Hi Andrew

I'll start will the easy questions first:

AYM said:

Does .gel always get called when a breakpoint is reached even if there is no "onHalt()"?

When the target execution is halted (whether via breakpoint, halt command, etc), the debugger will call a GEL onHalt(). If there is no GEL file loaded that defines this call back (or if the function is defined but empty), then nothing will happen. If this callback is defined in a GEL file then the contents of it will be executed.

AYM said:

If .gel starts starts the target running "GEL_run()" after remove all breakpoints, while the Javascript is pending on "dsp1ds.target.run()", what state is the Javascript thread left in? Is there any way for the Javascript to return from "dsp1ds.target.run()"?

target.run() will return when the target is halted. If the onHalt() GEL function is being executed, then you know the target has halted. So target.run() will have returned

AYM said:

Would be helpful if anyone at TI can give an overview of this DSS - GEL - Javascript relationship.

Javascript is simply the host scripting language that can call DSS APIs. DSS is a set of Java APIs that provide an programmable interface to the debugger. GEL is the expression language that is used by the CCS debugger and it is part of the debugger itself (while DSS is a layer that sits on top of the debugger). A lot of what you do in the debugger via the GUI (like pressing the "Suspend" button to halt execution) actually calls a GEL function (GEL_Halt() in this case) under the hood. DSS can actually call GEL APIs directly with the DSS expression.evaluate() API.

The thing to remember about GEL is that it is part of the debugger (so you can't use GEL until there is a debug session running) and that you can load a GEL file for each core in a multi-core environment. That is why in the target configuration file, you can specify a GEL file for each core. And that GEL file will only be loaded for (apply to) that core only. So If you load a GEL file for CPU1, the contents of that GEL file will only apply to CPU1. CPU2 would not be affected, and would not be able to access any GEL content in the loaded GEL file for CPU1. They are separate. An example is if CPU1 has a GEL file loaded that does some action in OnHalt() will CPU2 has no GEL file loaded. When both CPUs are halted, only CPU1 will be affected by any actions in that OnHalt() command.

For DSS, you can have a single DSS script that launches multiple debug sessions (one for each core) and then control them all from the same script.

AYM said:

I have code that came from TI with the  .gel  intialization file  "c:\ti\ccsv5\ccs_base\emulation\gel\DRA7xx\DRA7xx_dsp_basic_emulation.gel" that came configured with calls to "onHalt()" that removed all breakpoints after 1001 breakpoints where reached.

I'm looking at this GEL file and I'm not sure what is going on here. I don't think the intent is to halt 1000 times before doing something. If you look at some of the other GEL functions, you can see that they all set G_control to 1000 before executing:

//hotmenu basic_asm_execution_control_ddr1()
basic_asm_execution_control_ddr1()
{
    PC = 0x88000800;
    G_Control=1000;

...

So it looks like one of those functions are meant to be called first to set G_Control to 1000 before running and from there the first item in the OnHalt() if statement would be triggered. It was not meant to hit 1000 halts before doing anything. I really don't understand what the GEL function is written like that and why they use 1000 instead of just just using 0, 1 ,2 unless whoever wrote the script figured it was same to assume someone would never halt 1000 times in a single debug session so only people running the other GEL functions in the file would ever execute those if statements. It is strange to me and a question best asked to whoever wrote that script.

ki