Please note this thread is a continuation from http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/90061/312459.aspx#312459
PLEASE see the link above for the beginning of the story!
I am now trying the following, but with no success:
- From Tera Term connected to DM6467 EVM serial port, run my application, derived from canny edge detect, derived from encodedecode demo.
- Application has a getchar() before spinning off video/capture/display threads, so I hit enter to get past this.
- Application has a second getchar() just after Engine_open() call, per instructions at http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_CE_application_using_CCS#Algorithm_Debugging
- Note that if I hit enter for second getchar() now, having done nothing with CCS, the application and codec run and I see video on my monitor. However, for this discussion I do NOT hit enter yet. Instead, I continue with the steps below.
- From CCSv4.1.1.00014 on WIndowsXP(MachineB), provide same workspace as I used for building codec (but not server, built on Ubuntu/VMware/WindowsXP(MachineA).
- Locate View / Target Configurations / User Defined / Helmut1080PEVM.ccxml, where this ccxml was ignorantly made in the past by me from scratch and was used successfully to flash nand with UBL and U-Boot.
- Right click on Helmut1080PEVM.ccxml and select Launch Selected Configuration.
- I get a whole tree of things in the Debug window. I notice FOUR at the top level. I guess these should be called "Sessions".
- Spectrum Digital XDS510USB Emulator_0/ARM926 [Non-project Debug Session]
- Spectrum Digital XDS510USB Emulator_0/C64XP [Non-project Debug Session]
- Spectrum Digital XDS510USB Emulator_0/ARM926_0 [Non-project Debug Session]
- Spectrum Digital XDS510USB Emulator_0/ARM926_1 [Non-project Debug Session]
- Recognizing "C64XP" on the second of four at top level, I right click and Connect Target
- Next I select Target / Load Symbols.
- I'm asked for a Program file. I browse to my .x64P file. (Note my codec .a64P is created by CCSv4 on WindowsXP(MachineB). That gets copied to Ubuntu/VMware/WindowsXP(MachineA), where I build a codec server that ends in .x64P. I can't access the virtual Ubuntu disk from MachineB, but my makefile does always automatically copy all the pertinent Ubuntu files to a place on MachineA where backup software can save it. So, I can point there from MachineB. Therefore, I browse and point CCS at mycodecserver.x64P.
- I'm also asked for Code offset and Data offset. I have no clue what these are, so I leave them blank.
- After eclipse slowpokiness, I get "C64XP: GEL Output: Startup Complete.
- NOTE at this point, the C64XP session is NOT running. I did not stop it. It came that way. I have an enabled Target / Run option. The program pointer seems to be a value different each time I do this test. See images below for details.
- I select Target / Run per the instructions, and my C64XP session seems to be running.
- I finally press enter on the terminal session, to let the application continue.
- I get one more debug output on the terminal, from the same video thread with the getchar, but then nothing else. My video monitor remains black. It's not working like it did when I never tried to insert CCS.
I have doubt that my symbols are correct. Note I didn't set a breakpoint. I just want to see the sucker run like it did without CCS. Can I totally leave OUT the whole symbol stuff? If so, this would reduce the complexity of what I'm trying to establish.
Below is my debug window immediately after connecting. Note enable green "Play" (Run) button. Note "Suspended" C64XP session with program pointer 0x8faa616c.

Below is the disassembly window. It seems the DSP is paused half way through the setup for a subroutine. So it's not paused on any kind of wait, I don't think. Did CCS just pause it in its tracks? MORE IMPORTANTLY, does the assy seem to match the source? I've done lots of mixed assy/source debugging on other processors, but I'm not yet familiar with this compiler or highly parallel instruction set. So I really don't know if the source (symbols) match the code (disassembly). I suspect they don't. This does get back to my question, can I leave out the symbols altogether for the moment? I think my problem is elsewhere.

Next time, I get this disassembly window, with a different program pointer. It's "not working for me" (aka I doubt symbols). I really want to leave out the symbols step. Then, why won't my program run after I tell the paused DSP to run as well as hit enter for the ARM app waiting on the getchar()?
