How to debug Syslink compatible code on the DSP of the c6a8168?

You could try loading symbols only from CCS. When you connect CCS via emulator, to DSP after loading DSP firmware, issue halt from CCSv5.

RV said:

You could try loading symbols only from CCS. When you connect CCS via emulator, to DSP after loading DSP firmware, issue halt from CCSv5.

A couple of problems:

1.  If I cannot build the code in CCS, only in EZSDK, how do I get the symbols, or the DSP executable, into CCS?

2.  There is a timing problem of the interaction between the ARM and the DSP.  I can connect the emulator to the ARM, halt it, and then gain access to the DSP, but the emulator will reset the DSP and I will have lost any the consequences of the ARM to DSP interaction, any stored data would be lost.  How do you deal with ProcMgr of Syslink, running on the ARM, which loads code into the DSP and starts it up?   Idealy, you would want to connect to both the ARM and the DSP simultaneously, but I do not know if that is possible.

Lee Holeva

Lee,

Lee Holeva said:

1.  If I cannot build the code in CCS, only in EZSDK, how do I get the symbols, or the DSP executable, into CCS?

You transfer the executable along with your application code to your Windows machine. The symbols can be loaded into CCS using "load symbols". After that you can do debugging equivalent to the way you would do if you had loaded the executable using CCS.

Lee Holeva said:

2.  There is a timing problem of the interaction between the ARM and the DSP.  I can connect the emulator to the ARM, halt it, and then gain access to the DSP, but the emulator will reset the DSP and I will have lost any the consequences of the ARM to DSP interaction, any stored data would be lost.  How do you deal with ProcMgr of Syslink, running on the ARM, which loads code into the DSP and starts it up?   Idealy, you would want to connect to both the ARM and the DSP simultaneously, but I do not know if that is possible.

 

There shouldn't be any problem. You can halt using CCS, start again and communication with the ARM will continue.

See here for any generic hints on how to debug in such scenarios ... http://e2e.ti.com/support/embedded/f/356/p/90292/313056.aspx#313056

Regards,
Mugdha

MugdhaK said:

There shouldn't be any problem. You can halt using CCS, start again and communication with the ARM will continue.

Well, there appears to be a problem.  Upon attempting to connect to the ARM Cortex-A8, I get this:

I'm using the latest GEL file from Spectrum Digital.  I put a getchar() after the ProcMgr startup code, load the DSP code image and start it up, I click on Yes, the ARM is halted, but the only way I can restart it is to disconnect.  I can connect to the DSP ok after the ARM is halted, load symbols, and get it running, but when I go to restart the ARM, the only way I can do this is to disconnect, and the ARM hangs.

This part has been fixed.  I removed the GEL file and the connection to the ARM now works as it should.  The last issue is that of breakpoints.  Though I build using xdc with -g, I do not appear to be getting all of my symbols.

Lee Holeva

Lee,

Sorry, I misunderstood. I thought you were trying to debug on the DSP only, and my instructions were for that. If you want to debug on the DSP only, you should not connect to the ARM Cortex A8 using CCS at all. Just connect to the DSP, load symbols, provide the source lookup paths, and start debugging (single step, breakpoints etc.) on the DSP. The ARM Cortex A8 should not even be connected to.

Are you trying to debug on the ARM Cortex A8 as well using CCS and hence trying to connect to it?

Regards,
Mugdha

MugdhaK said:

Are you trying to debug on the ARM Cortex A8 as well using CCS and hence trying to connect to it?

I'm attempting to debug a Syslink/Ipc App between the ARM and DSP, where there is a program running on the ARM that controls the DSP.  I'll removed the GEL files so that when I connect to both devices they only halt and not reset.  The problem is that in building the DSP code outside of Code Composer, using xdc in EZSDK, "Load Symbols" does not seem to work.  Now, I notice that in the new EZSDK, Syslink now has the rtos package prebuilt, so I may be able to build my DSP code in Code Composer.  I hope that this solves the load symbol issue.

Lee Holeva

Hi Lee,

Was wondering how you made out.  I'm currently headed down the same trail.  Have no problem building Syslink in CCSV5 and will be working on the Linux side shortly.  Given both sides are custom I'll need to debug both simultaneously.  Figure Linux will probably be easier to use gdbserver/Eclipse environment, with CCSV5 on the DSP side.  I've done DSPLink on the L138 that way and worked fine but in that case the DSP loads the application.  Currently attempting similar application on the DM3730 ported to Syslink.

Kev

Kevin Halloran said:

Have no problem building Syslink in CCSV5 and will be working on the Linux side shortly.

How are you building Syslink code in CCS5?  Perhaps you're referring to Ipc which is a different matter all-together.  The emulator support for the C6a8168 is currently broken in CCS5.0.2, so I have been using 4.2.3.

Kevin Halloran said:

Given both sides are custom I'll need to debug both simultaneously.

So far, I haven't had much luck with this.  "Load symbols" of DSP code made by xdc in the SDK doesn't really work.  I cannot set break points in my code.  What is needed is to be able to make your DSP code in CCS.  I had partial success by modifying the GEL file for the ARM by removing all of the setup code so that upon connection it only halts the ARM while keeping the scripts that turn-off the reset to the DSP.  After removing the reset, by use of the GEL script, you can then connect to the DSP, load a program, and start it running.  The necessary bit that I haven't got working is to disable the loading control of the DSP by the ProgMgr of Syslink.  It appears that the "NoLoad" options that are suppose to be available in Syslink 2_00_00_68 do not work.  I can see the DSP looping forever calling Ipc_start() and the host is no where to be seen.

For Linux-side code I have had good luck with gdb which is open-source.  It's the TI stuff that I'm banging my head on wall over.  I would love to know how the Syslink developers at TI are making and debugging their code.  In fact, it says in the Install Guide that Syslink development has been validated with CCS.

Lee Holeva

Thanks for the info.  With regards to building a Syslink app I am linking with Syslink.  I have not tested the code yet but it is a full Syslink application build.  I basically looked at their MessageQ project.  Created a project in CCSV5 (Windows 7), copied the MessageQ 'C' code into the project, built Syslink outside of CCSV5 so the libraries would be available, then created a custom cfg file by looking at what TI had in the MessageQ and common subdirectories of the Syslink samples.  Also added a reference to the Syslink folder under CSS Build/RTSC.  I used OMAP3530 since it is close to the DM3730 and the DSP is a C64+.  After a few headaches it builds fine.  Memory map file looks correct so should work (famous last words).

I started with CCSV4 but the Eclipse editor didn't work the best so figured give CCSV5 a try since it seems to be basically a shell around the same compiler/linker.  So far seems to work better in debugging generic DSP code via JTAG (no Syslink).  The cfg stuff is a headache because their automated tools for building it are horrible so you have to use the text editor, but you get use to it.

When I did this same thing on the OMAPL138 I had to create my own startup code on the DSP side to be able to JTAG properly, but OMAP has the ARM start first so is more difficult.  I have a large application I've ported to Syslink, before testing it I'll get MessageQ working (hopefully) and let you know how I make out.  If the source code for ProgMgr is available on the Linux side can probably hack it to do what is needed.  Would be nice if TI provided some simple sample code & docs in a real development environment, is tuff when you have to fight the tools to get your work done ;-)...

Kev

I'm also having Syslink debugging issues. TI need to produce a guide of how to debug both ARM and DSP sides of a Syslink application on the TI816x from start to finish. I've spent my time picking up scraps of information here and there but no single guide to show me how it fits together. If I had a pound for every non-Ti816x guide that I've found and tried to use for debugging the TI816x I'd be a rich man.

I've never had ARM and DSP working in synchrony in a debug environment (i.e. CCS). I can get a Sysbios application running fine on just the DSP and  can step through it. I can step through an ARM using GDB. But when I try to boot Linux, disable the MMU, bring up the C674x, connect to the C674x and load symbols then run the ARM side app I find that the ARM has frozen and refuses to allow me to type in the name of the application to run.

Ralph

Hi,

Sorry to hear that you have been having issues. The way I usually debug is to keep CCS open with the required target configuration loaded (which will be setup to only have the DSP since I don't need to debug on anything else using CCS). At this point, I've not connected to any core in CCS. Then I power-up the board, boot Linux, insmod syslink etc. run ProcMgr application using SysLink and when it says that the DSP has been loaded and started, I connect to the DSP in CCS. Then load symbols with the application executable that I have built (whole_program_debug or debug build will give you symbolic debug). I also set the source lookup path to the folders where I have my application, SysLink/IPC source code (if I want to debug within that too) and sometimes BIOS code too. After that, I can go ahead and set breakpoints, do single-step, watch etc. The ARM-side continues execution. If it was spinning waiting on something the DSP had to do (e.g. Ipc_attach), then it passes as soon as the DSP-side completes it. Further execution/debugging can be asynchronously done on both ARM (using prints or gdb or something else) & DSP (using CCS).

The DSP application executable is the same one that we build within SysLink build system. We did not have to build it in CCS for us to be able to use CCS to debug the DSP-side. We don't use a GEL file for DSP since all initialization has been done by the ARM-side. Using a GEL file might reset the state of the DSP, which would be undesirable.

I have not faced any issues with this type of debugging, so I'm not really sure what's the exact cause of the problems you're facing. Perhaps someone else who has seen similar issues and worked through them can help here ...

Regards,

Mugdha

One thing I wanted to clarify was that you need to load the symbols for the application executable, i.e. for example, for SysLink release 02.00.00.56 MessageQ sample application, the file messageq_ti81xx_dsp.xe674. Loading the symbols for just the SysLink library would not work.

The procedure to debug with SysLink is very much similar to how we debug with DSPLink on DM3730 etc. platforms.

Regards,

Mugdha

Ralph said:

I've never had ARM and DSP working in synchrony in a debug environment (i.e. CCS). I can get a Sysbios application running fine on just the DSP and  can step through it. I can step through an ARM using GDB. But when I try to boot Linux, disable the MMU, bring up the C674x, connect to the C674x and load symbols then run the ARM side app I find that the ARM has frozen and refuses to allow me to type in the name of the application to run.

Try modifying the GEL file from Spectrum Digitial by changing the following part and use it with the ARM A8 :

/* ------------------------------------------------------------------------ *
 *                                                                          *
 *  OnTargetConnect( )                                                      *
 *      Setup PADCTRL, Power, PLLs, DDR, & EMIF                             *
 *                                                                          *
 * ------------------------------------------------------------------------ */
OnTargetConnect( )
{
    GEL_TextOut( "Ok\n\n" );
}

With this change the ARM only halts and does not reset. You will be able to restart it later.

Lee Holeva

MugdhaK said:

The DSP application executable is the same one that we build within SysLink build system. We did not have to build it in CCS for us to be able to use CCS to debug the DSP-side.

This is the primary problem that I have when I attempt to "load symbols".  I cannot set breakpoiints in my source code when I built the code using xdc in the SDK, only when I built the code in CCS. 

MugdhaK said:

Then load symbols with the application executable that I have built (whole_program_debug or debug build will give you symbolic debug). I also set the source lookup path to the folders where I have my application, SysLink/IPC source code (if I want to debug within that too) and sometimes BIOS code too. After that, I can go ahead and set breakpoints, do single-step, watch etc.

CCS asks me for source for BIOS code, do we have that?

Lee Holeva

Lee,

Lee Holeva said:

This is the primary problem that I have when I attempt to "load symbols".  I cannot set breakpoiints in my source code when I built the code using xdc in the SDK, only when I built the code in CCS. 

I really have no idea about this ... I've never built SysLink apps in CCS. I've always built using xdc. Perhaps someone else will be able to help on this one.

Lee Holeva said:

CCS asks me for source for BIOS code, do we have that?

Yes, the sysbios release also comes with full source. You can point to it in the source lookup.

Regards,
Mugdha

MugdhaK said:

I've never built SysLink apps in CCS. I've always built using xdc.

There is something different between Syslink/Ipc DSP code made in CCS versus xdc.  Running code made in CCS 4.2.3 I get assertions from the Syslink driver, but from the identical code made with xdc I do not:

./runDSP DSPtasks_CCS.out
DSP is loaded from ARM
Entered SysLinkSamples_startup
SysLinkSamples_osStartup
Number of processors = 4
Entered ProcManager_startup with reset vector = 0
ProcMgr_attach status: [0x97d2000]
After attach: ProcMgr_getState
    state [0x1]
ProcMgr_load staAssertion at Line no: 2459 in /swcoe/sdk/cm/netra/arago-tmp/work
/dm816x-evm-none-linux-gnueabi/ti-syslink-02_00_00_68-r3i/syslink_02_00_00_68_be
ta1/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl
/ti81xx/Platform.c: ( (entry.isValid == FALSE) || ( (entry.isValid == TRUE) && (
 entry.len == (handle->slaveSRCfg [i].entryLen)))) : failed
tus: [0x3046000]
Assertion at Line no: 2550 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none
-linux-gnueabi/ti-syslink-02_00_00_68-r3i/syslink_02_00_00_68_beta1/ti/syslink/u
tils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl/ti81xx/Platform
.c: (entry.len == handle->slaveSRCfg [i].entryLen) : failed
After Ipc_loadcallback: ProcMgr_getState
    state [0x3]
ProcMgr_start passed [0x6a85000]
After Ipc_startcallback: ProcMgr_getState
    state [0x4]
ProcMgr_close status: [0x97d2000]
Leaving ProcMgrApp_startup
Once the emulator is connected, hit return

root@dm816x-evm:~/dm816x-evm/r1397# ./runDSP DSPtasks_ti81xx_dsp.xe674
DSP is loaded from ARM
Entered SysLinkSamples_startup
SysLinkSamples_osStartup
Number of processors = 4
Entered ProcManager_startup with reset vector = 0
ProcMgr_attach status: [0x0]
After attach: ProcMgr_getState
    state [0x1]
ProcMgr_load status: [0x3046000]
After Ipc_loadcallback: ProcMgr_getState
    state [0x3]
ProcMgr_start passed [0x6a85000]
After Ipc_startcallback: ProcMgr_getState
    state [0x4]
ProcMgr_close status: [0x97d2000]
Leaving ProcMgrApp_startup
Once the emulator is connected, hit return

The .cfg and other source files are identical.

Lee Holeva

Lee,

I'm slowly catching up to you, which may not be a good thing ;-)...  I just built the MessageQ test program from within CCSV5.  In referencing the Syslink examples I noticed they have symbols turned off in the build "--symdebug:none", although later in the same command line they have "--symdebug:dwarf", which may override it (if you try to load the symbols from the samples directory).  In creating the MessageQ  project one of the things I've done is looked at the command line options that CCS generates in the make file versus the Syslink samples.  In referencing this I used the command file option and added the following to CCS build so options are similiar:

-s -pdsw225 -mi10 -mo --gcc -DSYSLINK_BUILD_RTOS -Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h -Dxdc_bld__profile_whole_program_debug -Dxdc_bld__vers_1_0_7_2_0 -oe --symdebug:dwarf -mo -DSYSLINK_PLATFORM_OMAP3530

Not all the options should make a difference but -mi10 may effect interrupts and one of the defines may do something that we are not aware of.  Anyways I'll get into the Linux side now and see what happens, odds are I'll hit the same wall as you.  In the mean time you may want to compare the build options and see if it makes a difference.

Kev

MugdhaK said:

The way I usually debug is to keep CCS open with the required target configuration loaded (which will be setup to only have the DSP since I don't need to debug on anything else using CCS). At this point, I've not connected to any core in CCS. Then I power-up the board, boot Linux, insmod syslink etc. run ProcMgr application using SysLink and when it says that the DSP has been loaded and started, I connect to the DSP in CCS. Then load symbols with the application executable that I have built (whole_program_debug or debug build will give you symbolic debug). I also set the source lookup path to the folders where I have my application, SysLink/IPC source code (if I want to debug within that too) and sometimes BIOS code too. After that, I can go ahead and set breakpoints, do single-step, watch etc.

Hi Mughda,

thanks for clarifying that. I have succeeded in following your instructions and going as far as loading the symbols but despite adding in all the most important directories and their subdirectories in the EZSDK no source code is found by CCS no matter which thread I click on. Pic of my source path (yes, it does slow down CCS a lot having so large a search path):

And here is a picture of my Debug window after connecting and loading symbols:

Lee, would you like me to create a new thread? I don't want to hijack yours but if this is related and of use I can keep my posts here.

Cheers,
Ralph

Ralph said:

no source code is found by CCS no matter which thread I click on.

No need to start a new thread, as I'm having the same problem, a lack of source symbols.  I just installed CCS5.0.3 and I need to post a question on the Code Composer forum as the launch debug configuration does not appear to work.

Lee Holeva

Kevin Halloran said:

I just built the MessageQ test program from within CCSV5

I can build Syslink code in CCS5, the code appears to work, yet I get assertions from the Syslink driver, which I do not get from the identical cope made by xdc in the SDK:

Code made in CCS5.0.3:

./runDSP DSPtasks_CCS5.out
DSP is loaded from ARM
Entered SysLinkSamples_startup
SysLinkSamples_osStartup
Number of processors = 4
Entered ProcManager_startup with reset vector = 0
ProcMgr_attach status: [0x97d2000]
After attach: ProcMgr_getState
    state [0x1]
ProcMgr_load staAssertion at Line no: 2459 in /swcoe/sdk/cm/netra/arago-tmp/work
/dm816x-evm-none-linux-gnueabi/ti-syslink-02_00_00_68-r3i/syslink_02_00_00_68_be
ta1/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl
/ti81xx/Platform.c: ( (entry.isValid == FALSE) || ( (entry.isValid == TRUE) && (
 entry.len == (handle->slaveSRCfg [i].entryLen)))) : failed
tus: [0x3046000]
Assertion at Line no: 2550 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none
-linux-gnueabi/ti-syslink-02_00_00_68-r3i/syslink_02_00_00_68_beta1/ti/syslink/u
tils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl/ti81xx/Platform
.c: (entry.len == handle->slaveSRCfg [i].entryLen) : failed
After Ipc_loadcallback: ProcMgr_getState
    state [0x3]
ProcMgr_start passed [0x6a85000]
After Ipc_startcallback: ProcMgr_getState
    state [0x4]
ProcMgr_close status: [0x97d2000]
Leaving ProcMgrApp_startup
Once the emulator is connected, hit return

Now the xdc made code:

./runDSP DSPtasks_ti81xx_dsp.xe674
DSP is loaded from ARM
Entered SysLinkSamples_startup
SysLinkSamples_osStartup
Number of processors = 4
Entered ProcManager_startup with reset vector = 0
ProcMgr_attach status: [0x97d2000]
After attach: ProcMgr_getState
    state [0x1]
ProcMgr_load status: [0x3046000]
After Ipc_loadcallback: ProcMgr_getState
    state [0x3]
ProcMgr_start passed [0x6a85000]
After Ipc_startcallback: ProcMgr_getState
    state [0x4]
ProcMgr_close status: [0x97d2000]
Leaving ProcMgrApp_startup
Once the emulator is connected, hit return

Update:

Interesting experiment:  I went back to CCS4.2.3, ran the debugger, and my Syslink code, which works fine by itself, hung at the point where the ARM attempts to open the DSP's message queue.  I'm guessing that the DSP went south.

Lee Holeva

Well that isn't a good sign.  In looking at the Platform.c code it would be interesting to see what you get at:

line 2406:  status = _Platform_readSlaveMemory (procId,start + sizeof (Platform_SlaveConfig),handle->slaveSRCfg,&numBytes);

for an xdc build as compared to ccs build.  'handle->slaveSRCfg' contents would be interesting to view.  Possibly it has something to do with cache not getting flushed on the DSP side with the configuration information thus causing some bogus values?  Or the shared region is not the size we think it should be and is a CCS platform configuration issue?  Just a guess but if you could breakpoint with gdb possibly a comparison of the structure contents may lead to what is different?  I know we shouldn't have to do this but have a feeling TI is not going to be of much help.  It may be Tuesday before I get to this point but if I see anything I'll drop a note...

Kev

Kevin Halloran said:

In looking at the Platform.c code it would be interesting to see what you get at:

line 2406:  status = _Platform_readSlaveMemory (procId,start + sizeof (Platform_SlaveConfig),handle->slaveSRCfg,&numBytes);

This is in the Syslink driver?  I rather not go there, that's TI's problem.

The only way I have been able to do symbolic debugging on the C6a816x DSP is when the emulator loads the program into the DSP and starts it running.  Unfortunately, I have not been able to get the Syslink driver to work using the NoLoad modes, say ProcMgr_BootMode_NoBoot, which should be the correct choice.  I see the DSP continuely looping attempting to get the host to respond to Ipc_start().  Load symbols, even when down on code made in CCS, doesn't allow me to set breakpoints.

Lee Holeva

Lee Holeva said:

I can build Syslink code in CCS5, the code appears to work, yet I get assertions from the Syslink driver, which I do not get from the identical cope made by xdc in the SDK:

Assertion at Line no: 2459 in /swcoe/sdk/cm/netra/arago-tmp/work
/dm816x-evm-none-linux-gnueabi/ti-syslink-02_00_00_68-r3i/syslink_02_00_00_68_be
ta1/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl
/ti81xx/Platform.c: ( (entry.isValid == FALSE) || ( (entry.isValid == TRUE) && (
 entry.len == (handle->slaveSRCfg [i].entryLen)))) : failed
tus: [0x3046000]
Assertion at Line no: 2550 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none
-linux-gnueabi/ti-syslink-02_00_00_68-r3i/syslink_02_00_00_68_beta1/ti/syslink/u
tils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl/ti81xx/Platform
.c: (entry.len == handle->slaveSRCfg [i].entryLen) : failed

Looks like a mismatch in SharedRegion configuration between the DSP and the firmware that's loaded on the VPSS-M3 earlier. Can you check the versions of dependencies match? And that the correct CFG is getting used? Not much more to offer here, unfortunately, since we've not experimented with CCS build.

Regards,
Mugdha

Ralph,

The picture of the debug window you showed is good ... it means that the DSP is up and blocked on something (in Idle task). It does show that symbols have been properly loaded, otherwise you would not have seen what you've shown here. If you want to debug something in your application after this, you may want to now open your application source file in CCS, put a breakpoint in your application (that comes after whatever you've been waiting on is unblocked), and proceed further from Linux-side -- run whatever you need to run to start communicating with the DSP.

You should see the breakpoint getting hit. If your symbols are loaded correctly, you will be able to set a breakpoint. Otherwise the breakpoint setting itself will fail.

If you want to debug before you reach the idle task, you'll have to stop somewhere ealier in your application. The way we do it is to add the following in main (say after Ipc_start) or in our application task, essentially wherever we want to debug from.

{

volatile int haltIt = 1;

while (haltIt);

}

Then when I connect to DSP and load symbols, if I've set my source lookup correctly, this file will open in CCS, and I will see that I'm spinning here. I just go ahead and change the value of 'haltIt' to 0 in watch window and then step through. At that point, I can set break-points anywhere I want, or even step through all the way if I so wish.

Making haltIt volatile ensures that if you're in release build with symbols, the compiler won't optimize out all the code after this, and also using a variable ensures that you can safely move ahead by changing the value in watch window (instead of directly using while (1)).

Regards,
Mugdha

MugdhaK said:

Looks like a mismatch in SharedRegion configuration between the DSP and the firmware that's loaded on the VPSS-M3 earlier. Can you check the versions of dependencies match? And that the correct CFG is getting used?

For the CCs build I had to remove the .cfg files for videom3 and vpssm3 as I get a build error for a missing library:

Instruments/bios_6_31_04_27/packages/ti/sysbios/family/arm/ducati/package.xs", line 72: Error: Library not found: ti.sysbios.family.arm.ducati.ae674

When I build using xdc in the SDK, all three .cfg files are present (to make the shared regions identical?).  I notice that in the previous SDK there were only .cfg files for the DSP.

Lee Holeva

Lee,

In the new SDK, do you specify SYSLINK_SDK=EZSDK when doing the SysLink samples build on Linux-side?

In the new SysLink release, all three cfg files are provided, but the build of sample is only for DSP if :

1. SYSLINK_SDK=EZSDK is specified when doing make for the samples on Linux-side, and for DSP-side build

2. For building DSP-side, the following is specified for XDCARGS

xdc all XDCARGS="SDK=EZSDK"

If you don't specify this, SysLink samples will attempt to build for all three slave cores, and then if you have changed the configuration, there could be a conflict.

If you specify this, SysLink samples will build and work only for the DSP. For CCS build, just building the DSP (and not building the others at all) should work similarly.

Regards,
Mugdha

MugdhaK said:

In the new SDK, do you specify SYSLINK_SDK=EZSDK when doing the SysLink samples build on Linux-side?

In the new SysLink release, all three cfg files are provided, but the build of sample is only for DSP if :

1. SYSLINK_SDK=EZSDK is specified when doing make for the samples on Linux-side, and for DSP-side build

2. For building DSP-side, the following is specified for XDCARGS

xdc all XDCARGS="SDK=EZSDK"

Yes, I built the samples in the new SDK exactly as you described.  For a CCS build I am using he same .cfg files for the dsp as in the xdc build in the SDK.

Lee Holeva

I'm running out of ideas :-/

Can you compare your .map file generated with CCS build and with the xdc build and see if they match? Can you check if your build options when built through CCS match those with xdc build? Can you use xdc build itself and not try to use CCS build at all? -- I do believe that your problems with symbolic debug are not because of xdc build and won't get solved with CCS build, if that's the reason why you're trying CCS build ... did you use debug build and check if you can get symbols correctly with that? With whole_program_debug, sometimes single step behaves strangely and jumps around in unexpected ways.

Regards,
Mugdha

MugdhaK said:

Can you compare your .map file generated with CCS build and with the xdc build and see if they match?

xdc does not produce a .map file.  I am using slighly modified config.bld and packge.bld files taken from the samples to build my code using xdc.

MugdhaK said:

I do believe that your problems with symbolic debug are not because of xdc build and won't get solved with CCS build, if that's the reason why you're trying CCS build 

The only bit of success that I've had is when I build the code in CCS and "Load Program", as I have actually been able to set a breakpoint and see a bit of the DSP code run.   When I do "Load Symbols" from the code made using xdc in the SDK, what I see is different from what Ralph is seeing:

Perhaps this would help, here are the xdc project files:

config.bld

// ON Linux Host. Modify this to suit your tool chain paths
var rootDirPre = "/home/lholeva/ti-ezsdk_dm816x-evm_5_01_00_77";
var rootDirPost = "";

//********************* Setup for C674 target for COFF *************************
var C674_COFF = xdc.useModule('ti.targets.C674');
C674_COFF.rootDir = rootDirPre + "/cgt6x_7_2_2" + rootDirPost;
C674_COFF.ccOpts.suffix += " -g -mi10 -mo ";
//set default platform and list of all interested platforms for c674
C674_COFF.platforms = [
                    //"ti.platforms.evmDA830:dsp",
                    "platforms.ti816x.dsp"
                ];

//********************* Setup for C674 target for ELF *************************
var C674_ELF = xdc.useModule('ti.targets.elf.C674');
C674_ELF.rootDir = rootDirPre + "/cgt6x_7_2_2" + rootDirPost;
C674_ELF.ccOpts.suffix += " --profile:breakpt -O0 -g -mi10 -mo ";
//set default platform and list of all interested platforms for c674
C674_ELF.platforms = [
                   // "ti.platforms.evmDA830:dsp",
                   //"ti.syslink.samples.rtos.platforms.ti816x.dsp",
     "platforms.ti816x.dsp"
                ];

//list interested targets in Build.targets array
Build.targets = [
                    //C28_large,
                    //C64,
                    //C64P_COFF,
                   //C64P_ELF,
                    //C67P,
                    //C674_COFF,
                    C674_ELF,
                   //M3_ELF,
                ];

package.bld

var testBld = xdc.loadCapsule("ti/syslink/buildutils/rtos/buildScripts/test.bld");
/*
 *  Export everything necessary to build this package with (almost) no
 *  generated files.  This also exports subdirectories like 'golden'
 *  and 'docs'.
 */
var srcRelease = Pkg.addRelease(Pkg.name + ",src", {exportSrc: true, exportExe : true, exportCfg: true, exportAll: true});

/*
 *  Export everything necessary to build this package with (almost) no
 *  generated files.  This also exports subdirectories like 'golden'
 *  and 'docs'.
 */
//Pkg.attrs.exportAll = true;

/*
 *  ======== testArray ========
 *  See ti/bios/build/test.bld. Only the test name is required.
 *
 *  Example:
 *    var testArray = [
 *        {name: Test1},
 *        {name: Test2, sources: ["Test"], config: "Test", refOutput: "Test", timeout: "15", buildTargets: ["C64", "C28_large"]}
 *    ];
 */
var testArray = [
    {name: 'DSPtasks_ti81xx_dsp',
        sources: ["DSPtasks", "Preprocessing"], config: "./ti81xx/DSPtasks_ti81xx_dsp",
        copts: ["-g -DSYSLINK_PLATFORM_TI81XX"],
        buildTargets: ["C674"],
        buildPlatforms: ["platforms.ti816x.dsp"],
    },
    {name: 'DSPtasks_ti81xx_videom3',
        sources: ['DSPtasks'], config: "./ti81xx/DSPtasks_ti81xx_videom3",
        copts: " -DSYSLINK_PLATFORM_TI81XX ",
        buildTargets: ["M3"],
        buildPlatforms: ["platforms.ti816x.videom3"],
    },
    {name: 'DSPtasks_ti81xx_vpssm3',
        sources: ['DSPtasks'], config: "./ti81xx/DSPtasks_ti81xx_vpssm3",
        copts: " -DSYSLINK_PLATFORM_TI81XX ",
        buildTargets: ["M3"],
        buildPlatforms: ["platforms.ti816x.vpssm3"],
    },
];

arguments[arguments.length++] = "platform=all";
arguments[arguments.length++] = "platform=debug";

/* clean generated files and folders */
Pkg.generatedFiles.$add("platforms.ti816x.dsp/");

/* Generate the makefile goals. 'arguments' is XDCARGS */
testBld.buildTests(testArray, arguments);

Lee Holeva

Lee,

I built my stuff with "debug", not "whole_program_debug" so you may want to try that. It doesn't look like your binary has many symbols in it (at a guess)...

Mughda,

if it's alright with you I'd like to continue with my woes in a new thread:

http://e2e.ti.com/support/dsp/integra_dsparm/f/625/p/113094/400774.aspx

Cheers,

Ralph

Ralph said:

I built my stuff with "debug", not "whole_program_debug" so you may want to try that. It doesn't look like your binary has many symbols in it (at a guess)...

Ralph,

How did you get xdc to make debug rather than whole program debug, or did you make the code in CCS? 

Lee Holeva

Not made in CCS. Made on Linux in the EZSDK.

As per the <EZSDK>/syslink/ti/syslink/docs/install guide.pdf at bottom of page  8.

Default build profie is "whole_program_debug" to change this to "debug" run the following
 $ xdc all XDCARGS="profile=debug"
XDCBUILDCFG="$SYSLINK_ROOT/config.bld" -PR .

I keep seeing references saying "whole_program_*" is optimised so I don't trust something that can be both optimised and debuggable at the same time. :-|

Ralph

Ralph said:

Default build profie is "whole_program_debug" to change this to "debug" run the following
 $ xdc all XDCARGS="profile=debug"

Ok, I rebuilt my DSP code this way, and I got a debug build, but still no symbols.  Did you try loading the entire xdc project into CCS?

Lee Holeva

Lee Holeva said:

 

Ok, I rebuilt my DSP code this way, and I got a debug build, but still no symbols.  Did you try loading the entire xdc project into CCS?

Lee Holeva

No, I daren't do that. I've got to get my particular procmgrapp working before I move onto that.

Ralph

Update: by the way, I am using the old EZSDK with Syslink ending in "56" whereas you are using the newest EZSDK with Syslink ending in "68".

Lee Holeva said:

config.bld

//********************* Setup for C674 target for ELF *************************
var C674_ELF = xdc.useModule('ti.targets.elf.C674');
C674_ELF.rootDir = rootDirPre + "/cgt6x_7_2_2" + rootDirPost;
C674_ELF.ccOpts.suffix += " --profile:breakpt -O0 -g -mi10 -mo ";

Our config .bld has slightly different ccOpts.suffix values:

C674_ELF.ccOpts.suffix += " -mi10 -mo --gcc -DSYSLINK_BUILD_RTOS ";

Can you try with this and check again?

Regards,
Mugdha