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.
Customer set cpu2 to go to main after reset but it doesn’t work (for cpu1 it works)
When they set script: Scripts->EMU Boot mode select->EMU_BOOT_FLASH then it works for cpu2 too but after re-loading program to cpu again it stopped to work.
How can they solve this out?
Restart option work correctly but only from ccs level.
Normally they are using javascript to run some scripts: reset works correctly, restart does not work it just stopped.
Hi Lawrence,
Please refer to section 4.7 of the F2837xD Technical Reference Manual for more details about the answer below.
When the customer uses the EMU_BOOT_FLASH script, the value at address 0xD00 is changed to the BMODE value that will cause the device to boot to flash during the emulation boot flow. I think that this section is getting reset when you restart the device. As this TRM section mentions, there is a location in the OTP that the user could use to permanently set the boot mode for this device. Please let me know if you would need help with this.
Best Regards,
Ben Collier
Hi,
Let's skip the issue refers to Scripts->EMU Boot mode select for a moment.
More important thisg is why Cpu2 doesn't go to main? Auto run options has two options selected -> Run to symbol main -> on a program load or restart and on a reset.
Both option are set but cpu2 go to main only during restart , not reset.
Hi Sebastian,
Ok, I have replicated what you are seeing. Please allow me to discuss this with another expert, and I will get back to you soon.
Best Regards,
Ben Collier
Hi Ben,
The alternate way to solve that issue is to run restart function in JavaScript.
The thing is that:
Function restart works correctly in sequence like this:
debugSession_2 = debugServer.openSession("*", "C28xx_CPU2");
debugSession_2.target.connect();
debugSession_2.memory.loadProgram( programToLoad_2 );
debugSession_2.target.restart(); -> Restart is done properly.
debugSession_2.target.runAsynch();
Function restart does not work correctly in sequence like this:
debugSession_2 = debugServer.openSession("*", "C28xx_CPU2");
debugSession_2.target.connect();
debugSession_2.target.runAsynch();
debugSession_2.target.reset();
debugSession_2.target.restart() -> Program stuck here.
Hi Sebastian,
Thank you for the additional information. The expert that I want to talk to about this has been busy all day today, so I will hopefully get back to you with an answer tomorrow.
Best Regards,
Ben Collier
// Import the DSS packages importPackage(Packages.com.ti.debug.engine.scripting) importPackage(Packages.com.ti.ccstudio.scripting.environment) importPackage(Packages.java.lang) // Arguments sent to java script var deviceCCXMLFile = arguments[0]; var logFilePath = arguments[1]; // Create scripting environment object var script = ScriptingEnvironment.instance(); // Log script.traceBegin(logFilePath,"c:/ti/ccs1031/ccs/ccs_base/scripting/examples/DebugServerExamples/DefaultStylesheet.xsl"); script.traceSetConsoleLevel(TraceLevel.INFO); script.traceSetFileLevel(TraceLevel.ALL); // Create a debug server var debugServer = script.getServer( "DebugServer.1" ); // Set the device ccxml debugServer.setConfig( deviceCCXMLFile ); // Open debug session script.traceWrite("[Msg] Open debug session-2..."); debugSession_1 = debugServer.openSession("*", "C28xx_CPU1"); debugSession_2 = debugServer.openSession("*", "C28xx_CPU2"); script.traceWrite("[Msg] Done"); // Connect to target script.traceWrite("[Msg] Connect to target..."); debugSession_1.target.connect(); debugSession_2.target.connect(); script.traceWrite("[Msg] Done"); // Reset target script.traceWrite("[Msg] Reset Cpu..."); // debugSession_1.target.reset(); debugSession_2.target.reset(); debugSession_2.target.restart(); script.traceWrite("[Msg] Done"); // Run target script.traceWrite("[Msg] Run target..."); // debugSession_1.target.runAsynch(); debugSession_2.target.runAsynch(); script.traceWrite("[Msg] Done"); // Disconnect debugger from target script.traceWrite("[Msg] Disconnect debugger from target...") debugSession_1.target.disconnect(); debugSession_2.target.disconnect(); script.traceWrite("[Msg] Done"); // Terminate debug session script.traceWrite("[Msg] Terminate debug session..."); debugSession_1.terminate(); debugSession_2.terminate(); script.traceWrite("[Msg] Done"); // Stop debug server script.traceWrite("[Msg] Stop debug server..."); debugServer.stop(); script.traceWrite("[Msg] Done"); script.traceEnd();
Hi Sebastian,
The problem is being caused by the value at the 0xD00 register for CPU2. After a power reset, the value is always loaded as 0x****025A. With this value, CPU2 will always boot in wait boot mode, where it will stay in idle waiting for CPU1 to release it.
When you load a program or use the restart button, the JTAG debug probe will just jump to the location of main on CPU1 or CPU2 since it knows where the program starts.
When you reset the device, it will go back to boot ROM. For CPU1, the value at 0xD00 is determined by the boot-mode pins, and this will be set on power-up. When you software reset the device, it will boot accordingly for the value set in the last 2 bytes at 0xD00. The options are shown below.
If CPU1 has been set to boot from flash (0x****0B5A), then it will boot to flash and go to main, if your program is stored in flash. If CPU1 is set to get boot mode (0x****035A), then it will read a location in the OTP to determine the boot-mode. By default, this location in the OTP is set to all 0xF, which boots to flash.
Since CPU2 will always have 0x****025A programmed at 0xD00 after a power reset, it will always wait for CPU1 to release it, unless you reprogram the value at 0xD00, which the EMU_BOOT_FLASH script does.
One other workaround that you could use would be to put a line in your cpu1 c code that tells CPU1 to pull CPU2 out of reset like shown below.
CPU1 will get stuck at this line until it pulls CPU2 out of reset. So after both CPU1 and CPU2 jump to main, you would need to reset CPU2 (which puts it in wait boot), then you could run CPU1 and CPU2 programs.
Please let me know if you need further clarification on any of this.
Best Regards,
Ben Collier