How to debug codec code on DM6467T EVM

Instructions for debugging code code exist at http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_CE_application_using_CCS#Algorithm_Debugging .

However, I find these instructions obsolete and incorrect.  I'm using CCS version 4.1.1.00014 and a DM6467T EVM, with a Spectrum Digital XDS510USB connected to the EVM's jtag header.  Here's what worked for me, all done from CCS.  Note that you do NOT need to put a getchar() pause in your application, as those obsolete and incorrect instructions advise.

1. Load CCS with the same workspace as you used for building your codec.
2. If you haven't done this already, create a target configuration as follows.  You only need to do this step once.
   1. Select menu option Target / New Target Configuration
   2. Give it a name of your choosing
   3. I de-selected "Use shared location", then browsed to my codec project.
   4. Click Finish
   5. A new window will pop up somewhere, with a tab matching the name you chose, plus text in the window "Basic" and "General Setup".
      1. For "Connection", I chose Spectrum Digital XDS510USB Emulator
      2. For "Device" I found EVMDM6467
      3. Click on "Save".  You may have to scroll right to see this button.
      4. Note that it's not obvious how to return to this window to edit anything.  Do this through the CCS menu View / Target Configurations.  Then double click on the target configuration you want to edit.  (The right click context menu does not have an edit option.)
3. Launch your target configuration (right click on config, select "Launch...").  It's a little easier if this configuration is associated with your codec project.
   1. In the debug window, you'll get four "Non-Project Debug Session" nodes at the highest level of a multi-level tree:
      1. Spectrum Digital XDS510USB Emulator_0/ARM926 [Non-Project Debug Session]
      2. Spectrum Digital XDS510USB Emulator_0/C64XP [Non-Project Debug Session]
      3. Spectrum Digital XDS510USB Emulator_0/ARM926_0 [Non-Project Debug Session]
      4. Spectrum Digital XDS510USB Emulator_0/ARM926_1 [Non-Project Debug Session]
   2. Note the second node (3.a.B) includes "C64XP" and refers to the DSP.  The first node (3.a.A) includes "ARM926" and refers to the ARM.  I'm not sure what the last two nodes are, if anything real.  These nodes have "ARM926_0" and "ARM926_1" text.  Later in these instructions, when I refer to "ARM926", I mean the first node (3.a.A) and not either of the last two nodes that also have "_0" and "_1".
   3. Note also that beneath each session node is a thread node.  They should all have a status note of "(Disconnected(Unknown))".
4. VERY IMPORTANT: You must connect to BOTH 2.a and 2.b.  
   1. Connect to the "ARM926" node first by right clicking on it in the debug window and selecting "Connect Target".  After doing this, the thread status note for this node changes to "(Suspended)".  At this point, you won't be able to type Linux commands in your terminal windows (that's a 115200:8:N:1 connection to the EVM's serial port).
   2. Connect to the "C64XP" node next by right clicking on it in the debug window and selecting "Connect Target".  After doing this, the thread status node for this node changes to "(Suspended)".
   3. Now both ARM and DSP are suspended.
   4. From this point forward, the thread status will give you live updates of the ARM and DSP status, with only a slight delay.
5. Allow the ARM to run again by clicking on the ARM926 node's "Thread" sub node, and the clicking on the green "Play" triangle in the toolbar or by selecting menu option Target / Run, or by pressing F8.
   1. You'll notice that this causes the ARM to reboot.  You'll see the boot log on your terminal.
   2. If the demo is running automatically, press PLAY on the IR remote to get past the remote help window, then POWER on the remote to end the demo menu.  If you forget this step, things will get all jammed up later, so tape the remote to your forehead or something!
   3. At this point, note that the ARM thread is "(Running)" and the DSP thread is "(In Reset)".  This is exactly as expected.
   4. NOTE: If you get jammed up somehow, it's OK to press the reset button on the EVM.  The ARM thread status will reflect this, and then go "(Suspended)", from where you run it and then watch the boot log on your terminal.
6. You only have a limited amount of time to do the next steps, so read them all before you start...  (Add a link here to that debug delay setting I found somewhere)
   1. Prepare and then run your application.  This could be one of the demos that come with the EVM.
   2. The DSP thread was "(In Reset)", but MIGHT change to "(Suspended)".  In this case, you only have a limited time to get it running again...
      1. Run the DSP thread by right clicking on the Thread node beneath the C64XP node, then click green PLAY toolbar button, or select Target / Run, or hit F8.
   3. You should now have both the ARM and DSP running.  If a trace log is active, you should see that on the terminal.  You should see your video output, too.
   4. You can pause the DSP and then let it run again by using the appropriate toolbar buttons, menu commands, or F keys.  When paused, the terminal trace will pause and the video will freeze, of course.  Then you can delight in letting them run again.  You're over the hump!
7. Your application and codec are running now, and so NOW is the appropriate time to load symbols.  This must be done even if you started with your codec project.  (This is at least the case for me.  My codec is built under this CCS project on Windows XP, but my codec server is built elsewhere under Ubuntu (Linux), where I'm providing my network file system (NFS) to the EVM.)
   1. Select CCS menu option Target / Load Symbols.
   2. Browse to the .x64P file of your built CODEC SERVER, not the .a64P file of your built codec.  This is the same executable as you had to provide the EVM file system in the same folder as your application.
   3. I find that I can leave "Code offset" and "Data offset" blank.
   4. Click OK.
   5. Previously, you may have had a "Disassembly" window visible, with green assembly code.  Now it will have bold blue source code interspersed within it.
8. Set a breakpoint
   1. Only now does the convenience arise from having the target configuration associated with your project.
   2. PAUSE the DSP thread first!  I click the yellow tape-recorder-like pause button on the toolbar.
   3. Double click on a codec source file in order to view the source.
   4. Find a source code line and set your breakpoint.  (Right click on line, Toggle Breakpoint)
9. Run your codec code
   1. RESUME the DSP thread.  I click the green tape-recorder-like play button on the toolbar.
   2. If your breakpoint is appropriately positioned, DSP execution you'll soon come to the breakpoint and stop.  Thread status becomes "(Suspended)".
   3. If you have a Local or Watch window visible in CCS, you'll now be able to see variable values, too!  (Get these windows with View menu options).
   4. I find it entertaining to set my breakpoint to occur once per frame (at the top of the codec process function when not doing slicing).  I then modify my video input scene (I have a long broom handle that reaches over to my electronics bench, so I can move the broom and change what the camera sees).  Then run past the breakpoint several times, counting how many times it takes for the scene change to appear on my monitor.  This is my video throughput latency in number of frames.  It probably corresponds to my capture and display number of buffers, too.  I haven't looked into that yet and probably never will.
10. Do your business.
11. You can modify your code or application and try again as follows...
    1. You do this while KEEPING CCS connected to your target system.  This saves a bunch of setup trouble.
    2. Pause the DSP, then remove or disable your breakpoints.
    3. Resume the DSP thread (RUN it).  Your application and code should be running again.
    4. Do that thing to stop your application.  Perhaps you press STOP on the remote control.  Perhaps you type control-C into your terminal windows.
    5. Make your mods and rebuild and whatever else you need to do.
    6. Run your application again.
    7. Now you're back at a place where you can pause the DSP, enable or add new breakpoints, and debug your code again.
12. To gracefully exit your debugging altogether...
    1. Pause the DSP, then remove or disable your breakpoints.
    2. [EDIT] Next, just click red toolbar buttton to "terminate all".  SKIP REMAINING STEPS HERE.  You'll be left with working ARM and DSP.
    3. Resume the DSP thread (RUN it).  Your application and code should be running again.  If you leave it running, you'll see confirmation of what your graceful exit.
    4. Disconnect from the C64XP session (right click on that node and select Disconnect Target).
    5. At this point, my C64XP session (the DSP) gets suspended.  I don't have to make it run again, and I believe I may have only a limited time for the next step.
    6. Disconnect from the ARM926 session (right click on that node and select Disconnect Target). 
    7. At this point, my application is running again, including trace log to my terminal and video output of my waving broom.  The ARM926 session shows the ARM is "(Disconnected(Running))".  However, it the C64XP thread says the DSP is "(Disconnected(Suspended))" while in fact I know it's running.  When I gracefully stop and restart my application using the IR remote and terminal input to Linux, this doesn't correct itself.  So maybe my exit isn't as graceful as I thought.
    8. Note you can't get back "in" without restarting the ARM, because connecting to the ARM target leads to such restart.