LOADING OF GLOBAL DATA DEFINITION

AC,

CCSv4 (and CCSv5), by default, are configured to load your application and then run to main.  (If you ever used CCSv3, this wasn't the default)  When you load your code, what actually happens is that the PC is set to the C Entry point (c_int00), and then a breakpoint is set at the main symbol.  CCS automatically runs to main and then removes the breakpoint.  The initialization of your global variables occurs in the code that executes between c_int00 and main.  

If you wish to change the behavior of CCS so that when you load code it remains at c_int00, you can do this in the debug preferences. 

Regards,
Dan

So if I have understood properly, when I load the code through CCSv4 (without altering the default debug properties) but not started running the code (through debug perspective of CCSv4) , at that time the PC points to main (that is what the dis-assembly window shows when enabled with source code view) and the initialization of all global data (before main) is over. Am I right?

Regards,

AC.

AC,

Your understanding is correct. Your wording is a bit imprecise, "not started running", but if you follow what Dan said about running to main() then you have an accurate understanding of the process.

You have another control over how initialization is done. Check out the --ram_model and --rom_model linker options in the Assembly Language Tools Reference Guide for your version of the tools. The default is --rom_model, and it is almost always the best choice.

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

Thanks Dan and Randy P  for your answers. Can anyone please tell me what device level operation actually takes place when we click on the 'Run' button in the CCSv4 debug window to run a code after loading it into the DSP(C6472)? As Dan has said about the breakpoint, my question is how the breakpoint from the symbol 'main' is removed and the code execution starts? Is it a JTAG related issue or it can be controlled from the DSP hardware? I have checked the BOOT_COMPLETE_STAT register. But BC0-BC5 are all 1 even if only core 0 is connected and loaded with code to check the register BOOT_COMPLETE_STAT. By the way I have configured no-boot mode in the EVM board(TMDXEVM6472). 

Regards,

AC.

AC,

I think you're asking two questions here.  I'll try to address them both.

- The 64x CPU essentially has an unadvertised HALT opcode.  When you set a breakpoint by clicking in the margin, or in this specific case, when CCS automatically sets a breakpoint at main, the actual opcode at the location where the break is set is removed, and then HALT opcode is inserted at that location. (Note:  You'll never see this opcode in the disassembly window or memory window.  CCS is smart enough to hide these from you and show the expected opcode)  The original opcode is stored in a breakpoint table associated with the address that it came from.  (More about this process continued below.)

- When you click ont he "RUN" button, the Emulator scans a "Run" command to the CPU.  Essentially, before that point your application is just stopped at main, and once you do the RUN, the CPU starts executing instructions from that location. At this point , CCS has not control over your application. It just periodically queries the CPU to see if it has been halted, but this has no effect on your application.  There's a completely separate hardware block on the device that does this, no CPU intervention is needed.

(Now back to handling breakpoints)

So, in the case of your application, we loaded the code, set the PC to c_int00, and then set a breakpoint at main.  CCS then issues the RUN command automatically because of the setting to automatically run to main.  So, it begins executing code and then periodically polls to see if the CPU is halted.  When the CPU hits the breakpoint, it halts and waits.  The next time CCS polls the target to see if it's halted, it sees that it is.  So, it then removes the breakpoint opcode and replaces it with the original instruction opcode at that location.  CCS then updates the open  disassembly, watch, memory, etc windows to the current values, and you see it with the PC pointing at main.  The only other additional magic that happens is when you run or step from the location of the breakpoint.  When it does a subsequent step or run, it will automatically flush the CPU pipeline and then re-fetch starting with the instruction at Main so that all of the correct instructions get executed.

I hope this information helps.

As far as the BOOT_COMPLETE_STAT register goes, I'd have to look into the specifics of this register, but I suspect that when no boot mode is configured, these are all set to 1 by default, as you are not actually booting

Regards,

Dan

Thanks Dan for your excellent informative answers. Does it mean that if I want to start the execution of codes in other cores (core-1 to core-5 in C6472) without giving a synchronized start command from CCSv4, rather by issuing some command/instruction from the code in core-0 (like a master and only core-0 will be given start command from CCS by Run button) in 'No Boot' mode that is not possible? If possible then what is that way? The document SPRS612C says (in sections 2.4.1 and 2.4.2) "Any active core can set bits in BOOT_COMPLETE_STAT at any time to begin code execution on inactive cores." But it says nothing like that while discussing 'No Boot' mode, whereas it mentions about this thing while discussing about the other boot modes.

Regards,

AC.