• Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 324 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Plans for Syslink/IPC and Code Composer?

Lee Holeva
Genius 4615 points

Apparently I have been pushing the envelope of TI's software.  To do serious development of DSP software, in my opinion, Code Composer is essential.  As delivered the EZSDK is restricted to command-line development in Linux and while this is fine for the ARM, the lack of a DSP debugger places severe limitations on DSP development.  At present Syslink is delivered without a complete rtos library package, while fine for the linux development environment presents some problems for Code Composer.  Compared to IPC, the Syslink documentation is also in a poor state.  What are the plans for extending the Syslink/IPC development environment to Code Composer? 

Lee Holeva

 

  • TI__Genius 17205 points

    I agree that CCS is essential for debugging.  I think the challenge you're having is that we haven't yet made it easy (possible?) to build within CCS using what is called a "managed make" project.  You should be able to build via "standard make" project - which simply launches a cmd line makefile build in the background the GUI.

    You certainly can build everything on Linux, including the DSP image, and _debug_ that built image with CCS on Windows.  That's the way most SysLink users work.  They let SysLink load the DSP, then connect to the DSP with CCS on Windows, "Load Symbols", set breakpoints and debug.

    I completely agree that we should provide guidance on how to build in CCS.  IMHO, and many disagree with me, I think CCS/Eclipse is a much nicer _debug_ engine than it is a _build_ engine.  Especially for multicore environments, where SysLink applies, CCS continues to be challenged with things like sharing memory maps and other resources between projects... and it's especially challenging when one/some of those cores are running an HLOS like Linux.  This is why the EZSDK - and many products that feed into it - tend to build everything outside of CCS, at the command line (typically from Linux).  But that doesn't disable the ability to debug on Windows using CCS.

    Chris

  • in reply to Chris Ring
    Genius 4615 points

    I would be satisfied if I could get the debug of a remotely made DSP program in Code Compose to fully function.  By removing the GEL file I have successively gotten CCs to connect, halt, and run the code as it is in both the ARM and the DSP.  The problem is that "load symbols" is not loading any of the symbols of my program.  I cannot set breakpoints or watch variables.  It would help greatly if someone at TI would figure this out.  There are two issues:

     

    1. Proper config.bld, package.bld, and package.xdc files for xdc to use in Linux so that symbols are generated

    2.  the setup of Code Composer for non-project debug

     

    Lee Holeva