Play button grayed out

jamp said:

I have a project that compiles and loads in debugger mode, but the play button remains grayed out as if it automatically has begun running

By default, CCS will try to auto-run to main on a program load. This can be disabled in the debugger options ('Window->Preferences' then expand 'CCS->Debug->Debugger Options->Generic' and look under 'Auto Run Options').This will disable it at a global workspace level.

jamp said:

Since no error messages come up I don' t have any indication of what I should look for as a cause.  Does anyone have an idea of what I should investigate?

There are some suggestions in the Troubleshooting Guide. Also providing any error and crash dump files (*.dmp) are very useful.

Thanks

ki

I do want it to autorun to main(). I guess the problem then  is that it never gets to main which is why the play button stays gray. I show no recent  crash dump files in the location the troubleshooting guide gives. However, I used the Debug View program to capture the transfer to/from the emulator ( i think that's what it does) of one case where the program hangs and another time where it ran fine.  And yes the files diverge very quickly after only the 5th line.

First 10 lines of the debug view for the successful run starting on the Locking command are

00000173    6.78914213    [2056] 0x00000F50 3  FS I: Locking C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\targetdb.lock (count = 0)   
00000174    6.78918171    [2056] 0x00000F50 3  FS I: Incremented lock-count on C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\targetdb.lock (count = 1)   
00000175    6.78921413    [2056] 0x00000F50 3  SETUP I: Loading repository "C:\Program Files (x86)\Texas Instruments\ccsv4\common\targetdb\"   
00000176    6.79045534    [2056] 0x00000F50 3  SETUP I: Scrubbing database   
00000177    6.81032038    [2056] 0x00000F50 3  SETUP I: Loading file "C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\2851868337.cache"   
00000178    6.81095505    [2056] 0x00000F50 3  SETUP I: TARGETDB INTEGRITY: Begin Self-Tests   
00000179    6.81114912    [2056] 0x00000F50 3  SETUP I: TARGETDB INTEGRITY: Analyzing C:\Program Files (x86)\Texas Instruments\ccsv4\common\targetdb\drivers\TI_reg_ids\CS_DAP_0_regids.xml...   
00000180    6.81706524    [2056] 0x00000F50 3  SETUP I: TARGETDB INTEGRITY: OK   
00000181    6.81722689    [2056] 0x00000F50 3  SETUP I: TARGETDB INTEGRITY: Analyzing C:\Program Files (x86)\Texas Instruments\ccsv4\common\targetdb\drivers\TI_reg_ids\CS_DAP_PC_0_regids.xml...   
00000182    6.82027864    [2056] 0x00000F50 3  SETUP I: TARGETDB INTEGRITY: OK   

The following is the log file for the time it did not run. I ran the 2nd one actually first and then restarted CCS, reset the emulator and the DSP and then got the successful run.

00000000    0.00000000    [2152] 0x00000738 3  FS I: Locking C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\targetdb.lock (count = 0)   
00000001    0.00003986    [2152] 0x00000738 3  FS I: Incremented lock-count on C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\targetdb.lock (count = 1)   
00000002    0.00007350    [2152] 0x00000738 3  SETUP I: Loading repository "C:\Program Files (x86)\Texas Instruments\ccsv4\common\targetdb\"   
00000003    0.00069153    [2152] 0x00000738 3  SETUP I: Scrubbing database   
00000004    0.02161797    [2152] 0x00000738 3  SETUP I: Loading file "C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\2851868337.cache"   
00000005    0.02249783    [2152] 0x00000738 3  FS I: Decremented lock-count on C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\targetdb.lock (count = 0)   
00000006    0.02259876    [2152] 0x00000738 3  FS I: Unlocking C:\Users\JPETER~1\AppData\Local\.TI\3522574184\0\targetdb.lock (count = 0)   
00000007    0.02314474    [2152] 0x00000738 3  CT C: CCLoadLibrary( C:\Program Files (x86)\Texas Instruments\ccsv4\emulation\analysis\bin\ctools.dll )   
00000008    0.02324384    [2152] 0x00000738 3  CT R: CCLoadLibrary( C:\Program Files (x86)\Texas Instruments\ccsv4\emulation\analysis\bin\ctools.dll )   
00000009    0.02328663    [2152] 0x00000738 3  CT C: GetcToolsMgrIF( 0x289F5C38 )   
00000010    0.02332356    [2152] 0x00000738 3  CT R: GetcToolsMgrIF( *0x289F5C38 = 0x1C9CF4C8 )

Does this give any indication for why these two runs behaved differently?

In debug mode, what happens between loading the program through the emulator and the start of main()?  This is where the hang up occurs.  Can someone tell me the process?

When the program is loaded, it will go to the entry point of the program (_c_int00). Then it will try and set a breakpoint at the start of  the 'main' routine (if one exists) and then run the program. If there is a 'main' and the breakpoint is correctly set, it will halt at 'main'.

You should disable the auto-run to main option and start stepping until you see around what instruction is causing the issue. See the below thread (the post by JohnS) on how to disable the autorun option:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/75374/274142.aspx#274142

I've tried to single step twice now and both times it takes hundreds of steps  which darn near puts me to sleep.  Anyway, both times it has gotten fatal errors. Once it had trouble reading a memory location on a NOP instruction, and the other time it had a JTAG communication error.  I don't know if either had to do with holding down the F5 key too long--might have had something to do with the sleeping part.. Each step is painstakingly slow.They both died in different locations. There is a lot of looping from a memcpy routine to several others and back. I suppose it's loading the memory with the variables, etc. Are there some tips on how to step through this assembly or is it just by brute force that we must do this?  I don't think these errors have anything to do with my problem, since I don't get any errors, it just hangs and never gets to main when I run it.

Okay I put a break in the memcpy loop.  Instead I have run this loop hundreds of times without ever crashing.  The emulator must not have been able to handle too many single steps???  but with a breakpoint it doesn't have that problem. However, the code seems stuck in this loop and doesn't exit, but I have no idea what the loop is. These are the disassembly labels for each subroutine(?)

Starts with

C_int00:

GLB_USRINITFXN, ...

CSRL0:

_autoinit:

C$L1:

then loops the following:

_memcpy:

C$RL0:

C$RL5:

C$RL1:

then back to _memcpy, over and over.  Does anyone know what these are?

I think there might be a problem with my gel file. I have SDRAM on my board, but I can't change the data in the SDRAM memory (manually) so I think it's not getting initialized correctly.  There is a function in my gel file called Setup_EMIFB() with a comment that this function sets up the SDRAM.  Nevertheless I still can't manually change any SDRAM memory location. I have the gel file saved in the TargetConfiguration file within the project and I have only one gel file on my computer, so I think it's getting the one I want, just not doing what I want, which is to initialize my SDRAM. 

This solved my problem, Thanks ki
my problem is, I have multiple GEL files, 1. for device specific and 2. for test related
so when i build the test and loaded the .out after loading the 2 gel files, the program is directly running in a loop and behaving unusual. Posting this info as this may help others with same issue.

In CCS 3.3 the auto run can be disabled as follows,
Option -> Customize -> Debug Properties and then uncheck "Perform Go main automatically"

Hi,

            I too facing some times Failed to connect PRSC module (Error 6306). What is mean by 6306 error. Where we will find the information regarding the different types of errors and where we can the information about Failure errors. Can any one provide information regarding this.

Thanks,

Siva.