Failed to open HeapBufMP_open in multicore application

Is HeapBufMP_open is your custom function or provided by PDK.

Thanks,

Arun.

What is your MultiProc list? I mean the line of the cfg file that looks similar to:

MultiProc.setConfig(null, ["CORE0", "CORE1"]);

What is the synchronization you are using for the IPC module? (also found in the cfg) procSync_ALL, PAIR, or NONE?

Twentz,

For two cores, we use

MultiProc.setConfig(null, ["CORE0", "CORE1"]);

and for 8 cores

MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2", "CORE3", "CORE4", "CORE5", "CORE6", "CORE7"]);

We set the number of processors accordingly.

For IPC, procSync_ALL is used for synchronization. IPC_Start returns success.

Arun,

This function is provided by ti.sdo.ipc.heaps.HeapBufMP of IPC installation.

Thanks,

Lijo

Hmm, it'd probably be best if you post your cfg file for my following questions:

If you are familiar with the ROV tool, then that should be able to help you greatly.  It is one of the tools in one of the dropdown menus while you are debugging.  Once you load it, the NameServer and HeapBufMP modules should give you some helpful information while debugging this.

Are you sure you are setting up Notify correctly? HeapBufMP_open uses NameServer, and I believe the default NameServer RemoteTransport for your IPC version uses Notify.  In other words, make sure you do not have this in your cfg:

(I can't remember the exact syntax)

Ipc.setMeta{

...

setupNotify: false

}

Since you [correctly] specify the first argument in MultiProc.setConfig as "null" are you making a call to MultiProc.setLocalId(DNUM); (or some other core identifier) early in the program? Or if MultiProc returns the correct ID, then that should be fine.

Twentz,

I tried to use ROV as per your suggestion.

I am able to see the HeapBufMP properties for Core 0 after calling HeapBufMP_create.

But for Core1, It is not displaying any content as HeapBufMP_open didnt return.

I havent configured the setupNotify in the configuration file.

Should we call MultiProc.setLocalId(DNUM); to set the proc id?

Thanks,

Lijo

Clearly HeapBufMP will return that information -- that is why you need to check the NameServer module and the Notify module to see if there are "pending messages" or similar details.

Ipc_start by default sets up Notify on the processors it attaches to (which is why specifying procSync_ALL is important) -- so as long as you haven't told the IPC module to *not* set it up, it should be fine the way it is.

The local ID needs to be set -- but this is very often done correctly by default without calling MultiProc_setLocalId.  You can verify that each core is returning the correct ID by checking value returned by MultiProc_getId(). If this is not true, then you *would* need to set the ID manually, possibly even in start-up functions before main().  However, this is probably unnecessary and the ID is probably correct already.

I can't think of any difference in the newer MCSDK that would break anything dealing with IPC.  Are you sure there aren't any problems at compilation? Could you also try building and running the IPC MessageQ example? (found when you go to create a new project).  That example has a configuration that you should be able to contrast your current one with.

Hi,

There was a bug against SYSBIOS that was released with 2.0.1 release. We think that the issue you are facing could be related to this bug.

BUG ID# :SDOCM00083648    CpIntc host ints are incorrect for C6678 and C6670

This is fixed in SYSBIOS 6.32.04.49.

We integrated this version of sysbios in 2.0.2 release of BIOS MCSDK. Can you please download 2.0.2 BIOS MCSDK release and see if resolves the problem?

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html 

-thanks,

Aravind

I installed MCSDK 2.0.2 and tried. The behaviour seems same. In our application, call to HeapBufMP_open hangs and core1 get into idle loop.

I tried setting the ProcID in EVM_init function as well.

The messageQ test application in IPC works fine. The call to HeapBufMP_open returns successfully and I was able to see the information in ROV.

_{Hi Lijo Jose,}

_{The BIOS/IPC team is looking on to this issue.}

_-Thanks,

_Aravind

Since the messageQ test application is working for you the initial though that the problem was related to SDOCM00083648 is incorrect.  This problem only effects CPINTC interrupts which the IPC interrupt is not.

Could you attach your .cfg file here?

Are you running the app on all 8 cores or just core 0 and core1?  If you are having the problem on all 8 cores, could you try it on just 2 cores and see if you have the same problem?  When you say HeapBufMP_open() hangs, where is the Program when it hangs?

As someone previously states that a open() does a NameServer requests to another core and pends on a Semaphore waiting for a response from the remote core.  If the interrupt never comes through, the Task is blocked on the Semaphore.

Judah

In the meantime, a work-around that is independent of these possible problems with NameServer/IPC interrupts is if you use HeapBufMP_openByAddr:

1) Set aside & initialize a word (preferably an entire cacheline) in shared memory

2) Core0 creates the HeapBufMP

2.5)  Other cores poll on the reserved word (invalidating as needed)

3) Core0 writes (and performs a writeback of) the address of the HeapBufMP to the word in shared memory (may need to use SharedRegion's address translation)

4) Other cores read the address that was written to the word and use this in HeapBufMP_openByAddr

This should get your application running and would also isolate the problem to the underlying method or configuration of HeapBufMP_open (not by addr)

Hi,Lijo

Can you tell me how to avoid tht EVM_init() for all cores other than core 0?

Thank you!

Regards

In my case, we call EVM_init(). Inside that, if the core_id is not 0, then, it will return without further processing inside evm_init().

regards,

Lijo