Difficulty debugging codec algorithm on DSP side

Hmmm....  Aside from the obvious problems with instructions being out-of-date vs the 4.1.1 release of CCS, is it possible that I have indeed figured out that (findings_list) 2.a is the correct way to go about it, but I'm being messed up by the fact that my application is MULTITHREADED?  

The application structure is derived from the canny edge detect example, which for the DM6467(T?) comes from the encodedecode demo.  In these, the video processing, capture, and display work is done by three separate threads.  By having the application wait on a getchar immediately after Engine_open(), I'm stopping ONLY the video thread.  The capture and display threads continue forward to, I infer, a Rendezvous_meet(envp->hRendezvousInit).  So these two threads move further down the path than the video thread.  Now, I don't think either calls the codec, but is it possible that these need to be stopped ealier as well?  (Generally speaking of thread synchronization, the rendezvous is evidently enough for general operation.  So it should be enough for inserting CCS control of the codec "under" the video thread.  After all, the video thread could for any other reason be very late to the rendezvous.  Nevertheless, one wonders if insertion of the CCS control adds additional synchronization requirements.)

-Helmut

Helmut,

There's a lot to dig in, therefore bear with me while I do some initial comments:

Helmut Forren said:

Please help me figure out how to do this.  The instructions above are obviously obsolete, and I'm probably doing things wrong as well.

Yes, the page was written for CCSv3.3. You may also ask for an update to this page or some additional highlights about the procedure in the Multimedia Codecs forum, as they have a much better understanding about Codec Engine.

Helmut Forren said:

   1. For doing instruction step #2, Debug->connect, I have no "Debug" command on the menu bar at the top of the window.  Instead, I see three possible paths to follow:
         1. View / Target Configurations / Projects / mycodecproject / DM6467T_TargetConfiguration.ccxml [Default]
         2. View / Target Configurations / User Defined / Helmut1080PEVM.ccxml

    * Note I tried to use a downloaded dm6467T_arm.gel and follow instructions at http://processors.wiki.ti.com/index.php/GEL, but my CCS does not have a Tools Gel files option.  (Note I think I created one on my own as a part of my NAND flashing.

I would use one of the two options in blue above, as they precisely determine which device you are launching - the Debug Active Project button does a multitude of steps automatically and can lead to problems in your case, as the code was already loaded to the DSP via Codec Engine.

I would not, however, use a GEL file. At the moment you connect to the DSP core, it is already initialized by the Codec Engine loader, and chances are the GEL script will disrupt this initialization.

Same thing applies if you are trying to connect to the ARM core: the x-loader/U-boot/linux already initialized the device.

Helmut Forren said:

I tried (findings_list) 2.a and found options under the Target menu.  So I followed up with...

   1. Target / Connect Target
   2. I get a whole tree of things in the Debug window.  I notice FOUR at the top level:
         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]
   3. It seems 2.b which mentions C64XP ought to be right, so select it and then go back up to the top for Target / Connect Target
   4. After eclipse slowpokiness, I get "C64XP: GEL Output: Startup Complete.
   5. NOTE at this point, I figure I've completed instructions 1 and 2.  The next instruction, 3, is to load symbols.  Since I used a target configuration associated with my project, I don't think I need this.  I move on to step 4 and set a breakpoint.
   6. Oooh!  unlike 2.b described below, I now have an enabled Target / Run (F8) option.  I try it.  I get one more debug output from the arm side on my Tera Term session, which seems appropriate.  But then nothing else happens on either the Tera Term session or within CCS.

 

Steps 1 through 4 above are correct, with the remark I mentioned before (do not use a GEL file).

In step 5 you should load symbols to the target by using the procedure you followed below. Loading symbols does not transfer data to the board but only makes CCSv4 aware of the correlation between the current execution address (PC) and the delimiters of each function that is used by your source code. From the debugger perspective it is just a bunch of binary code with no information whatsoever.

Step 6 shows that the GEL file disrupted the execution by reconfiguring the device.

Helmut Forren said:

   1. Target / Connect Target
   2. Target / Load Symbols
   3. 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.
   4. I'm also asked for Code offset and Data offset.  I have no clue what these are, so I leave them blank.
   5. AT THIS POINT, I'm hoping I've accomplished instruction step 1 through 3, so my next steps are 4 and 5, which are to set breakpoint and run the DSP.  However, it seems the DSP is already running.  The Target menu has Halt and Terminate All options, but the Run (F8, not F5) option is grayed out.  So I don't think I'm in the right "place" at the moment.
   6. When I try to set breakpoint anyway, there's already one set from previous attempts.  Yet I try to set it again, and get "Failed to load symbols from ... 'mycodecserver.x64'P on target 'Spectrum Digital XDS510USB Emulator_0/ARM968_1' with "Reason: Invalid file format".  So again, I don't think I'm in the right place.

That is the correct approach to load symbols to the DSP, as CCS does not know what the symbols are in the executable code loaded to the target (it is all binary code).

Step 4. I don’t know Codec Engine in details, but I would try your approach first (don’t input anything). If you still can’t properly locate the functions, then I would check the Codec Engine memory map settings and see what it is needed to be done. If the file .x64P does not carry absolute address information, the DSP and CCS will not be able to correlate the addresses and the functions. In any case, I would confirm that in the Multimedia codecs forum.

Step 5. This is expected (the page also says that), as the function Engine_Open() loads the .x64P executable to the DSP and starts its execution automatically. You can halt the DSP execution, load symbols, set the breakpoints and resume operation.

It seems from the information in red that you are trying to load the symbols to one of the ARM processors (ARM968). Make sure the C64XP core is selected when you try to load them.

Hope this helps,

Rafael

Rafael,

Thanks very much for your help.

I'll do more followup on the Multimedia codecs forum.

For now, some followup questions, please.  I've tried what you've suggested but still haven't gotten it working.  In order to SIMPLIFY the question, do you think I should be able to succeed WITHOUT SYMBOLS and set NO BREAKPOINTS?  All I want to do is confirm it runs whatsoever.  It will run fine, and I see appropriate video out, if I simply run the app and hit enter (twice, I have two getchars() at different places, so I can see on the output what's up, relating to multithreading).  But if I try to connect CCS before the last getchar(), in the appropriate place right after Engine_open(), then I get one more trace output (don't recall which thread), followed by NO terminal output and NO video output.

Again, I would think I could connect CCS but put in no breakpoints, therefore need no symbols.  By omitting the symbol step, I can test a more simple situation.

What do you think?

NOTE: Just continued thread over at http://e2e.ti.com/support/embedded/f/356/p/90189/312690.aspx#312690

Thanks again,

Helmut

Helmut,

Helmut Forren said:

For now, some followup questions, please.  I've tried what you've suggested but still haven't gotten it working.  In order to SIMPLIFY the question, do you think I should be able to succeed WITHOUT SYMBOLS and set NO BREAKPOINTS?  All I want to do is confirm it runs whatsoever.  It will run fine, and I see appropriate video out, if I simply run the app and hit enter (twice, I have two getchars() at different places, so I can see on the output what's up, relating to multithreading).  But if I try to connect CCS before the last getchar(), in the appropriate place right after Engine_open(), then I get one more trace output (don't recall which thread), followed by NO terminal output and NO video output.

Again, I would think I could connect CCS but put in no breakpoints, therefore need no symbols.  By omitting the symbol step, I can test a more simple situation.

What do you think?

 

At first glance I don't see a problem there. My guess is that, at the point the ARM application starts the DSP through Engine_Open(), it should have the input data ready to be processed by your algorithm. However you must keep in mind that, since you have two threads running, the fact the DSP is being connected causes a delay in the overall system functionality - I am thinking about race conditions or a conflict of resources between the two threads. I wish I knew more about the Codec Engine...

Another alternative is to try to load one of the simple examples instead of your complete application - this way you would be able to fool proof the debugging procedure.

I will try to think about other possible alternatives.

Helmut Forren said:

NOTE: Just continued thread over at http://e2e.ti.com/support/embedded/f/356/p/90189/312690.aspx#312690

Thanks for pointing the ongoing discussion.

Best regards,

Rafael

Helmut,

Thanks for reporting such complete instruction guide. These instructions will probably become an incredibly useful wiki page at http://processors.wiki.ti.com

Cheers,

Rafael