How to get DSP address - OMAP L138

Kiran,

Are you trying to figure out the DSP address in the memory map of the DVSDK? While compiling the DSP side code you can generate a map file using linker options and can see the exact location where each section of your DSP binary gets loaded. In general the DVSDK for OMAPL138 follows the memory map that is mentioned here:

http://processors.wiki.ti.com/index.php/DVSDK_4.x_MemoryMap

It wasn`t very clear to me which example you were referring to inside the DVSDK. Perhaps if you provide the path to the example, I can provide you some pointers.

Regards,

Rahul

Hi Rahul,

My basic requirement is to get data from a specific memory location in the DSP address space.

These memory location could be the addresses of global variables, function start address, some buffer address etc. which are defined in my DSP code.

I know that i can use PROC_read/PROC_write to access any specific memory location in DSP.

Now i am trying to use the PROC_GetSymbolAddress() function to get the DSP address of some symbol which is part of the DSP code. Let me know if this is the right thing to do for the above mentioned scenario.

Looks like I am not able to figure out how to use the PROC_GetSymbolAddress() function probably. There dont seem to be any example code available in DVSDK for this. Can you point me to some reference code on its usage.

Thanks,

Kiran Kumar

Hi Kiran:

   1) Getting the DSP address of a symbol:

       As Rahul mentioned, you could either

       a)  generate the DSP .map file and look up the address from the .map, or

       b) call PROC_getSymbolAddress().   If PROC_getSymbolAddress() is failing, what error code do you get?  What trace messages are generated?

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

     Assuming symbols aren't stripped from the executable (See: http://processors.wiki.ti.com/index.php/Using_a_symbol_stripped_DSP_executable_with_DSPLink ), the COFF symbol table should be available after loading.

     Also, what version of DSPLINK are you using?

   2) Example.

     I wasn't able to find an explicit example for your scenario, but it seems PROC_read() should do the job (once you have the address).

- Gil

Hi Gil/Rahul,

Thanks for the reply.

I am able to read the data content of the symbol address using PROC_read(). However I am unable to see the function symbol addresses in the *.map file.

How will I find the function addresses? so that I can get the control of the DSP program counter and try to jump to that particular location, is this possible? if yes, please let me know the steps/API's to be used.

Regards,

Kiran Kumar

Hi Kiran:

>  My basic requirement is to get data from a specific memory location in the DSP address space.

   So, it seems you have succeeded to get a (global variable) symbol's address using PROC_getSymbolAddress() and read its data using PROC_read(), correct?

   If so, you should be able to get the (function) symbol's address as well.

   Ensure the symbol address is global (not declared static), so it will show up in the .map file.  Then you should be able to successfully reference the function symbol from another C file with an extern <type> global_func() declaration.

    However, I don't think you can control the DSP PC directly from the ARM side.  One could poke a new boot address and then reset the DSP to start from that new address, but it's not very efficient.

   Allow me to suggest another design: Since we already know the address on the DSP side, you could write a small DSP server that the ARM notifies with a command payload to jump to any address (i.e., call a DSP function), from the DSP side.

   For example, you could load a DSP server that waits for a function ID payload from an ARM side notification (see NOTIFY_notify), then calls the associated function from an <funcID, functionPtr> look up table.

- Gil

Hi Gil,

Thanks for the suggestions.

Yes, I am able to get the function addresses using PROC_GetsymbolAddress().

However, I don't think you can control the DSP PC directly from the ARM side.  One could poke a new boot address and then reset the DSP to start from that new address, but it's not very efficient.

Can you please help me with a sample program? or the set of API's which can be used for implementing the above.

Regards,

Kiran Kumar

Kiran:

     If you need to stay with DSPLink, there is an example in: /dsplink/dsp/src/samples/message/tskMessage.c, which implements a loop in TSKMESSAGE_execute() which can be adapted to receive a message from the host, carrying a function index into a function pointer table, and call the function.   If you need to pass arguments to the function, you could also place them in the message, and return results in the return message back to the host.

    If you just need IPC, and don't need to stick with the DVSDK, you could also upgrade to SysLink 2 (the successor of DSPLink): http://processors.wiki.ti.com/index.php/SysLink_FAQs

     There is an example in the SysLink product, in examples/archive/OMAPL138_linux_elf/ex02_messageq/dsp/Server.c, which shows essentially the same thing: how to await a message from the host, process it (see adaptation below ), and return a result to the host.
   

      This is just the DSP side, and just a suggestion assuming all you want is a simple server:

      You could do the same thing with DSPLink MSGQ as well...

==== Server.c====

/* import your known DSP functions: */

extern  int myFunc1(void);
extern  int myFunc2(void);
extern  int myFunc3(void);

typedef int (*MyFxnType)(void);

/* Set up a function table */
static MyFxnType funcTable[NUMFUNCS] = {
     myFunc1, myFunc2, myFunc3,
};

/*
 *  ======== Server_exec ========
 */
Int Server_exec()
{
    Int                    status;
    Bool                running = TRUE;
    App_Msg *     msg;
    MessageQ_QueueId    queId;
    MyFxnType    fptr;

    Log_print0(Diags_ENTRY | Diags_INFO, "--> Server_exec:");
    while (running) {
        /* wait for inbound message */
        status = MessageQ_get(Module.videoQue, (MessageQ_Msg *)&msg, MessageQ_FOREVER);

        /* process the message */
       if ('msg->cmd is valid') {
            fptr = funcTable[msg->cmd];
            msg->result = (*fptr)();
            Log_print1(Diags_INFO, "Server_exec: processed cmd=0x%x", msg->cmd);
       }

        /* send message back */
        queId = MessageQ_getReplyQueue(msg); /* type-cast not needed */
        MessageQ_put(queId, (MessageQ_Msg)msg);
    } /* while (running) */
}

Hello Gil,

Thanks for the reply, I took sometime to come back was doing some development.

I am trying to change a global variable on DSP and I am stuck since the change in variable data is not taking effect. I am trying to write a small piece of code to blink the LED on DSP side, wherein I will change the value for number of times LED to Blink from ARM side application.

Below is the code:

volatile char src[2]={1,10};

Void main(Int argc, Char *argv[])
{
    int i, j;
    char count;

    /* TSK based loopback */
    TSK_Handle tskLoopTask;

    /* Initialize DSP/BIOS LINK. */
    DSPLINK_init () ;

LedInit();
    while(1)
    {
        if(src[0] == 1){

        led_blink(src[1])

         }

     }

}

I am changing the src[ ] array values from GPP(ARM) side but I see the values are changing when read back but dont see the led blinking as expected.

Please help me.

one more thing to add:

Can I use the DVSDK compiling source code to CCS?. I tried but there are lot of library mis-matches. Please clarify on how to compile the code on CCS and then load output files on OMAPL138 without JTAG?.

Thanks,

Kiran Kumar

Kiran:

    First Question:

    It seems your DSP side is cached.   You may need to flush the cache to see the actual value of your shared variable.

    See this link: http://processors.wiki.ti.com/index.php/Cache_Management

    You can either 1) Disable cache for the memory region in which your shared variable resides; or 2) perform Cache operations on the Sys/BIOS side.

    See the BIOS User's Guide, Section 6.6 Cache Configuration:

    http://www.ti.com/lit/ug/spruex3k/spruex3k.pdf

    You can also search these e2e forum posts:  Google  "site:e2e.ti.com OMAPL138 MAR bits cache" for more hints.

    For your second question, could you be more specific on what you're trying to do?  In general, it should be possible to compile any application in CCS, and load using for example the SysLink SlaveLoader application.

Dear Gil,

Now I am trying to build the DSPLINK examples using CCS. However I have set of questions to ask.. :(

1. Which CCS version is been supported for OMAPL138?. I am using CCS Version: 4.0.2.01003.

2. I am unable to compile with the links provided by you, I get the below error.  I tried to compile by using the dsplink libraries of OMAP-L138_dsp_1_00_00_11 version, downloaded from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/omap_l138/1_00/latest/index_FDS.html.

"../swiLoop.c", line 51: fatal error: could not open source file "std.h"
1 fatal error detected in the compilation of "../swiLoop.c".
Compilation terminated.

"../loop_config.c", line 44: fatal error: could not open source file "dsplink.h"
1 fatal error detected in the compilation of "../loop_config.c".

Please help me on compiling the dsplink applications from CCS, I dont know where I am going wrong I am newbie to this CCS, dont mind if I am asking basic questions.

Thanks,

Kiran Kumar

Kiran:

   Your compiler include path is missing the "-I <include>" option pointing to where those header files are.

   Did you use Method 1 or Method 2 in these instructions?  http://processors.wiki.ti.com/index.php/Building_DSPLink_Applications#Method_3:_Building_a_DSPLink_application_using_a_CCS_project_file

   If Method 1, then you take the value of TI_DSPLINK_DSP0_INC_PATH from the $DSPLINK/config/BUILD/CURRENTCFG.MK file after having run the dsplinkcfg script, in insert it into your build options.

   Any version of CCS should work, though the location of the Build Options dialog box changes in CCS from version to version.

   Did you try to import the existing CCS v3 project into CCS v4 and then update the search path options?

   You can consult the CCS help file to see how to add search paths to the compiler.

   The last link in my last post had some good advice:

                "5.2  After this I clicked on the "Include Options" under the C600 Compiler tab on the left.  Then I inserted all the include files based on all the paths specified in

                     the   TI_DSPLINK_DSP0_INC_PATH variable in CURRENTCFG file (${DSPLINK Directory)\config\BUILD)"

Hi Gil,

I am trying to compile the dsp example located at "C:\OMAP-L138_dsp_1_00_00_11\dsplink_linux_1_65_00_02\dsplink\dsp\src\samples\readwrite" using Method-1

I tried the link suggested in your last post, and included all the paths (TI_DSPLINK_DSP0_INC_PATH) specified in CURRENTCFG.MK

But, below list of files were missing from my "C:\OMAP-L138_dsp_1_00_00_11\dsplink_linux_1_65_00_02\dsplink" path which were mentioned in CURRENTCFG.MK

${DSPLINK}/dsp/inc/DspBios/DA8XXGEM

${DSPLINK}/dsp/src/base/hal/DspBios/5.XX

${DSPLINK}/dsp/src/base/hal/DspBios/5.XX/DA8XXGEM

${DSPLINK}/dsp/src/base/drv/DspBios/5.XX

and so on for all the path for 5.XX

I, any how compiled it by defining  TI_DSPLINK_DSP0_DEFINES and TI_DSPLINK_DSP_COMMON_DEFINES also.

Now i get an error in the Linking stage (seen below).

Can you please give me some pointers on what could be the problem and how i can resolve this issue.

Thanks,

Kiran Kumar

warning: creating output section ".bss" without a SECTIONS specification
warning: creating output section ".cinit" without a SECTIONS specification
warning: creating output section ".const" without a SECTIONS specification
warning: creating output section ".far" without a SECTIONS specification
warning: creating output section ".stack" without a SECTIONS specification
warning: creating output section ".text" without a SECTIONS specification
warning: creating ".stack" section with default size of 0x400; use the -stack
   option to change the default size
"../DspBios/6.XX/DA8XXGEM/readwrite.cmd", line 48: warning: memory range not
   found: SDRAM on page 0
"../DspBios/6.XX/DA8XXGEM/readwrite.cmd", line 48: error: program will not fit
   into available memory.  placement with alignment fails for section
   ".data:DSPLINK_shmBaseAddress" size 0x0
"../DspBios/6.XX/DA850GEM/readwrite.cmd", line 48: warning: memory range not
   found: SDRAM on page 0
"../DspBios/6.XX/DA850GEM/readwrite.cmd", line 48: error: program will not fit
   into available memory.  placement with alignment fails for section
   ".data:DSPLINK_shmBaseAddress" size 0x0
"../DspBios/5.XX/OMAPL1XXGEM/readwrite.cmd", line 48: warning: memory range not
   found: SDRAM on page 0
"../DspBios/5.XX/OMAPL1XXGEM/readwrite.cmd", line 48: error: program will not
   fit into available memory.  placement with alignment fails for section
   ".data:DSPLINK_shmBaseAddress" size 0x0
"../DspBios/5.XX/OMAPL138GEM/readwrite.cmd", line 48: warning: memory range not
   found: DDR on page 0
"../DspBios/5.XX/OMAPL138GEM/readwrite.cmd", line 48: error: program will not
   fit into available memory.  placement with alignment fails for section
   ".data:DSPLINK_shmBaseAddress" size 0x0

 undefined                                   first referenced      
  symbol                                         in file           
 ---------                                   ----------------      
 _BCACHE_inv                                 ./tskReadwrite.obj    
 _BCACHE_wbInv                               ./tskReadwrite.obj    
 _DDR                                        ./tskReadwrite.obj    
 _DSPLINK_init                               ./main.obj            
 _FXN_F_nop                                  ./readwrite_config.obj
 _LOG_printf                                 ./tskReadwrite.obj    
 _MEM_calloc                                 ./tskReadwrite.obj    
 _MEM_free                                   ./tskReadwrite.obj    
 _MSGQ_ATTRS                                 ./tskReadwrite.obj    
 _MSGQ_close                                 ./tskReadwrite.obj    
 _MSGQ_get                                   ./tskReadwrite.obj    
 _MSGQ_locate                                ./tskReadwrite.obj    
 _MSGQ_open                                  ./tskReadwrite.obj    
 _MSGQ_put                                   ./tskReadwrite.obj    
 _SMAPOOL_FXNS                               ./readwrite_config.obj
 _SMAPOOL_init                               ./readwrite_config.obj
 _TSK_create                                 ./main.obj            
 _ZCPYMQT_FXNS                               ./readwrite_config.obj
 _ZCPYMQT_init                               ./readwrite_config.obj
 _ti_sysbios_ipc_Semaphore_Object__create__S ./tskReadwrite.obj    
 _ti_sysbios_ipc_Semaphore_pend__E           ./tskReadwrite.obj    
 _ti_sysbios_ipc_Semaphore_post__E           ./tskReadwrite.obj    
 _ti_sysbios_knl_Task_sleep__E               ./tskReadwrite.obj    
 _trace                                      ./tskReadwrite.obj    

error: unresolved symbols remain
error: errors encountered during linking; "readwrite.out" not built
C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake: *** [readwrite.out] Error 1
C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake: Target `all' not remade because of errors.

Kiran:

   It appears some macros are not being defined properly in the configuration of DSPLink, which is causing you to add some wrong libraries and paths to the CCS Build options.

   The unresolved symbol errors imply the BIOS v 6 libraries are getting set in the Linker tab, and DSPLink libraries are missing.

   The memory map errors may also be the result of choosing the wrong platform.

   Maybe you have a "--dspos_0=DSPBIOS6XX" defined somewhere in the configuration?

   I would clean out the DSPLink build configuration files, and follow carefully the instructions in the DSPLink UserGuide, Section 9.3, on   "DSPLink Build Configuration".

   Additionally, look at the Build Option paths and libraries, to make sure you are getting the right libraries in.   See the detailed steps here also:

http://processors.wiki.ti.com/index.php/CCS_Project_OMAP-L137_HelloDSP_DSPLINK_example

Regards,

- Gil

Dear Gil,

Thanks for the reply, I am able to reduce the error to expect below some redefined errors.

I don't know where I am going wrong but it is very much cumbersome method to compile a project on CCS 5.2 :(.

undefined first referenced
symbol in file
--------- ----------------
_DSPLINK_init ./main.obj
_SMAPOOL_FXNS ./message_config.obj
_SMAPOOL_init ./message_config.obj
_ZCPYMQT_FXNS ./message_config.obj
_ZCPYMQT_init ./message_config.obj

error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "trying_new.out" not built

Can you please provide me any documents which covers the exact procedure to compile predefined samples for example $(DSPLINK)/dsp/src/sample/readwrite, application

Regards,

Kiran Kumar

Hi Arnie/Gil,

I am able to compile the DSPLINK sample applications :).... thanks for the reply... However I am not very clear on the usage of template... since I am using now 

New CCS Project -> DSP/BIOS v5.xx Examples -> evmOMAPL138 Examples ->hello Example.

Is the above approach correct?. I am asking this question because we have to run the compiled code on our customized board having OMAPL138 and not on evmOMAPL138. When I tried to run the compiled code on our board it is giving some weird errors and the *.tcf file is also not as expected.

One more question:

I want to extract the symbols from the *.out file generated. When I checked the file format of the *.out created using DVSDK/CCS is of data format. Please find below.

user-desktop:~/ti-dvsdk_omapl138-evm_04_03_00_06/dsplink_1_65_01_05_eng/dsplink/dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/RELEASE$ file loop_new.out
loop_new.out: data

user-desktop:~/ti-dvsdk_omapl138-evm_04_03_00_06/dsplink_1_65_01_05_eng/dsplink/dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/RELEASE$ objdump -r loop_new.out
objdump: loop_new.out: File format not recognized

Please suggest me on how to create *.out file having symbols in it or how to extract the symbols from the *.out created.

Thanks,

Kiran

Dear Arnie,

Thanks for the reply. I am able to extract the symbols from *.out file and also I am able to run the *.out file created in CCS5 on to the board as expected. One last question may be :).. is there any possibility to create a template of our own on CCS?.. As I dont want to add all the libraries, predefined symbols and linker paths on creation of every new project.

Kindly advice.

Thanks,
Kiran Kumar

When DspLink has been configured and build, you'll find a few useful files that will simplify the include and defines need  in the following files:

# Set defines required by DSP/BIOS Link, leveraging file created by Link's build
DSPLINK_DEFINES = $(shell cat $(LINK_INSTALL_DIR)/dsplink/dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/IPS_defines.txt)

# Set include paths required by DSP/BIOS Link, leveraging file in Link's build
DSPLINK_INCLUDES = $(shell cat $(LINK_INSTALL_DIR)/dsplink/dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/IPS_includes.txt)

You can leverage these file by adding them in your DSP-side build within CCS.

You can then added an additional linker command file to your project that only include the dsplink libraries needed that you can reuse.

===== myDspLinkApp.cmd ======

/* DSP/BIOS LINK libraries */
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplink.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinkdata.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinkmpcs.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinkmplist.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinkpool.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinkringio.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinknotify.lib"
-l"dsp/export/BIN/DspBios/OMAPL138/OMAPL138GEM_0/DEBUG/dsplinkmsg.lib"

If you have a DVSDK installatio,n take a look at the audio_soc example.  This application leverages the method outlined above to build the Dsp-side thought it uses GNU makefiles to build.  You should be able to do the same within a CCS project.