IPC 1.21.02.23: linking GateHWSem and peers

Ram R

Intellectual 420 points

All

Here is my configuration:

{ CCS: Version: 4.2.0.10017 / CGTools: 7.0.4 / SYS/BIOS 6.30.02.42 / IPC 1.21.02.23}

I am using the message_single example for C6472 as boiler-plate.

It seems like including the IPC package does not pull in the link dependency for ti.sdo.ipc.gates(?)

I also tried changing the platform from ti.sdo.ipc.examples.platforms.evm6472.core0 to ti.platforms.evm6472, but, no luck.

------------------------------------------------------------------------------------------------------

undefined                                     first referenced
symbol                                           in file
---------                                     ----------------
_ti_sdo_ipc_gates_GateHWSem_Object__create__S ./message_single.obj
_ti_sdo_ipc_gates_GateHWSem_Params__init__S   ./message_single.obj

error: unresolved symbols remain
error: errors encountered during linking; "test4.out" not built
------------------------------------------------------------------------------------------------------

I even tried adding the library explicitly as follows, but no luck.

If memory serves, the 7x toolchain default is COFF... and I've confirmed that the archive has the required symbols and is COFF as well

'Building target: test4.out'
'Invoking: Linker'
"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.0.4/bin/cl6x" -mv64+ -g --diag_warning=225 -z -m"test4.map" --warn_sections -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.0.4/lib" -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.0.4/include" --reread_libs --rom_model -o "test4.out" -l"./configPkg/linker.cmd" "./message_single.obj" -l"libc.a" -l"C:\Program Files\Texas Instruments\ipc_1_21_02_23\packages\ti\sdo\ipc\gates\lib\whole_program_debug\ti.sdo.ipc.gates.a64P"

A quick response is greatly appreciated.

Thanks!

over 14 years ago

0 Karl Wechsler over 14 years ago

TI__Mastermind 20805 points

try adding the following line to your .cfg script.

xdc.useModule('ti.sdo.ipc.gates.GateHWSem');

Regards,
-Karl-

0 Shreyas Oppanthaya over 14 years ago in reply to Karl Wechsler

Genius 4375 points

Actually, the GateHWSem module should never be used with the C6472 device. Have you made any modifications at all to the 'stock' example? I'd like to figure out who is pulling in that module. Could you post your .cfg file and other relevant files so I can check them out?

Regards,

Shreyas

0 Ram R over 14 years ago in reply to Shreyas Oppanthaya

Intellectual 420 points

Is that because the device does not support a HW Sema? Now that you mention it, perhaps there was something to that effect in the documentation or forums(?)... I cant remember.

Perils of working into the wee hours of the morning - I realized that I'd missed adding relevant info in the cfg file - good catch!

And then, the system does error out during validation saying that HW Sema is not supported for C6472.

Please clarify the recommended (or only?) way to do interprocessor sync (AAMonitor seems link now) for C6472. Can you please point me to an example of how to use these?

Here is what I'm thinking:

Looks like you need region0 in SL2 (C6472 constraint) - which I already do per message_single cfg template.

I'm not sure of the order of calling Params_init() and sharedMemReq() to setup params.resourceId and params.sharedAddr

Looks like I also need a HeapBufMP, HeapMemMP or variant to allocate memory

Best

Ram

0 Shreyas Oppanthaya over 14 years ago in reply to Ram R

Genius 4375 points

Normal 0 false false false MicrosoftInternetExplorer4

You are right--the C6472 uses atomic access monitors (GateAAMonitor) for locks and not hardware semaphores.

You actually don't typically use the device-specific gate modules (GateHWSem, GateHWSpinlock, GateAAMonitor) directly in your application. These modules are helper modules for the GateMP module whose instances can be created and opened using a name just like any other IPC instance (Heap*MP, ListMP, etc). The GateMP module automatically chooses the gate delegate module based on the build device. The GateMP also automatically manages the hardware resources for your particular gate delegate, so you never have to configure any resource IDs, etc. This design allows your application to be easily ported to other devices (i.e. C6474, etc) without knowledge of the locking mechanism on the device.

Depending on your use-case, you can avoid the step/overhead of creating/opening an instance by retrieving a handle to the default system GateMP instance that was created internally during the Ipc_start initialization sequence. The handle can be retrieved using the GateMP_getDefaultRemote() API.

Refer to section 3.6 in the IPC users guide for general information about the GateMP module. You can refer to the doxygen supplied with IPC for information about the GateMP runtime APIs.

Lastly, regarding your heaps question--

Similar to the system GateMP instance, a HeapMemMP (variable-length MP heap) is automatically created in Ipc_start to manage the memory contained with SharedRegion #0. You can retrieve a handle for this heap using the SharedRegion_getHeap API. You can opt to create your own heap within that existing SharedRegion heap to perhaps better partition the shared memory or to create a HeapBufMP (fixed-length MP heap).

0 Ram R over 14 years ago in reply to Shreyas Oppanthaya

Intellectual 420 points

OK. I got it.

I've been using the Ipc/MessageQ module and examples...

I was looking for a way to use multi-processor sync/lock to share a HW resource.

For some reason I zeroed in on cdoc for ti.sdo.ipc.gates instead of ti.sdo.ipc.GateMP proxy.

I'll take a look and let you know if there are more questions.

Processors

Processors forum

IPC 1.21.02.23: linking GateHWSem and peers