IPC_Attach() gets into an indefinite LOOP.

vinodh rv

Intellectual 955 points

Hi ,

MCSDK version : 2.2.1.03

IPC : ipc_1_25_03_15

CCS : V5.5

Compiler : c6000_7.4.4

On trying out IPC communication module : IPC_attach is always getting into an indefinite loop state .

Am attaching the .CFG file along with this post .

Code Snippet :

void attachAll(Int numCores)
	{
    SharedRegion_Entry entry;

    Int i , status ;
    UInt16 clusterBaseId = MultiProc_getBaseIdOfCluster();

    /* Call Ipc_start() */
    status = Ipc_start();
               if (status < 0) {
                   System_abort("Ipc_start failed!\n");
               }
             System_printf("IPS START DONE\n");

    /* get region 0 information */
	 SharedRegion_getEntry(0, &entry);
	    System_printf("Shared region entry success\n");
	    /* if entry is not valid then return */
	    if (entry.isValid == FALSE) {
	        return;
	    }
	    System_printf("Shared region entry success: %d ||| %d\n",entry.ownerProcId,MultiProc_self());

	    /* Must attach to owner first to get default GateMP */
	    if (MultiProc_self() != entry.ownerProcId) {
	        do {
	            status = Ipc_attach(entry.ownerProcId);

	        } while (status < 0);
	    }

	    System_printf("attach done\n");

	    /* Loop to attach to all other processors */
	    for (i = clusterBaseId; i < (clusterBaseId+numCores); i++)
	    {
	        if ((i == MultiProc_self()) ||
	             (i == entry.ownerProcId)) {

	            continue;
	        }

	        if (Notify_numIntLines(i) == 0) {
	            continue;
	        }

	        /* call Ipc_attach for every remote processor */
	        do {
	            status = Ipc_attach(i);
	        } while (status < 0);
	    }

}

When i use

Ipc.procSync = Ipc.ProcSync_ALL;

IPC_start gets into a indefinite while loop . Is there any issue with the IPC_attach call procedure .

6523.cfg.docx

over 11 years ago

0 Ramsey over 11 years ago

TI__Genius 12025 points

Vinodh,

Overall, the attach code above looks correct. However, it should only be used with

Ipc.procSync = Ipc.ProcSync_PAIR

When using

Ipc.procSync = Ipc.ProcSync_ALL

you do not need to call Ipc_attach from your application. This function is called internally from Ipc_start. Your application should only call Ipc_start when using Ipc.ProcSync_ALL.

Furthermore, when using Ipc.ProcSyn_ALL, all the processors defined in the MultiProc name list but be participating at the same time. For example, if you have three processors in your system, but only two of them are calling Ipc_start, it will never finish until the third processor also calls Ipc_start.

The most common reason for Ipc_attach to fail is a mis-configuration between all the executables. If you are building different executables for each processor, then you must make sure they are all configured the same way. This includes the MultiProc configuration (i.e. name list), SharedRegion configuration (i.e. base address for SharedRegion #0) and Ipc configuration (i.e. Ipc.ProcSync_ALL).

In the code above, I see numCores is passed in as parameter to the function. It would be better to use the MultiProc_getNumProcessors function.

What device are you using?
Are you building one DSP executable for all processors?
How are you loading and running the DSP?

~Ramsey

0 vinodh rv over 11 years ago in reply to Ramsey

Intellectual 955 points

Thank you Ramsey ,
Am using Ipc.procSync = Ipc.ProcSync_PAIR for above code.
For testing we are grouping the two DSP core["CORE0" & "CORE1"] and loading different executable in each core .

in the above code snippet :
Int numCores ;
numCores = MultiProc_getNumProcessors();

and am passing this numCores to the Attach_all() function.
The MultiProc configuration (i.e. name list), SharedRegion configuration (i.e. base address for SharedRegion #0) and Ipc configuration (i.e. Ipc.ProcSync_PAIR) is same in both the code's .cfg file.

- Vinodh

0 Ramsey over 11 years ago in reply to vinodh rv

TI__Genius 12025 points

Vinodh,

Another typical handshake failure reason is incorrect cache configuration for the shared region. Make sure that the SharedRegion cache configuration is consistent with the actual memory configuration. For example, if SR#0 is in cacheable memory, then you must configure the SharedRegion cacheEnable property to 'cacheEnabled'. From looking at your config script, it looks like you are already doing this, but it's worth double-checking this.

At this point, I would use the RTSC Object Viewer (ROV) tool in CCS to inspect various module configuration values. In particular, I would check the following on both processors.

MultiProc > ID
MultiProc > name list
SharedRegion > owner
SharedRegion > base
SharedRegion > free heap size (make sure the region is not too small)

Another good sanity check is to view the beginning of SR#0 in a memory window from both processors. Make sure the view is consistent. In other words, if one processors writes its handshake value into SR#0, make sure the other processor can see it. For your configuration, I would guess that each handshake row is 128 bytes long. Since you have two processors, there should be two rows. The rows start at the beginning of SR#0.

What device are you using?
How are you loading your programs?

~Ramsey

0 vinodh rv over 11 years ago in reply to Ramsey

Intellectual 955 points

Hi Ramsey ,

# Shared Region Cache is enabled in both core program

# I validated the following values using ROV and they are fine.

MultiProc > ID ;MultiProc > name list ;SharedRegion > owner ; SharedRegion > base ;SharedRegion > free heap size (make sure the region is not too small).

# beginning of SR#0 in memory window is same for both processors. (i,e) values in the memory location is consistent.

In case if i use

Ipc.procSync = Ipc.ProcSync_ALL;

code is getting stuck in the IPC_start() .

# localQueueName and nextQueueName values also validated.

# Am using TI 6614 and am loading the program using CCS 5.5 .

vinodh

0 Ramsey over 11 years ago in reply to vinodh rv

TI__Genius 12025 points

Vinodh,

From your reply above, it sounds like you are using Ipc.procSyn = Ipc.ProcSync_ALL. If this is the case, your application should not be calling Ipc_attach. It should only be calling Ipc_start. Please verify this.

When using ProcSync_ALL, all the processors configured into your MultiProc must be participating at the same time. In other words, if you have four processors in your MultiProc configuration, then all four processors must be calling Ipc_start at the same time. If only three are calling Ipc_start, it will spin until the fourth processor also calls Ipc_start.

Let's have a look at your MultiProc configuration. I believe your device has a total of four DSP C66x processors and one ARM Cortex-A8 processor. Is this correct?

What operating system are you running on the ARM?

From your description so far, it sounds like you just want to load CORE0 and CORE1. You want to make IPC calls between just these two processors. Correct? You don't plan to communicate with the ARM.

Your MultiProc configuration should look like this:

/* configuration for CORE0 */
var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
MultiProc.setConfig("CORE0", [ "CORE0", "CORE1" ];

/* configuration for CORE1 */
var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
MultiProc.setConfig("CORE1", [ "CORE0", "CORE1" ];

Please note that the name list must be identical for both processors. The only difference is the name of the current processor.

In ROV, when you look at MultiProc, you should only see these two processors. If you see CORE2, CORE3, or HOST, then it is incorrect.

In ROV, the Ipc module should show you which processors you have attached to. What does this show?

~Ramsey

Processors

Processors forum

IPC_Attach() gets into an indefinite LOOP.