Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hello again,

I've just realized the line "ISTP = (unsigned int)_intcVectorTable;" in {StarterWare}/system_config/c674x/interrupt.c appears to be what breaks the Notify module. The symbol _intcVectorTable is defined in {StarterWare}/system_config/c674x/intvecs.asm, but I have no clue about why ever "initializing the vector table" would break the IPC interrupts. Any ideas?

(I know Critical Link doesn't support SysLink at the moment, but I'm hoping someone might give me a piece of advice or notice an obvious mistake I've been making.)

Okan

Hi Okan,

My guess is that your core problem is that SysLink and StarterWare simply do not play well together in general. My understanding of StarterWare is that it is intended as a means for the DSP to run independently. Therefore, during the DSP's setup it may be configuring interrupts to make sure the ARM cannot ever interrupt the DSP (See 11.4.3 in the L138 TRM (http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf) for additional details on the interrupt for DSP-ARM communications). Since you have two opposing environments (SysLink and Startware), the setup of one is always contending with the other.

In order to resolve this I would recommend reading up on the L138's interrupts and porting the necessary portions of your StarterWare based application to SysLink.

Thanks,
\Greg

Hi Greg,

I've already read the relevant sections of the technical reference manual and megamodule reference guide, but I still have no idea how the Notify module initializes its interrupts. The function Notify_registerEventSingle() just takes lineId and eventId as input arguments, and inside, its content has nothing to do with cpuINT [4..15] and sysINT [0..127].

Here, have a look:

Int Notify_registerEventSingle(UInt16                 procId,
                               UInt16                 lineId,
                               UInt32                 eventId,
                               Notify_FnNotifyCbck    fnNotifyCbck,
                               UArg                   cbckArg)
{
    UInt32        strippedEventId = (eventId & 0xFFFF);
    UInt16 clusterId = ti_sdo_utils_MultiProc_getClusterId(procId);
    UInt          modKey;
    Int           status;
    ti_sdo_ipc_Notify_Object *obj;

    Assert_isTrue(procId < ti_sdo_utils_MultiProc_numProcessors && 
            lineId < ti_sdo_ipc_Notify_numLines, ti_sdo_ipc_Notify_A_invArgument);
    Assert_isTrue(strippedEventId < ti_sdo_ipc_Notify_numEvents, 
            ti_sdo_ipc_Notify_A_invArgument);
    Assert_isTrue(ISRESERVED(eventId), ti_sdo_ipc_Notify_A_reservedEvent);

    modKey = Gate_enterModule();

    obj = (ti_sdo_ipc_Notify_Object *)
            Notify_module->notifyHandles[clusterId][lineId];

    Assert_isTrue(obj != NULL, ti_sdo_ipc_Notify_A_notRegistered);

    if (obj->callbacks[strippedEventId].fnNotifyCbck) {
        /* A callback is already registered. Fail. */
        status = Notify_E_ALREADYEXISTS;
    }
    else {
        /*
         *  No callback is registered. Register it. There is no need to protect
         *  these modifications because the event isn't registered yet.
         */
        obj->callbacks[strippedEventId].fnNotifyCbck = (Fxn)fnNotifyCbck;
        obj->callbacks[strippedEventId].cbckArg = cbckArg;

        if (procId != MultiProc_self()) {
            /* Tell the remote notify driver that the event is now registered */
            INotifyDriver_registerEvent(obj->driverHandle, strippedEventId);
        }

        status = Notify_S_SUCCESS;
    }

    Gate_leaveModule(modKey);

    return (status);
}

I can tell it fills an array obj->callbacks[] with callback functions/ISRs, but nothing else. I can't see what it is that Starterware does wrong and breaks SysLink.

I also tried sending interrupts between the cores without using SysLink Notify, but I couldn't do that, either. mmap'ing the CHIPSIG (0x01C14174) register from Linux returns MAP_FAILED and causes a segmentation fault.

I honestly have no idea what to try next.

Thanks again,
Okan

Hi Okan,

I'm not too familiar with either syslink or starterware. However I've found that when I'm debugging kernel problems similar to this and I don't know where to go, I try to dump as many registers as I can to a text file when the system is working and then when its broken. And then compare the two files to find whats changed. You can probably start by focusing on the interrupt registers and working out from there. The hope is to find some registry changes that don't make sense and will give you something to search for in both code bases to find where they might be clobbering each other.

I'd also suggest posting a question to TI's E2E forum and see if they have ever used these two systems together.