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.

help with IPC needed

Other Parts Discussed in Thread: OMAPL138, SYSBIOS, OMAP-L138

hello there...

currently i'm trying to get IPC to work on an OMAPL138 system. with no luck at the moment.

on arm and dsp i'm using SYSBIOS 6.35.04.50. IPC version is 3.22.01.08.

my problems are completely at the beginning... during ipc_attach. i'm not able to sync the two cores. does anybody have a hint, where i could start searching.

i'm really helpless at the moment, as all the hints i extracted from e2e forums did'nt work for me...

thank you for your help

peter

my cfg files are as follows:

ARM:

5086.app.cfg

DSP:

8611.app.cfg

my sources for arm and dsp are as follows:

ARM:

Int main()
{ 
	Int status,slaveID,masterID;

	
	slaveID = MultiProc_getId("DSP");
	status = Ipc_start();

	if (status == Ipc_E_FAIL)
	{
	  System_printf("Ipc_start() failed core 0\n");
	  System_exit(0);
	}

    System_printf("Attaching to slaveId= %d..\n", slaveID);

    status = Ipc_attach(slaveID);

    while(status < 0)
	{
	   status = Ipc_attach(slaveID);
	}

 
    BIOS_start();    /* does not return */
    return(0);
}

DSP:

Int main()
{ 
Int status,slaveID,masterID;
status = MultiProc_self();
status = Ipc_start();

/*
* use ROV->SysMin to view the characters in the circular buffer
*/
System_printf("enter dsp main()\n");

masterID = MultiProc_getId("HOST");
System_printf("Attaching to masterId= %d..\n", masterID);
System_flush();
status = Ipc_attach(masterID);
while(status < 0)
{
//Task_sleep(1);
status = Ipc_attach(masterID);
}
System_printf("Attached to masterId= %d..\n", masterID);
System_flush();

BIOS_start(); /* does not return */
return(0);
}


  • Hi Peter,

    I'm just taking a look at this I'll let you know pretty soon when I come across something.

    Thanks,

    Moses

  • hi moses, 

    first of all i want to thank you for your help.

    just to clarify i'd like to depict my procedure for testing. maybe i'm doing something wrong here.

    in CCS5 i imported minimal project examples for arm and dsp (using platform ti.platforms.evmOMAPL138 for each of the projects).

    then i implemented code in *.cfg and *.c files and compiled without errors and warnings.

    in the next step i startet a debug-session with debug configuration EVMOMAPL138.ccxml (from one of the imported projects) using a XDS510 USB debugger.

    in debug-view first i connect to arm core, and load the .out file. then i connect to dsp core and load the .out file. next i start arm program execution and then dsp program execution.

    next thing i observe is the arm core stucking in 

    ti_sysbios_family_arm_exc_Exception_excHandlerAsm__I

    unfortunately i was not able to find the reason for this behaviour...

    am i doing something wrong here??? could it be the platform configuration or gel file for the debugger?

    i don't understand why these 5 essential code lines could make such a big problem ;)

    thank you for your help...

    peter

  • Peter,

    You need to find out why you are getting into the Exception handler code on the ARM processor.  It could be for a variety of things...just on top of my head...are there any MMU entries you need to setup?  Definitely, make sure you have the right gel files.

    So, I suggest the first thing make sure you can run a standalone BIOS app on the ARM and one on the DSP.  Then you could try the IPC programs.

    Judah

  • Peter,

    How is it going? I've attached a CCS 6 project which might help. It's a simple IPC example which runs on ARM and DSP using SYS/BIOS and IPC on both.

    However, I must state that Texas Instruments does not officially support IPC on OMAP-L138 with SYS/BIOS running on the ARM. We do support IPC when running Linux on the ARM.

    Here are some notes regarding the projects.

    1. I've created three projects. You need all three to run this example.

    hello_arm - ARM side project, builds ARM executable
    hello_dsp - DSP side project, builds DSP executable
    shared - eclipse project for shared files, does not build anything

    2. This example is very simple. It only illustrates the IPC configuration and a simple use of the Notify module. The DSP simply listens for a notify event. When received, it sends it back to ARM. The ARM drives the example, it sends a notify event to the DSP and then waits for the response. It does this ten times.

    3. The memory map is defined in shared/config.bld. This is referenced by both the ARM and DSP projects. Look at the project build properties.

    Project Properties > Build > XDCtools > Advanced Options
    Build configuration file: "${WORKSPACE_LOC}/shared/config.bld"

    To select the platform instance, I've specified its name in the build properties.

    Project Properties > General > RTSC
    Platform: ti.platforms.evmOMAPL138:dsp

    4. The common IPC configuration is in shared/ipc.cfg.xs. This ensures that both executables have the same configuration values.

    5. Shared Region #0 is cached from the ARM side, and non-cached from the DSP side.

    6. I used System_printf on ARM. Look in ROV > SysMin to see the output.

    7. I used LoggerBuf on DSP. Look in ROV > LoggerBuf to see the output.

    8. Use the following steps to load and run the example.

    ARM: load and run to main
    DSP: load and run to main
    ARM: run
    DSP: run
    ARM: halt
    DSP: halt

    Use ROV to inspect the logs.

    Let me know if you have any questions. Good luck.

    ~Ramsey

    OMAP-L138.zip
  • hello ramsey,

    thank you for your great effort! this provided example is really interesting. especially how you partition your projects and the part with the common memory map configuration is very interesting and helpful!!!

    i spent a lot of time to find out how this is done in a professional manner. but never found souch an simple and straight forward description and example which outlines how this is done correctly.

    thank you for your help! IPC is working now for me!!

    greets peter

  • Peter,

    Thank you for the nice reply.

    I made one small improvement to the hello_dsp program. In main_dsp.c, I changed the Event_Queue typedef to use Bits32 instead of UInt32 for the head and tail pointers.

    typedef struct
    {
        UInt32              queue[Event_QSZ];
        Bits32              head;
        Bits32              tail;
        Bool                error;
        Semaphore_Handle    sem;
        Semaphore_Struct    semObj;
    } Event_Queue;

    In most cases, this would not be important. However, the assumption is that the head and tail pointer size must be a power of two (e.g. 16-bits, 32-bits, 64-bits, etc). If the pointer size were to be 33-bits, then the logic in the code would fail.

    The type UInt32 does not guarantee an exact size of 32-bits, only a minimum size of 32-bits. The type Bits32 is guanranteed to be exactly 32-bits.

    ~Ramsey