Power On Reset from JTAG/DSS

Hi,

At first glance I can't see anything wrong with the code you are using. Just for your reference, that is what I use to figure out the different types of resets of a target/debug session:

var numResets = debugSession.target.getNumResetTypes();
if (scriptDebug) { script.traceWrite("Number of resets: " + numResets + "\n") };

for (count = 0; count < numResets; count++)
{
	var reset0 = debugSession.target.getResetType(count);
	if (scriptDebug) { script.traceWrite("Reset name: " + reset0.getName() + ". " + reset0.getDescription() + "\n") };
	if ( reset0.isAllowed() ) { reset0.issueReset(); }
}

Timon Zijnge said:

What is the difference between resetType.issueReset() and debugSession.target.reset()?

The difference is the second routine issues the default reset, while the first allows you to specify which of the different types of resets available on the target can be issued. I tend to prefer the first as I get more control over what I am doing.

Timon Zijnge said:

My target configuration file (.ccxml) has options for reset modes that I don't understand and have not been able to find information about. They are related to the EMU0 and EMU1 pins on the JTAG header. What are these options and how do I use them? Do I need to configure these options in order to do a Power On Reset via JTAG?

These options are dependent on the target device and a complete reference can be found on the device's TRM. They cause the Debug Probe to set/reset the EMU pins which can be sampled during a power up or device reset and are usually designed to configure the JTAG operation modes (scan chain, debug, etc.).. Check section 2.4.1 of the page below:

processors.wiki.ti.com/.../XDS_Target_Connection_Guide 

The System Reset usually asserts the nReset pin on the JTAG connector - check section 2.2 of the page above. I think the XDS100v2 is capable of issuing a System Reset without problems. 

Hope this helps,

Rafael

Hello,

Timon Zijnge said:

What is the difference between resetType.issueReset() and debugSession.target.reset()?

target.reset will use the default reset type for the device and debug probe. This is usually a CPU Reset

resetType.issueReset allows you to specify other supported reset types (like System Reset).

Timon Zijnge said:

DSS manual says resetType.issueReset is executed asynchronously. How can I wait until the reset is done?

There is a GEL callback function called OnReset() which you can use to execute actions after a reset occurs. But that would require you to use both GEL and DSS together.

10 seconds should be plenty of time for the system reset to occur. Can you enable debug server logging and try again with your script? From the log, we should be able to confirm if the reset command was issued successfully. Zip  up the log and attach it to this thread:

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

Timon Zijnge said:

My target configuration file (.ccxml) has options for reset modes that I don't understand and have not been able to find information about. They are related to the EMU0 and EMU1 pins on the JTAG header. What are these options and how do I use them? Do I need to configure these options in order to do a Power On Reset via JTAG?

• JTAG nTRST Boot-Mode
• Power-On-Reset Boot-Mode

The JTAG nTRST Boot-Mode - — This defines level of EMU0/EMU1 pins on raising edge of nTRST pin. nTRST is driven high on beginning of debugging session to release JTAG from reset.

The Power-On-Reset Boot-Mode  -— This defines level of EMU0/EMU1 pins in the moment when target is powered-up (raising edge of PD pin on JTAG connector).

If you are using the same ccxml for both CCS and DSS sessions, I don't think these settings are the root cause.

Thanks

ki

Here is my log file and the version of LoadProgram.js that I used.

// Import the DSS packages into our namespace to save on typing
importPackage(Packages.com.ti.debug.engine.scripting)
importPackage(Packages.com.ti.ccstudio.scripting.environment)
importPackage(Packages.java.lang)

// Configurable Parameters
var deviceCCXMLFile = "InsituTargetConfiguration.ccxml";
var programToLoad = "NANDWriter_DSP.out";

// Create our scripting environment object - which is the main entry point into any script and
// the factory for creating other Scriptable ervers and Sessions
var script = ScriptingEnvironment.instance();

// Create a debug server
var ds = script.getServer( "DebugServer.1" );

// Set the device ccxml 
ds.setConfig( deviceCCXMLFile );

// Open a debug session
//debugSession = ds.openSession( "tixds100v2c674x.xml" );
var debugSession = ds.openSession( "Texas Instruments XDS100v2 USB Debug Probe_0/C674X_0" );

debugSession.target.connect();

// Load the program 
debugSession.memory.loadProgram( programToLoad );

// Run the program
debugSession.target.run();

debugSession.target.waitForHalt();

//var resetType = debugSession.target.getResetType(1);
//script.traceWrite("Reset name: " + resetType.getName() + ". " + resetType.getDescription() + "\n")
var numResets = debugSession.target.getNumResetTypes();
for (count = 0; count < numResets; count++)
{
    var resetType = debugSession.target.getResetType(count);
    
    if ( resetType.isAllowed() )
	{
		script.traceWrite("Reset name: " + resetType.getName() + ". " + resetType.getDescription() + "\n");
		resetType.issueReset();
		java.lang.Thread.sleep(10000);
	}
}
//java.lang.System.out.println(resetType.getDescription());
//java.lang.System.out.println(resetType.getName());
//resetType.issueReset();

//java.lang.System.out.println("Bla1");
//java.lang.Thread.sleep(10000);
//java.lang.System.out.println("Bla2");

//debugSession.target.reset();
//debugSession.target.restart();

debugSession.target.disconnect();

8836.dss.zip

Hope it helps

Hello Timon,

My apologies for the delay. I will request an emulator expert to reply to your questions regarding the details of the various resets.

Thanks

ki

"System Reset" in CCS is implemented by commanding the ICEPick router in the device to issue a reset to the cores it is connected to. This is a hardware reset but only resets the logic inside the device.  It does not reset anything else on the board.  The "System Reset" in CCS should be the same reset as calling "System Reset" in DSS.

TRSTn is not a power on reset, nor should it reset the device's CPU.  TRSTn only resets the debug logic within the device. Most boards are designed to assert TRSTn with a weak pull down while the debug probe is not connected to ensure the debug logic is held in reset during normal run.  If you're seeing a power on reset, then it's unlikely to be caused by TRSTn unless the probe's TRSTn pin is connected to the power on reset line on the board.  The pin that should control power on reset at the board level is the SRSTn pin of the debug header (but not available on the TI-14 pin header).

I have experimented a bit more, but still no results. The DSP is apparently reset correctly by issuing a 'system reset', both from CCS and DSS. I have verified this by looking at the RESETn pin of the DSP. In both cases, the RESETn line pulses active (low). During the entire procedure the TRSTn line remains high. However, after a 'system reset' from CCS the DSP starts running normally. After a 'system reset' from DSS the DSP seems to remain in emulation mode. I can then only get it to run normally by physically detaching the XDS100V2 or power-cycling the LCDK6748 board.