Project

General

Profile

IPC and uPP interrupts APIs conflict

Added by Okan Çalış over 1 year ago

Hi,

We've been working on a MityDsp-L138F. The ARM and DSP cores run Linux and SYS/BIOS, respectively. We're using SysLink for inter-processor communication. Specifically, we send Notify events between the cores. Up to this point, everything works fine.

Also, we have a baremetal DSP code that utilizes the StarterWare API to set up the uPP interrupts from the FPGA. It's also working without issues.

The problem is, I can't make these two work together (in the BIOS code). When I use the StarterWare API IntDSPINTCinit(), the Notify module stops working and I can't get any events from the ARM side. If I comment out that call, then the Notify module does work, but uPP stops working this time. Although I call the Notify_registerEventSingle() function after IntDSPINTCinit(), somehow the StarterWare API breaks SysLink.

Could you please elaborate on what cpuINT (CPU maskable interrupt number; [4..15])and sysINT (system event number [0..127]) parameters represent in the StarterWare API? Is it possible that these two are responsible for the problem? The Notify API doesn't require any of these parameters as input arguments, it just asks for line ID (0) and event ID (7). I can't find a match between these two APIs.

Thanks in advance,
Okan


Replies (4)

RE: IPC and uPP interrupts APIs conflict - Added by Okan Çalış over 1 year ago

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

RE: IPC and uPP interrupts APIs conflict - Added by Gregory Gluszek over 1 year ago

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

RE: IPC and uPP interrupts APIs conflict - Added by Okan Çalış over 1 year ago

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

RE: IPC and uPP interrupts APIs conflict - Added by Jonathan Cormier over 1 year ago

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.

    (1-4/4)
    Add picture from clipboard (Maximum size: 500 MB)