DSS Scripting - Nonintrusive breakpoints, detailed conditions, file I/O

Joshua Lawes said:

1. Can I create data watchpoints via DSS and if so how? As I can't see the data watchpoint properties menus, I can't easily ascertain the modifiable breakpoint properties using only the API as a reference.

It is possible. The issue is that it is a pain to do if you are not familiar with it. Basically a watchpoint is an advanced breakpoint. So you need to create a breakpoint property using breakpoint.createProperties and setting up the properties to by a watchpoint and specify the conditions to watch. Then you would use:

breakpoint.add(BreakpointProperties breakpointProperties)

to add the breakpoint. There is not any good documentation on how to do this (oh how I wish there was). I'll try and put together an example for you.

Joshua Lawes said:

2. In fact, the API tells me the methods available for class objects though no real description apart from their names and no details concerning the actual elements or the values they can take. A good example is that I know for BreakpointProperty objects, I can call setString() to modify a particular property to a particular property however I do not know what the list of modifiable properties is and what range of values is acceptable. Is there a more complete reference around than the API? There are a few code snippet examples around like http://processors.wiki.ti.com/index.php/Breakpoint, however nothing showing the full range of capabilities of DSS.

3. I can see from the CCS Help documentation for Built-In GEL Functions that it is possible to set conditions for breakpoints however there isn't very much detail except to say that it must be an expression surrounded by quotation marks. Is there any more detailed information here? If nothing else, I would specifically like to know how with such expressions it might be possible to cause a data breakpoint on any change to the data (read, write or either). If this is therefore not possible with GEL then hopefully there is an answer to my question #2 above so that I can figure out how to modify my data breakpoint correctly to this effect!

The DSS documentation is lacking. Actually the documentation in CCSv4 in general is lacking. It is something we will address in v5. But right now it is tough.

Joshua Lawes said:

4. Finally, I see that it is possible with the Built-In GEL Functions to associate input or output files "for use" with breakpoints at a specified address (e.g. GEL_AddInputFile, GEL_AddOutputFile). What I can't see is any other functions related to interaction between the breakpoint and the file. Is there anywhere to obtain more information on this functionality? I ask mainly because if the response to question #3 above is positive, I could perhaps record to file all the values , giving me the equivalent of a trace analysis (please correct me if I'm wrong!).

Those GEL calls are for File I/O. You can set this up with DSS with the breakpoint properties API. Again it is just an advanced breakpoint where the action that occurs when you hit the breakpoint is to read data from the target and write to a file on the PC or vice versa. But this is intrusive and I believe you are looking for non-intrusive options.

ki

Ki-Soo Lee said:

There is not any good documentation on how to do this (oh how I wish there was). I'll try and put together an example for you.

Ok Ki, thanks.  Looking forward to whatever you can provide!

Concerning the GEL_AddOutputFile() functionality, I accept that this would be an intrusive technique however I thought I'd try it out just to get something working initially, however I am finding errors.

I tried: 

var outputFile            = "[someFilePath...]";

var myDataAddress         = debugSession.symbol.getAddress("myDataSymbol");
var myDataAddressStr      = "0x" + Long.toHexString(myAddress);

var myProgramAddress      = debugSession.symbol.getAddress("myProgramSymbol");

// GEL_AddOutputFile(programAddr, "connectFileName", Format, "dataAddr" [, "length"] [, page] [, "condition"])
debugSession.expression.evaluate('GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr);');.

Yet I'm receiving the following the following error in the terminal:

evaluate: ENTRY sExpression: GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr);
eval: Requesting evaluation of expression: "GEL_AddOutputFile(myProgramAddress, outputFile, 2, myAddressStr);"
waitUntil: ENTRY flag: GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr); timeout: 10000 (ms)
onEvent: Evaluated expression: GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr);
waitUntil: RETURN true
SEVERE: Evaluation of expression: "GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr);" failed. identifier not found: myProgramAddress

Is GEL able to recognise parameters I have defined in javascript or is this another case where I will need to figure it out using the DSS method to add the breakpoint?

Ok thanks again for your time and assistance!

--

Joshua

Ok, so now I have managed to get something working using only DSS (thanks to the createProperties() function to output the different types of breakpoints available and then the printProperties() function to output the various properties available, along with their possible values) as follows:

var outputFile            = "myOutputFile.dat";

// Set breakpoint at program address for myProgramSymbol()
var bpProperties = debugSession.breakpoint.createProperties(1);
bpProperties.setString("Hardware Configuration.Type.Trigger 0", "Memory Address Bus");
bpProperties.setString("Hardware Configuration.Type.Trigger 0.Location", "myProgramSymbol");
bpProperties.setString("Debugger Response.Action", "Write Data to File");
bpProperties.setString("Debugger Response.Action.File", outputFile);
bpProperties.setString("Debugger Response.Action.Format", "Hex");
bpProperties.setString("Debugger Response.Action.Start Address", "myDataSymbol");
bpProperties.setString("Debugger Response.Action.Length", "0x1");
// Print all the current properties for this breakpoint type for verification
bpProperties.printProperties();
var bp = debugSession.breakpoint.add(bpProperties);

The only real problem with this is that as the debugger writes to file instead of remaining halted, the debugger appears to crash due to the timeout (although I have the data I was after in the output file).

waitUntil: RETURN true
run: Target is running, waiting for a halt
waitUntil: ENTRY flag: onHalt timeout: 20000 (ms)
waitUntil: RETURN false
SEVERE: Target run timed-out after 10000ms waiting for target halt org.mozilla.javascript.WrappedException: Wrapped com.ti.ccstudio.scripting.environment.ScriptingException: Target run timed-out after 10000ms waiting for target halt (X:\myScript.js#102)

So now I was just wondering if there is a way to prevent this?  Is the best way just to catch any error that occurs from my debugSession.target.run() after adding the breakpoint or perhaps adding an extra breakpoint simply to return control to the debugger on a certain condition or this there some way more clean and efficient?

Thanks,

--

Joshua

Just as an additional query, I don't appear to be able to set the breakpoint on simple reading or writing of data, only the following:

Instruction fetch, Instruction fetch & hold trigger, No instruction fetch, Don't care

How do I stop on read/write of data??

Thanks,

--

Joshua

Joshua Lawes said:

Ok Ki, thanks.  Looking forward to whatever you can provide!

Sorry on dragging my heels on this. I hope to get something up soon.

Joshua Lawes said:

Is GEL able to recognise parameters I have defined in javascript or is this another case where I will need to figure it out using the DSS method to add the breakpoint?

Yes, but the way you are making the call will not work. This will fail:

Joshua Lawes said:

debugSession.expression.evaluate('GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr);');

because you are passing in myProgramAddress as string to expression.evaluate. This entire line is one big string.

'GEL_AddOutputFile(myProgramAddress, outputFile, 2, myDataAddressStr);'

To have myProgramAddres, outputFile and myDataAddressStr  first evaluated, you need to do something like:

debugSession.expression.evaluate('GEL_AddOutputFile(' + myProgramAddress + ',' + outputFile + ', 2,' + myDataAddressStr ');');

Thanks

ki

Joshua Lawes said:

The only real problem with this is that as the debugger writes to file instead of remaining halted, the debugger appears to crash due to the timeout (although I have the data I was after in the output file).

 

---

waitUntil: RETURN true
run: Target is running, waiting for a halt
waitUntil: ENTRY flag: onHalt timeout: 20000 (ms)
waitUntil: RETURN false
SEVERE: Target run timed-out after 10000ms waiting for target halt org.mozilla.javascript.WrappedException: Wrapped com.ti.ccstudio.scripting.environment.ScriptingException: Target run timed-out after 10000ms waiting for target halt (X:\myScript.js#102)

---

 

So now I was just wondering if there is a way to prevent this?  Is the best way just to catch any error that occurs from my debugSession.target.run() after adding the breakpoint or perhaps adding an extra breakpoint simply to return control to the debugger on a certain condition or this there some way more clean and efficient?

You can do one of the following:

-increase the timeout value using the setScriptTimeout() API

-try catching and handling the exception

-add an extra breakpoint in the same location which simply halts the target

I think any of the three is fine and it is up to you on which you prefer.

Thanks

ki

Hi Ki,

Thanks again for your thorough response.

My results from previously trying each of the above suggestions are as follows:

Ki-Soo Lee said:

-increase the timeout value using the setScriptTimeout() API

My issue with this approach is that whatever the value of the timeout, the script will still not be in control and I will end up with a system (rather than test) failure in my results which isn't ideal for qualification.

Ki-Soo Lee said:

-try catching and handling the exception

This indeed seems like the most practical option after all, however I don't want to risk catching a different exception by coincidence.  I need to be sure that the exception is due to the script timeout.  Just to confirm, this could be done as follows (is that the correct reference for the timeout exception)?

(assuming try block above)

catch (e) {

    if (e == Error.TIMEOUT) {

        [... exit/continue test safely with no error reported ...]

    }

}

Ki-Soo Lee said:

-add an extra breakpoint in the same location which simply halts the target

My issue here is that (whether it's supposed to be like that or not) on my target (MSP430F249), I am only able to set hardware breakpoints and am limited to two so that definitely limits my capabilities during the test.  For example if I want to write the values of two different parameters to file, then both breakpoints are used with no additional available to halt the processor (or is it possible to write values of multiple parameters to file with the one command - if not, then perhaps an extension idea)?

Do you think it might be in the scope for TI to add a duration (time or number of cycles) for the write to file to continue before returning control to the script without any failures?  I realise that even in a positive case, that this would be a future development and not useful for my present situation however it does seem like it might be useful.

By the way, did you see my post above concerning Instruction fetch, Instruction fetch & hold trigger, No instruction fetch, Don't care?  If you could just point me to a concise reference, that would be sufficient.

Thanks!

--

Joshua