CCS Project for IPC MessageQ samples

Girish,

Girish Tummala said:

error: ti.ipc.remoteproc.Resource: "C:/ti/ipc_3_35_01_07/packages/ti/ipc/remoteproc/Resource.xs", line 57: ti.ipc.remoteproc.Resource : IpcMemory.loadSegment not found

Do you have a statement similar to the following in your .cfg file?:

    var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
    Resource.loadSegment = Program.platform.dataMemory;

That error message is printed when the Resource module's 'loadSegment' member is not assigned.

Regards,

- Rob

Rob,

I don't see any such statement in my .cfg file. Again, I just copied rpmsg_transport.cfg file from the tests folder of IPC samples to this CCS project. One thing I noticed is there is a 'package.bld' file in the 'tests' folder of the IPC samples, but it looks like the CCS project generates 'package.bld' file and it doesn't have any of the memory map information present in the IPC sample package.bld file. I am suspecting it might not be finding the memory map for dsp.

Am I making any sense in saying this? Where should I place this memory map in CCS project? I printscn'ed my CCS window to give you an idea of how I setup the project structure.

Could you let me know if you see any mistakes in setting up CCS project from the above image?

Does TI already have a sample CCS6 project for IPC sample codes?

Girish,

Girish Tummala said:

Does TI already have a sample CCS6 project for IPC sample codes?

Not that I know of.

And I'm not knowledgeable about CCS projects, but I'll try to struggle along with you ...

Girish Tummala said:

I don't see any such statement in my .cfg file. Again, I just copied rpmsg_transport.cfg file from the tests folder of IPC samples to this CCS project.

rpmsg_transport.cfg includes Dsp_vayu.cfg (after it has decided that it's being invoked for a DRA7XX DSP), which has the following:
Resource.loadSegment = "EXT_CODE";

Girish Tummala said:

I am suspecting it might not be finding the memory map for dsp.

That's correct.  In setting up your project your probably chose the platform ti.platforms.evmDRA7XX, which just has the generic memory map.  The Ipc tree's package.bld defines a platform instance for each remote core on the DRA7XX, and in doing so the platform instance's memory map is defined to have a section named "EXT_CODE".  Since your project isn't using this platform instance then your memory map doesn't have "EXT_CODE", and the Resource.xs file is complaining that it doesn't know about the value assigned to loadSegment (i.e., "EXT_CODE").

You probably need to use the CCS Platform Wizard to create your own platform, based on ti.platforms.evmDRA7XX (the platform wizard is kinda hard to find, I think it's under the Tools dropdown *only* when you're using the CCS Debug perspective).  I'm not up on the details, but there's a way to either copy an existing platform or base your platform on an existing one.  You would add your custom memory map there, duplicating what is defined in <ipc>/ti/ipc/tests/package.bld's ti.platforms.DRA7XX:dsp1 platform instance definition:

Build.platformTable["ti.platforms.evmDRA7XX:dsp1"] = {
    externalMemoryMap: [
        [ "EXT_CODE", evmDRA7XX_ExtMemMapDsp.EXT_CODE ],
        [ "EXT_DATA", evmDRA7XX_ExtMemMapDsp.EXT_DATA ],
        [ "EXT_HEAP", evmDRA7XX_ExtMemMapDsp.EXT_HEAP ],
        [ "TRACE_BUF", evmDRA7XX_ExtMemMapDsp.TRACE_BUF ],
        [ "EXC_DATA", evmDRA7XX_ExtMemMapDsp.EXC_DATA ],
        [ "PM_DATA", evmDRA7XX_ExtMemMapDsp.PM_DATA ],
        [ evmDRA7XX_SR_0.name, evmDRA7XX_ExtMemMapDsp.SR_0 ],
    ],
    codeMemory: "EXT_CODE",
    dataMemory: "EXT_DATA",
    stackMemory: "EXT_DATA",
};

The values assigned to evmDRA7XX_ExtMemMapDsp are just above this snippet in that package.bld file (didn't want to include here since it's kinda long).

The platofrm wizard will ultimately create a package whose location needs to be contained in your XDC package path (expand the path to point to it, or place in a location that's already in your path).

As you've seen, the Ipc tree uses package.bld to define platform instances.  The instance could also be defined in config.bld (in the Ipc tree that equates to ipc-bios.bld, since we do XDCBUILDCFG=./ipc-bios.bld on the xdc command line - see ipc-bios.mak for details), but both package.bld and config.bld are generated by the CCS project, so it seems that option is not available for this.

Some general advice is to make sure that you use the same compiler/linker options as are used in the Ipc tree.  These are defined mostly in that top-level ipc-bios.bld that I just mentioned.

Regards,

- Rob

Rob,

I used the platform wizard and defined a custom platform instance based of DRA7xx memory map. I added all the regions in the sample code package.bld file. I modified the platform name in some files to match the one I created. I placed the created package under 'C:\ti\xdctools_3_30_01_25\packages\ti\platforms',  but when I try to build the project, it is erroring saying that there is a mismatch. See below:

**** Build of configuration Debug for project SampleDSP ****

"C:\\ti\\ccsv6\\utils\\bin\\gmake" -k all

subdir_rules.mk:24: warning: overriding commands for target `configPkg/linker.cmd'

subdir_rules.mk:7: warning: ignoring old commands for target `configPkg/linker.cmd'

'Building file: ../rpmsg_transport.cfg'

'Invoking: XDCtools'

"C:/ti/xdctools_3_30_01_25/xs" --xdcpath="C:/ti/bios_6_40_01_15/packages;C:/ti/xdctools_3_30_01_25/packages;C:/ti/ipc_3_35_01_07/packages;C:/ti/ccsv6/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.elf.C66 -p ti.platforms.sdDRA7xx -r debug -c "C:/ti/ccsv6/tools/compiler/c6000_7.2.12" --compileOptions "-g --optimize_with_debug" "../rpmsg_transport.cfg"

making package.mak (because of package.bld) ...

generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...

configuring rpmsg_transport.xe66 from package/cfg/rpmsg_transport_pe66.cfg ...

Program.cpu.deviceName = DRA7XX

Program.platformName = ti.platforms.sdDRA7xx

js: "C:/Users/tummala/workspace_v6_1/SampleDSP/messageq_common.cfg.xs", line 227: messageq_common.cfg.xs: Did not match any platform!

   "C:/Users/tummala/workspace_v6_1/SampleDSP/rpmsg_transport.cfg", line 126

   "./package/cfg/rpmsg_transport_pe66.cfg", line 191

gmake.exe: *** [package/cfg/rpmsg_transport_pe66.xdl] Error 1

js: "C:/ti/xdctools_3_30_01_25/packages/xdc/tools/Cmdr.xs", line 51: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted.

making ../src/sysbios/sysbios.ae66 ...

gmake[1]: Entering directory `C:/Users/tummala/workspace_v6_1/SampleDSP/src/sysbios'

cle66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/BIOS.c ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c64p/Hwi_disp_always.s64P ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c64p/Hwi_asm.s62 ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c64p/Hwi_asm_switch.s62 ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c64p/Clobber_asm.s62 ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c64p/Exception_asm.s64P ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c64p/MemoryProtect_asm.s64P ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/family/c62/TaskSupport_asm.s62 ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/timers/timer64/Timer_asm.s64P ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/timers/dmtimer/Timer_asm.s64P ...

asme66 C:/ti/bios_6_40_01_15/packages/ti/sysbios/../sk/sk_cwrap.asm ...

are66 BIOS.obj c64p_Hwi_disp_always.obj c64p_Hwi_asm.obj c64p_Hwi_asm_switch.obj c64p_Clobber_asm.obj c64p_Exception_asm.obj c64p_MemoryProtect_asm.obj c62_TaskSupport_asm.obj timer64_Timer_asm.obj dmtimer_Timer_asm.obj sk_sk_cwrap.obj ...

gmake[1]: Leaving directory `C:/Users/tummala/workspace_v6_1/SampleDSP/src/sysbios'

gmake: Target `all' not remade because of errors.

**** Build Finished ****

I just created the memory map for dsp1 in the custom package, do I need to created memory maps for all the other cores as well?

Any ideas on what else to update?

Girish,

There are directions on creating a platform here:

rtsc.eclipse.org/.../Creating_Platform_Packages

Did you run the "xdc" command on your package after you created it? If so you should see a ti/platforms/sdDRA7xx/package directory.

Brad

Brad,
Thanks for posting that link.
After making the required changes and fixing a couple of errors, I am able to build IPC 3.x sample code in CCS6.
I have not tried running it yet on the dsp, but the build completed successfully and it generated the .out file successfully.

So in order to run the created .out file on the DSP. Do I need to modify anything on the A15 side?
Right now, A15 is initially loading dsp binaries on to the dsp cores at startup. Do I need to change any of this thing?
Can I just push the newly created dsp image on to the dsp core using USB560v2 debugger and still communicate to A15 using IPC?

-Girish

Girish Tummala said:

Can I just push the newly created dsp image on to the dsp core using USB560v2 debugger and still communicate to A15 using IPC?

What was the old image?  Was it the same example built by makefiles instead of by CCS?  If so, then yes, I believe you should be able to drop-in your updated DSP image.

Girish,

Girish Tummala said:

Can I just push the newly created dsp image on to the dsp core using USB560v2 debugger and still communicate to A15 using IPC

You need to let remoteproc load the dsp image, it performs a lot of actions that won't happen when loading through CCS.

And as Brad said, you should be able to just drop the new image in place of the old one without changing anything on the A15.

Regards,

- Rob

 

Yes, currently I have sample example running on DSP core.
But my question was about the most efficient way to continue iterative development on DSP code.
Since I have my CCS project setup validated with the sample example, I will be continuing my development in CCS.
When I make some changes to the DSP code and build it, what is the best way to run and debug it?

Until now, before being able to build DSP code in CCS, I was using yocto build system to build the linux side of things on A15 core, as well as the dsp core side of things( by calling make from a yocto recipe) and since both are in the same root image, remoteproc loaded dsp image at start up.

Now if I am planning to start active dsp core development in CCS, how can I make sure that I can run the build dsp output file and debug it?

-Girish

I usually try to do algorithm development in a simplified project that doesn't have ARM dependencies so that I can rapidly make changes and reload the code without any complex booting, etc. Once things are in a state where you think it's working properly, that's where you would integrate into the full IPC-based image where you incur additional "overhead" with regard to loading, etc. It sounds to me like you're better off using your Yocto build for "the full image" and that perhaps you should try to set up something very simple that works with test vectors instead of real I/O for your initial development.

Girish Tummala said:

since both are in the same root image, remoteproc loaded dsp image at start up.

Can your CCS access the root image that the yocto recipe uses?  If so, you can configure your project to output the final dsp .xe66 to the same place.

If not, you will need to manually copy the xe66 from your CCS project over to the root image from where remoteproc loads it..

Girish Tummala said:

Now if I am planning to start active dsp core development in CCS, how can I make sure that I can run the build dsp output file and debug it

After remoteproc has loaded the image, you can connect to the dsp core with CCS.  This will stop the dsp whereever it is running at the time.  If your CCS project is active then you should have full debug capability.  If you need to have it stopped at some earlier point, such as in main(), the easist way is to add a spin loop that you can release after connecting with CCS, such as:

volatile int spin = 1;

int main()
{
    while (spin);
}

and then changing 'spin' to 0 in CCS after connecting (and setting breakpoints and such).

Regards,

- Rob

Robert Tivy said:

After remoteproc has loaded the image, you can connect to the dsp core with CCS.  This will stop the dsp whereever it is running at the time.  If your CCS project is active then you should have full debug capability. 

I am assuming I should select to just load symbols when I connect to dsp using debugger, Am I right?

Robert Tivy said:

you will need to manually copy the xe66 from your CCS project over to the root image from where remoteproc loads it.

I looks like from your response that I should be getting a xe66 output file from CCS project. I don't see any such file being generated. <proj-name>.out file is being created in my CCS workspace project folder after successfully building the project in CCS, where as when I ran the make file, a .xe66 file is being generated. 

Am I missing any settings to generate a .xe66 output file in CCS project?

-Girish