• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 99 subscribers
  • Views 645 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.

DSP-Link installation problem

Fjs
Intellectual 360 points
Other Parts Discussed in Thread: OMAP-L138, CCSTUDIO, OMAPL138, OMAP3530

I actually implement DSP-Link on the DSP side of the OMAP-L138. I only need a simple data transfer between the ARM and the DSP unit. Therefore i will use the PROC_read / -write functionality.

For this, i use the DSP-Link part in the packet "OMAP_L138_dsp_setupwin32_1_00_00_08.exe"

First of all, i included the libs "dsplink.lib" and "dsplinkdata.lib" in my project. In the next step, i add via "utils.importFile("dsplink-omapl138gem-base.tci");" in my configuration file the settings for the DSP-Link part.

After that, i try to compile my project, But i get a compilation error:

"js: "./configuration.tcf", line 37: Heaps are enabled, but the segment for DSP/BIOS Objects (MEM.BIOSOBJSEG) is not set correctly. Please create a heap in one of your data segments and set MEM.BIOSOBJSEG to it."

I see that this message is a result from importing the dsplink configuration file. In the dsplink configuration a heap will be created in the DDR section. For my project i do not need dynamic memory heaps. So in the next step i link BIOSOBJSEG and MALLOCSEC via

bios.MEM.BIOSOBJSEG = prog.get("DDR");
bios.MEM.MALLOCSEG = prog.get("DDR");

to the DDR memory. The compilation was now successful, but i got many linker errors like this:

"C:\\CCStudio_v3.3\\MyProjects\\test\\Configurationcfg.cmd", line 339: error:
   run placement fails for object ".bss", size 0x3444 (page 0).  Available
   ranges:
   IRAM         size: 0x8000       unused: 0x0          max hole: 0x0

 

Does anybody knows what is wrong?

 

 

Here is my actual configuration file:

utils.loadPlatform("ti.platforms.expOMAPL138");

utils.importFile("dsplink-omapl138gem-base.tci");

/* The following DSP/BIOS Features are enabled.  */
bios.enableRealTimeAnalysis(prog);
bios.enableRtdx(prog);
bios.enableTskManager(prog);

bios.LOG.create("LOG_Obj");
bios.LOG.instance("LOG_Obj").bufLen = 256;
bios.LOG.instance("LOG_Obj").destroy();
bios.LOG.create("trace");
bios.LOG.instance("trace").bufLen = 256;
bios.LOG.instance("trace").comment = "Trace buffer";
bios.HWI.instance("HWI_INT4").useDispatcher = 1;
bios.HWI.instance("HWI_INT4").fxn = prog.extern("McASPInt");
bios.HWI.instance("HWI_INT4").interruptMask = "all";
bios.HWI.instance("HWI_INT4").interruptSelectNumber = 61;
bios.SWI.instance("PRD_swi").order = 1;
bios.SWI.instance("KNL_swi").order = 2;
bios.SWI.instance("PWRM_loadSwi").order = 3;
bios.TSK.create("FilterTsk");
bios.TSK.instance("FilterTsk").order = 1;
bios.TSK.instance("TSK_idle").order = 2;
bios.TSK.instance("FilterTsk").priority = 15;
bios.TSK.instance("FilterTsk").fxn = prog.extern("FilterFct");
bios.TSK.instance("FilterTsk").comment = "Filter routine";

bios.SEM.create("BufferReady");
bios.SEM.instance("BufferReady").comment = "A semaphore to start the task";
bios.HWI.instance("HWI_INT5").interruptSelectNumber = 89;
bios.HWI.instance("HWI_INT5").useDispatcher = 1;
bios.HWI.instance("HWI_INT5").interruptMask = "all";
bios.HWI.instance("HWI_INT5").fxn = prog.extern("McBSPInt");
bios.MEM.BIOSOBJSEG = prog.get("DDR");
bios.MEM.MALLOCSEG = prog.get("DDR");
// !GRAPHICAL_CONFIG_TOOL_SCRIPT_INSERT_POINT!

prog.gen();

  • 0
    Intellectual 360 points

    The errors occures from a too small IRAM section. I increased the length of the IRAM section. Now, i can compile my project without errors.

    The next step i will do, is to init the DSPLink unit and implement the PROC_read / -write functionality.

  • 0 in reply to Deepali Uppal
    Intellectual 360 points

    Hi Deepali,

    thanks for your answer.

    In the meantime, i inserted the command 'DSPLINK_init'. After that, i got some linker errors. First of all, i must include all dsplink libraries, although i only need PROC and NOTIFY. Then i got a pool error from the linker:

     undefined    first referenced                                                         
      symbol          in file                                                              
     ---------    ----------------                                                         
     _POOL_config C:/CCStudio_v3.3/bios_5_41_02_14/packages/ti/bios/lib/bios.a674<pool.o674>

    So i added a dummy pool in my project, how it was described in the wiki. After entering the two lines:

    POOL_Obj Dummy_Pool[1] = {POOL_NOENTRY} ;
    POOL_Config POOL_config = {Dummy_Pool, 1};

    i could compile and link my project successfully.

    After starting my project, the programm does not return from the DSPLINK_init function.

    Actually only the DSP side is working. Is the GPP side necessary, although i actually do not use PROC_read / write? Could there be another reason for this behaviour? It is really necessary, that i must include all dsplink libraries?

     

  • 0 in reply to Fjs
    TI__Expert 4930 points

    Please find my responses inline:

    fjs said:
    In the meantime, i inserted the command 'DSPLINK_init'.

    Please note this must be called before any DSPLink API usage.

    fjs said:
    After that, i got some linker errors. First of all, i must include all dsplink libraries, although i only need PROC and NOTIFY. Then i got a pool error from the linker


    Which with configurations have you run dsplinkcfg command? This looks like you have run it with at least --comps=ponslm . This command configures DSPLink to use POOL, MSGQ etc and forces the application writer to link in the associated DSPLink component libraries. This is the reason you are getting linker errors for POOL and other DSPLink functions. To remove the linker errors, re-configure DSPLink to use --comps as pn. Then you will have to link in only PROC and NOTIFY libraries and you will not get linker errors for other DSPLink components.

    fjs said:
      After starting my project, the programm does not return from the DSPLINK_init function.


    Did the application run before this change? Have you called PROC_start on GPP? DSPLINK_init call waits in a while till PROC_start is called on GPP.


    fjs said:
    Actually only the DSP side is working. Is the GPP side necessary, although i actually do not use PROC_read / write? 

    Are you using DSPLink to boot load the DSP? DSPLink will be needed to do the boot loading functions like PROC_setup, PROC_attach, PROC_load (to load DSP image in memory), PROC_start (to release DSP from reset). These API's set up the DSP memory so that the handshake between DSP and ARM (done in DSPLINK_init) and Notify related logic to allow GPP to receive notifications from DSP. You cannot do away with DSPLink on GPP side completely if you want to use PROCand NOTIFY within DSPLInk.
    Deepali

  • 0 in reply to Deepali Uppal
    Intellectual 360 points

    Hi Deepali,

    thanks for your answer.

    Please note this must be called before any DSPLink API usage.

    Actually, i have not using any DSPLink API call. Only DSPLink_init is done in the main.

    Which with configurations have you run dsplinkcfg command? This looks like you have run it with at least --comps=ponslm . This command configures DSPLink to use POOL,  MSGQ etc and forces the application writer to link in the associated DSPLink component libraries. This is the reason you are getting linker errors for POOL and other DSPLink functions. To remove the linker errors, re-configure DSPLink to use --comps as pn. Then you will have to link in only PROC and NOTIFY libraries and you will not get linker errors for other DSPLink components.

    I am not very familiar with the make system, so i do not use the make system. I installed the DSP-Link in my CCS project. For this, i adapt the tcf file and inserted the precompiled dsplink.lib from the 'OMAP-L138_dsp_1_00_00_08\dsplink_linux_1_65_00_01\dsplink\dsp\export\BIN\DspBios\OMAPL138\OMAPL138GEM_0\RELEASE' directory. After compiling my project, i see that i need all other dsplink libs from this directory. Is it possible to configure DSPLink in the CCS without using the make system and using the precompiled libs?

    Did the application run before this change? Have you called PROC_start on GPP? DSPLINK_init call waits in a while till PROC_start is called on GPP.

    Yes, it runs previously. If i comment out DSPLINK_init my application is running again. I run the dsp program via emulator. No application is actually running on the GPP side.You say, that the DSPLINK_init call waits in a while loop till PROC_start is called on GPP. Has the DSPLINK_init a time out, if no GPP part is running?

    Are you using DSPLink to boot load the DSP? DSPLink will be needed to do the boot loading functions like PROC_setup, PROC_attach, PROC_load (to load DSP image in memory), PROC_start (to release DSP from reset). These API's set up the DSP memory so that the handshake between DSP and ARM (done in DSPLINK_init) and Notify related logic to allow GPP to receive notifications from DSP. You cannot do away with DSPLink on GPP side completely if you want to use PROCand NOTIFY within DSPLInk.

    As i explained above, i have no GPP part running, but i only called DSPLINK_init. No DSPLINK API call is actually done.

    When the dsp part is ready, the next step is the GPP part and the test of the bootloader functionality. After that, PROC_read / write will be implemented.

     

     

  • 0 in reply to Fjs
    TI__Expert 4930 points

    My suggestion is:

    Please complete the DSP part of the application. When the DSP part is ready, you can proceed to the next step i.e. integrate DSPLink in your application. This involves usage of configuring DSPLink to use only PROC and NOTIFY, re-building DSPLink, using PROC API's to boot load, calling DSPLINK_init etc.

    Do not call DSPLINK_init before the GPP part is up. If you call DSPLINK_init without GPP part, it will wait forever for handshake to complete. There is no timeout as this handshake must successfully complete to ensure correct DSPLink run.

    Before you start work on the GPP part, you can go through the wiki at http://processors.wiki.ti.com/index.php/Category:BIOSLink.

    This wiki addresses many commonly asked questions like:

    http://processors.wiki.ti.com/index.php/Building_DSPLink

    http://processors.wiki.ti.com/index.php/Building_DSPLink_Applications#Method_3:_Building_a_DSPLink_application_using_a_CCS_project_file

    Deepali

  • 0 in reply to Deepali Uppal
    Intellectual 360 points

    Hi Deepali,

    in the meantime, i can download the DSP part via the GPP program and start the DSP program via PROC_start. But i have problems with DSPLink and interrupts.

    I have two interrupts which serve McASP and McBSP in my program. If i comment out DSPLINK_init, my program runs correctly. Audio data is transferred from McBSP to McASP via interrupts. If my program calls DSPLINK_init no audio data are transferred from input (McBSP) to output (McASP). I changed my program and give a sine wave to the output in a loop. No interrupt is used. This works with DSPLINK without problems.I can see the sine wave on the scope.

    I experienced with the program. First i try to output data in the McBSP interrupt and second, i try to output the sine wave via the McASP interrupt. I see that neither the McASP nor the McBSP interrupt works.

  • 0 in reply to Fjs
    Intellectual 360 points

    In the meantime i solved this problem. Downloading and starting a DSP program via DSPLINK is now possible.

  • 0 in reply to Deepali Uppal
    Prodigy 240 points

    Hello everyone,

    I don't know if I should start a new post for this. My dsplink issues are related to the configuration and APIs being discussed in this particular post, so I am just replying to Deepali's post. I am trying to set up a static system with minimal communication between the ARM and DSP for OMAP3530.  When running the configuration script for dsplink, I specify --comps=pn. However, the dsplink build fails with the following message:

     

    Building kernel side code using kbuild
    In file included from /home/dsplink_linux_1_65_00_03/dsplink/gpp/src/ldrv/MPCS/ldrv_mpcs_os.h:31,
                     from /home/dsplink_linux_1_65_00_03/dsplink/gpp/src/../../gpp/src/ldrv/Linux/ldrv_mpcs_os.c:37:
    /home/dsplink_linux_1_65_00_03/dsplink/gpp/inc/usr/mpcsdefs.h:196: error: 'MPCSOBJ_PROC_PADDING' undeclared here (not in a function)
    /home/dsplink_linux_1_65_00_03/dsplink/gpp/inc/usr/mpcsdefs.h:201: error: 'MPCS_TURN_PADDING' undeclared here (not in a function)
    /home/dsplink_linux_1_65_00_03/dsplink/gpp/inc/usr/mpcsdefs.h:228: error: 'MPCS_ENTRY_PADDING' undeclared here (not in a function)
    /home/dsplink_linux_1_65_00_03/dsplink/gpp/inc/usr/mpcsdefs.h:267: error: 'MPCS_CTRL_PADDING' undeclared here (not in a function)
    make[2]: *** [/home/dsplink_linux_1_65_00_03/dsplink/gpp/src/../../gpp/src/ldrv/Linux/ldrv_mpcs_os.o] Error 1
    make[1]: *** [_module_/home//dsplink_linux_1_65_00_03/dsplink/gpp/src] Error 2
    make: *** [debug] Error 2

    I can make this error go away if I configure dsplink with --comps=pons. My question is: Is it possible to configure dsplink to use only PROC and NOTIFY (no MPCS and POOL) When i opened the SOURCES file in $DSPLINK/gpp/src/ldrv/Linux, I saw that ldrv_mpcs_os.c is compiled unconditionally (that is, whether USE_MPCS is defined or not) Does the IPS and NOTIFY depend on MPCS at the lower-level?

    If someone could share their success/failure with this issue, it would be very helpful.

    Thank you in advance

     

     

  • 0 in reply to RH44284
    Prodigy 240 points

    Hello Everyone,

    The kbuild failure is still there.  I will look into the ips and ldrv_ips sources to see if I can get a clue. I hope someone from TI can confirm whether in the latest version of dsplink, the NOTIFY and PROC modules can be used independently of all the other modules. According to TI docs, this should be possible. But, I don't know if anything changed. Thank you all in advance.

     

    RH