OMAP-L138 - DSP_LINK - MSGQ_get failed on GPP side

The return code from MSGQ_get() should give you some clue.  You say it is not DSP_SOK, but what is it?  Are you calling it with a non-forever timeout?

You can enable DSPLink tracing to find out more (see DSPLink docs for help with enabling tracing, or see here: http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink)

Regards,

- Rob

Please, have a look on my code and the returned traces :

     if(DSP_SUCCEEDED(i32_status)) {
        /* Creating message queue */
        i32_status = MSGQ_open(pc_gpp_msgq_name, &ui32_gpp_msgq, NULL);

        if(DSP_FAILED(i32_status)) {
            printf("MSGQ_open() failed. Status = [0x%x]\n", (unsigned int)i32_status);
        } else {
            printf("MSGQ_open() successed. Status = [0x%x]\n", (unsigned int)i32_status);
        }
    }

    /* Set the message queue that will receive any async. errors. */
    MSGQ_setErrorHandler(ui32_gpp_msgq, CCN2013_POOL_ID);

    do {

      if(DSP_SUCCEEDED(i32_status)) {
          do {
              /* Receive a message */
              i32_status = MSGQ_get(ui32_gpp_msgq, 0, &pst_msg_gpp);

              if((i32_status == DSP_ETIMEOUT) || (i32_status == DSP_ENOTCOMPLETE )) {
                  usleep(10000);
              } else if ((i32_status == DSP_EINVALIDARG) || (i32_status == DSP_EMEMORY) || (i32_status == DSP_EFAIL)) {
                  printf("MSGQ_get() failed. Status = [0x%x]\n", (unsigned int)i32_status);
              } else {
                  printf("MSGQ_get() succeeded. Status = [0x%x]\n", (unsigned int)i32_status);
              }

           } while(i32_status != DSP_SOK);
        }

        if(DSP_SUCCEEDED(i32_status)) {
            /* Return the message ID */
            ui16_msg_id = MSGQ_getMsgId(pst_msg_gpp);

            printf("message ID : %d", ui16_msg_id);
        }

        if(DSP_SUCCEEDED(i32_status)) {
            /* free the message after use */
            i32_status = MSGQ_free(pst_msg_gpp);

            if(DSP_FAILED(i32_status)) {
                printf("MSGQ_free() failed. Status = [0x%x]\n", (unsigned int)i32_status);
            } else {
                printf("MSGQ_free() successed. Status = [0x%x]\n", (unsigned int)i32_status);
            }
        }

    } while(ui16_msg_id != 98);

Entered MSGQ_open ()
    queueName    [0xbed31be3]
    Failure [0x80040800] in [0x506] at line 873
    msgqQueue    [0xbed31bdc]
    Failure [0x80008051] in [0x703] at line 1078
    attrs    [0x0]
    Failure [0x80008051] in [0x302] at line 699
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e032]
    arg1    [0xbed31ba8]
    arg2    [0x0]
Status: 8000
Leaving DRV_Invoke ()     status [0x8000]
Leaving MSGQ_open ()
    Failure [0x80008051] in [0x703] at line 1078
    status [0x8000]
    Failure [0x80008051] in [0x302] at line 699
MSGQ_open() successed. Status = [0x8000]

Entered MSGQ_setErrorHandler ()
    errorQueue    [0x10000]
    poolId    [0x0]
Entered DRV_Invoke ()
    drvObj    [0x37008]
    Failure [0x80040800] in [0x506] at line 873
cmdId    [0xc018e03b]
    Failure [0x80008051] in [0x703] at line 1078
    arg1    [0xbed31bac]
    Failure [0x80008051] in [0x302] at line 699
    arg2    [0x0]
Status: 8000
Leaving DRV_Invoke ()     status [0x8000]
Leaving MSGQ_setErrorHandler ()     status [0x8000]

Entered MSGQ_get ()
    msgqQueue    [0x10000]
    Failure [0x80040800] in [0x506] at line 873
    timeout [0x0]
    Failure [0x80008051] in [0x703] at line 1078
    msg    [0xbed31bd8]
    Failure [0x80008051] in [0x302] at line 699
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e03a]
    arg1    [0xbed31bac]
    arg2    [0x0]
Status: 80008051
    Failure [0x80040800] in [0x506] at line 873
Leaving DRV_Invoke ()
    Failure [0x80008051] in [0x703] at line 1078
    status [0x80008051]
    Failure [0x80008051] in [0x302] at line 699
    Failure: Status:[0x80008051] File:[0x202] Line:[657]
Leaving MSGQ_get ()     status [0x80008051]

Entered MSGQ_get ()
    msgqQueue    [0x10000]
    Failure [0x80040800] in [0x506] at line 873
    Failure [0x80008051] in [0x703] at line 1078

    timeout    [0x0]
    Failure [0x80008051] in [0x302] at line 699

    msg    [0xbed31bd8]
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e03a]
    arg1    [0xbed31bac]
    arg2    [0x0]
Status: 80008051
    Failure [0x80008051] in [0x703] at line 1078
    Failure [0x80040800] in [0x506] at line 873

Leaving DRV_Invoke ()     status [0x80008051]
    Failure [0x80008051] in [0x302] at line 699
    Failure: Status:[0x80008051] File:[0x202] Line:[657]
Leaving MSGQ_get ()     status [0x80008051]

Entered MSGQ_get ()
    msgqQueue    [0x10000]
    Failure [0x80040800] in [0x506] at line 873
    timeout    [0x0]
    Failure [0x80008051] in [0x703] at line 1078
    msg    [0xbed31bd8]
    Failure [0x80008051] in [0x302] at line 699
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e03a]
    arg1    [0xbed31bac]
    arg2    [0x0]
Status: 80008051
    Failure [0x80040800] in [0x506] at line 873
Leaving DRV_Invoke ()
    Failure [0x80008051] in [0x703] at line 1078
    Failure [0x80008051] in [0x302] at line 699
    status [0x80008051]
    Failure: Status:[0x80008051] File:[0x202] Line:[657]
Leaving MSGQ_get ()     status [0x80008051]

Thanks for your help.

I always have a problem with this.

 

Please let me know if you need more informations to understand the problem.

Thanks

David Marty said:

Leaving MSGQ_get ()     status [0x80008051]

A status of 0x80008051 is DSP_ENOTCOMPLETE.  This status is returned when the internal kernel driver "pend" call returns SYNC_E_FAIL, and since you have timeout as 0 then it simply means that there was no message available at that time.

Are you sure that the DSP sent a message?  You should check that.

Regards,

- Rob

The  trace seems to indicate that the error occured in the MSGQ_open itself.

Entered MSGQ_open ()
    queueName    [0xbed31be3]
    Failure [0x80040800] in [0x506] at line 873 <-- SYNC_E_FAIL
    msgqQueue    [0xbed31bdc]
    Failure [0x80008051] in [0x703] at line 1078 <-- DSP_ENOTCOMPLETE
    attrs    [0x0]
    Failure [0x80008051] in [0x302] at line 699 <-- DSP_ENOTCOMPLETE
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e032]
    arg1    [0xbed31ba8]
    arg2    [0x0]
Status: 8000
Leaving DRV_Invoke ()     status [0x8000]
Leaving MSGQ_open ()

So the issue needs to be looked at MSGQ_open().

Is the kernel version changed, Or is this the issue with multiple iterations (After how long it failes)

Robert Tivy said:

Are you sure that the DSP sent a message?  You should check that.

Yes, messages are sent by the DSP. Have a look at this :

• the code :

    if(i_status == SYS_OK) {
        /*
         *  Allocate a message.
         */
        i_status = MSGQ_alloc(CCN2013_POOL_ID, (MSGQ_Msg *)&pst_msg_gpp, APP_MSG_SIZE);

        if(i_status != SYS_OK) {
            LOG_printf(&st_trace, "MSGQ_alloc() failed. Status = [0x%x]", (unsigned int)i_status) ;
        } else {
            LOG_printf(&st_trace, "MSGQ_alloc() succeeded. Status = [0x%x]", (unsigned int)i_status) ;
        }
    }

    /*
     *  Set the message ID.
     */
    MSGQ_setMsgId((MSGQ_Msg)pst_msg_gpp, (ui16_compteur * 10) + i);

    if(i_status == SYS_OK) {
        /*
         *  Send the message.
         */
        i_status = MSGQ_put(ui32_dsp_msgq, (MSGQ_Msg)pst_msg_gpp);

        if(i_status != SYS_OK) {
            LOG_printf(&st_trace, "MSGQ_put() failed. Status = [0x%x]", (unsigned int)i_status) ;
        } else {
            LOG_printf(&st_trace, "MSGQ_put() succeeded. Status = [0x%x]", (unsigned int)i_status);
        }
    }

• the return :

MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]

Messages are allocated until the alloc section is full.

Velan said:

So the issue needs to be looked at MSGQ_open().

I don't think so because MSGQ_open returns DSP_SOK and MSGQ_locate , on the DSP side, returns also SYS_OK.

Velan said:

Is the kernel version changed, Or is this the issue with multiple iterations (After how long it failes)

The kernel version isn't changed. The issue appears at the first iteration.

David Marty said:

MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]
MSGQ_alloc() succeeded. Status = [0x0]
MSGQ_put() succeeded. Status = [0x0]

Messages are allocated until the alloc section is full.

So, it looks like all the MSGQ_put()s are queueing up on the DSP side and the GPP side is never getting notification of them.

I wish I had a better suggestion, but all I can think of doing at this point is to enable the dsplinkk.ko kernel module TRACE.  You would want to enable it for MSGQ as well as the transport configured for MSGQ use.  The link that I provided in an earlier post contains info for enabling kernel module tracing.

What is the MSGQ transport here?

Regards,

- Rob

 

See the trace below.

FYI, gpp/src/osal/print.h is not like describe in the "Enabling trace in DSPLink" wiki page.

 

• Traces obtained redirected to a file :

...
Entered MSGQ_open ()
    queueName    [0xbee7bbe3]
    msgqQueue    [0xbee7bbdc]
    attrs    [0x0]
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e032]
    arg1    [0xbee7bba8]
    arg2    [0x0]
Status: 8000
Leaving DRV_Invoke ()     status [0x8000]
Leaving MSGQ_open ()     status [0x8000]
MSGQ_open() successed. Status = [0x8000]

Entered MSGQ_setErrorHandler ()
    errorQueue    [0x10000]
    poolId    [0x0]
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e03b]
    arg1    [0xbee7bbac]
    arg2    [0x0]
Status: 8000
Leaving DRV_Invoke ()     status [0x8000]
Leaving MSGQ_setErrorHandler ()     status [0x8000]

Entered MSGQ_get ()
    msgqQueue    [0x10000]
    timeout    [0x0]
    msg    [0xbee7bbd8]
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e03a]
    arg1    [0xbee7bbac]
    arg2    [0x0]
Status: 80008051
Leaving DRV_Invoke ()     status [DSP_ENOTCOMPLETE]
Failure: Status:[DSP_ENOTCOMPLETE] File:[src/api/msgq.c] Line:[657 ->MSGQ_get()]
Leaving MSGQ_get ()     status [DSP_ENOTCOMPLETE]

Entered MSGQ_get ()
    msgqQueue    [0x10000]
    timeout    [0x0]
    msg    [0xbee7bbd8]
Entered DRV_Invoke ()
    drvObj    [0x37008]
    cmdId    [0xc018e03a]
    arg1    [0xbee7bbac]
    arg2    [0x0]
Status: 80008051
Leaving DRV_Invoke ()     status [DSP_ENOTCOMPLETE]
Failure: Status:[DSP_ENOTCOMPLETE] File:[src/api/msgq.c] Line:[657 ->MSGQ_get()]
Leaving MSGQ_get ()     status [DSP_ENOTCOMPLETE]
...

• Traces obtained directly in the console and translated :

Entered DRV_Ioctl ()
        inode   [0xc1f2d380]
        filp    [0xc1e0b100]
        cmd     [0xc018e032]
        args    [0xbee7bba8]
Entered DRV_CallAPI ()
        cmd     [0xc018e032]
        args    [0xc1f0feac]
Entered PMGR_MSGQ_open ()
        queueName       [0xbee7bbe3]
        msgqQueue       [0xbee7bbdc]
        attrs   [0x0]
Entered LDRV_MSGQ_open ()
        queueName       [0xbee7bbe3]
        msgqQueue       [0xbee7bbdc]
        attrs   [0x0]
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
...
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
Entered MEM_Calloc ()
        ptr     [0xc1f0fe14]
        cBytes  [0x38]
        arg     [0x0]
Entered MEM_Alloc ()
        ptr     [0xc1f0fe14]
        cBytes  [0x38]
        arg     [0x0]
Leaving MEM_Alloc ()    status [0x8000]
Leaving MEM_Calloc ()   status [0x8000]
Entered GEN_Strcpyn ()
        destination     [0xc2d81000]
        source  [0xbee7bbe3]
        maxNum  [0x20]
Leaving GEN_Strcpyn ()  status [0x8000]
Entered LIST_Create ()
        list    [0xc2d81024]
Entered MEM_Calloc ()
        ptr     [0xc1f0fdd4]
        cBytes  [0x8]
        arg     [0x0]
Entered MEM_Alloc ()
        ptr     [0xc1f0fdd4]
        cBytes  [0x8]
        arg     [0x0]
Leaving MEM_Alloc ()    status [0x8000]
Leaving MEM_Calloc ()   status [0x8000]
Leaving LIST_Create ()  status [0x8000]
Entered SYNC_CreateSEM ()
        semObj  [0xc2d81028]
        attr    [0xc1f0fe10]
Entered MEM_Calloc ()
        ptr     [0xc2d81028]
        cBytes  [0x14]
        arg     [0x0]
Entered MEM_Alloc ()
        ptr     [0xc2d81028]
        cBytes  [0x14]
        arg     [0x0]
Leaving MEM_Alloc ()    status [0x8000]
Leaving MEM_Calloc ()   status [0x8000]
Leaving SYNC_CreateSEM ()       status [0x8000]
Leaving LDRV_MSGQ_open ()       status [0x8000]
Entered PRCS_Create ()
        prcsObj [0xc1f0fe54]
Entered MEM_Alloc ()
        ptr     [0xc1f0fe54]
        cBytes  [0x14]
        arg     [0x0]
Leaving MEM_Alloc ()    status [0x8000]
Leaving PRCS_Create ()  status [0x8000]
Leaving PMGR_MSGQ_open ()       status [0x8000]
Leaving DRV_CallAPI ()  status [0x8000]
Leaving DRV_Ioctl ()    status [0x8000]

Entered DRV_Ioctl ()
        inode   [0xc1f2d380]
        filp    [0xc1e0b100]
        cmd     [0xc018e03b]
        args    [0xbee7bbac]
Entered DRV_CallAPI ()
        cmd     [0xc018e03b]
        args    [0xc1f0feac]
Entered PMGR_MSGQ_setErrorHandler ()
        errorQueue      [0x10000]
        poolId  [0x0]
Entered LDRV_MSGQ_setErrorHandler ()
        errorQueue      [0x10000]
        poolId  [0x0]
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
Leaving LDRV_MSGQ_setErrorHandler ()    status [0x8000]
Leaving PMGR_MSGQ_setErrorHandler ()    status [0x8000]
Leaving DRV_CallAPI ()  status [0x8000]
Leaving DRV_Ioctl ()    status [0x8000]

Entered DRV_Ioctl ()
        inode   [0xc1f2d380]
        filp    [0xc1e0b100]
        cmd     [0xc018e03a]
        args    [0xbee7bbac]
Entered DRV_CallAPI ()
        cmd     [0xc018e03a]
        args    [0xc1f0feac]
Entered PMGR_MSGQ_get ()
        msgqQueue       [0x10000]
        timeout [0x0]
        msg     [0xc1f0fec4]
Entered LDRV_MSGQ_get ()
        msgqQueue       [0x10000]
        timeout [0x0]
        msg     [0xc1f0fec4]
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered LIST_GetHead ()
        list    [0xc2d84000]
        headElement     [0xc1f0fec4]
LIST_GetHead(). &list->head = [c2d84000]
Leaving LIST_GetHead ()         status [0x8000]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
Entered SYNC_WaitSEM ()
        semObj  [0xc2d87000]
        timeout [0x0]
Failure [SYNC_E_FAIL] in [src/osal/Linux/2.6.15/sync.c] at line 873 -> SYNC_WaitSEM()
Leaving SYNC_WaitSEM ()         status [SYNC_E_FAIL]
Failure [DSP_ENOTCOMPLETE] in [src/ldrv/ldrv_msgq.c] at line 1078 -> LDRV_MSGQ_get()
Leaving LDRV_MSGQ_get ()        status [DSP_ENOTCOMPLETE]
Failure [DSP_ENOTCOMPLETE] in [src/pmgr/pmgr_msgq.c] at line 699 -> PMGR_MSGQ_get()
Leaving PMGR_MSGQ_get ()        status [DSP_ENOTCOMPLETE]
Leaving DRV_CallAPI ()  status [0x8000]
Leaving DRV_Ioctl ()    status [0x8000]

Entered DRV_Ioctl ()
        inode   [0xc1f2d380]
        filp    [0xc1e0b100]
        cmd     [0xc018e03a]
        args    [0xbee7bbac]
Entered DRV_CallAPI ()
        cmd     [0xc018e03a]
        args    [0xc1f0feac]
Entered PMGR_MSGQ_get ()
        msgqQueue       [0x10000]
        timeout [0x0]
        msg     [0xc1f0fec4]
Entered LDRV_MSGQ_get ()
        msgqQueue       [0x10000]
        timeout [0x0]
        msg     [0xc1f0fec4]
Entered SYNC_SpinLockStartEx ()
        spinLockHandle  [0xc296d000]
Leaving SYNC_SpinLockStartEx ()         irqFlags [0x0]
Entered LIST_GetHead ()
        list    [0xc2d84000]
        headElement     [0xc1f0fec4]
LIST_GetHead(). &list->head = [c2d84000]
Leaving LIST_GetHead ()         status [0x8000]
Entered SYNC_SpinLockEndEx ()
        spinLockHandle  [0xc296d000]
        irqFlags        [0x0]
Leaving SYNC_SpinLockEndEx ()
Entered SYNC_WaitSEM ()
        semObj  [0xc2d87000]
        timeout [0x0]
Failure [SYNC_E_FAIL] in [src/osal/Linux/2.6.15/sync.c] at line 873 -> SYNC_WaitSEM()
Leaving SYNC_WaitSEM ()         status [SYNC_E_FAIL]
Failure [DSP_ENOTCOMPLETE] in [src/ldrv/ldrv_msgq.c] at line 1078 -> LDRV_MSGQ_get()
Leaving LDRV_MSGQ_get ()        status [DSP_ENOTCOMPLETE]
Failure [DSP_ENOTCOMPLETE] in [src/pmgr/pmgr_msgq.c] at line 699 -> PMGR_MSGQ_get()
Leaving PMGR_MSGQ_get ()        status [DSP_ENOTCOMPLETE]
Leaving DRV_CallAPI ()  status [0x8000]
Leaving DRV_Ioctl ()    status [0x8000]
...

Robert Tivy said:

What is the MSGQ transport here?

The transport used is ZCPY_MQT.

 

FYI, I'm working on dsplink_linux_1_65_00_02 with dspbios_5_41_03_17, cgt6x_6_1_14 and linux-2.6.33-rc4.

 

Regards,

David

Everything in your traces looks normal.

The only thing I can surmise is that the GPP is never receiving the interrupt from the DSP that serves as notification of a MSGQ message arrival.  The DSPLINK configuration contains a table of IPS entries, and each IPS entry contains an interrupt number for the GPP to receive notifications.  Here is the table from DSPLINK 1.65's config for OMAPL138:
/** ============================================================================
* @name LINKCFG_ipsTable_00
*
* @desc IPS table ID 0.
* ============================================================================
*/
STATIC LINKCFG_Ips LINKCFG_ipsTable_00 [] =
{
    {
        "IPS", /* NAME : Name of the Inter-Processor-Signaling component */
        (Uint32) 32, /* NUMIPSEVENTS : Number of IPS events to be supported */
        (Uint32) SHAREDENTRYID0, /* MEMENTRY : Memory entry ID (-1 if not needed) */
        (Uint32) 28, /* GPPINTID : Interrupt no. to used by the IPS on GPP-side. (-1 if uni-directional to DSP) */
        (Uint32) 5, /* DSPINTID : Interrupt no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */
        (Uint32) 4, /* DSPINTVECTORID : Interrupt vector no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */
        (Uint32) 50000000, /* ARGUMENT1 : Poll value for which IPS waits while sending event (-1 if infinite) */
        0 /* ARGUMENT2 : Second IPS-specific argument */
    },
    {
        "IPS", /* NAME : Name of the Inter-Processor-Signaling component */
        (Uint32) 32, /* MAXIPSEVENTS : Number of IPS events to be supported */
        (Uint32) SHAREDENTRYID1, /* MEMENTRY : Memory entry ID (-1 if not needed) */
        (Uint32) 29, /* GPPINTID : Interrupt no. to used by the IPS on GPP-side. (-1 if uni-directional to DSP) */
        (Uint32) 67, /* DSPINTID : Interrupt no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */
        (Uint32) 5, /* DSPINTVECTORID : Interrupt vector no. to used by the IPS on DSP-side. (-1 if uni-directional to GPP) */
        (Uint32) 50000000, /* ARGUMENT1 : Poll value for which IPS waits while sending event (-1 if infinite) */
        0 /* ARGUMENT2 : Second IPS-specific argument */
    }
} ;

Note the GPPINTID entries.  IPS channel 0 uses 28 and IPS channel 1 uses 29.  Can you check your configuration that you build DSPLINK with, and then check the corresponding interrupts in Linux?

To check Linux interrupts, do:
% cat /proc/interrupts
           CPU0
  0:  668550441    IO-APIC-edge  timer
  1:          9    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:         67    IO-APIC-edge  i8042
 14:   83145133    IO-APIC-edge  ide0

The above output is from one of our Linux servers, but you will see similar output for your OMAPL138, and one of the interrupts will be displayed as "owned" by dsplinkk.  The number printed after the interrupt # is the number of times that interrupt has fired.  I suspect you might see 0 for the dsplink one.

Other suggestions...

Validate that you are MSGQ_locate()ing (on the DSP) the correct name as has been given to the ARM-side MSGQ_open().

Simplify your DSP side to do just one MSGQ_alloc()/MSGQ_put(), to eliminate any potential problems that might arise when you MSGQ_alloc() over and over until failure.

Regards,

- Rob

Robert Tivy said:

Can you check your configuration that you build DSPLINK with

OK, I can see the same in dsplink/config/BUILD/CFG_OMAP138GEM_SHMEM.c.

 

Robert Tivy said:

check the corresponding interrupts in Linux

When my application is running, we can see this :

root@arago:~# cat /proc/interrupts
           CPU0
 11:          0     cp_intc  edma
 12:          6     cp_intc  edma_error
 16:          0     cp_intc  mmc0
 19:          0     cp_intc  rtc0
 21:       7113     cp_intc  clockevent
 22:          1     cp_intc  free-run counter
 28:          0     cp_intc  DSPLINK
 29:          1     cp_intc  DSPLINK
 33:          0     cp_intc  eth0
 34:      28987     cp_intc  eth0
 35:      13206     cp_intc  eth0
 36:          0     cp_intc  eth0
 52:          0     cp_intc  da8xx_lcdc
 56:          0     cp_intc  spi_davinci.1
 58:          1     cp_intc  musb_hdrc
 59:          2     cp_intc  ohci_hcd:usb2
 61:       6851     cp_intc  serial
 93:          0     cp_intc  edma
 94:          0     cp_intc  edma_error
210:          0        GPIO  OHCI over-current indicator
Err:          0

Robert Tivy said:

Validate that you are MSGQ_locate()ing (on the DSP) the correct name as has been given to the ARM-side MSGQ_open()

The name is the same : "EVT_DSP_vers_GPP".

Robert Tivy said:

Simplify your DSP side to do just one MSGQ_alloc()/MSGQ_put()

The result is the same. The GPP loops on MSGQ_get.

 

Regards

David

I have done many tests on my application and on the sample (message) and I don't see where is the issue.

Is this possible to debug the GPP side application with CCS ? How ?

I'm blocked on this issue since many weeks, I need your help ...

Thanks

 

David

David Marty said:

 28:          0     cp_intc  DSPLINK
 29:          1     cp_intc  DSPLINK

OK, from the above we can see that GPP interrupt 29 has been serviced by Linux 1 time, and it is owned by DSPLINK.  IPS channel 1 is configured to use GPP interrupt 29, and the MSGQ transport is configured to use IPS channel 1.  That 1 interrupt is probably the result of the MSGQ_locate() call, which when performed on the DSP will query the ARM side for the existence of the MSGQ being located.  This shows that the plumbing is connected correctly between the ARM and DSP.

Is is possible that some other SW or HW in your system is trying to use that same interrupt 29?  I don't know how you would check this directly, you probably would just need to know about the other system components.

When you enabled TRACE for your dsplink.ko, did you enable ID_OSAL_DPC and ID_OSAL_ISR?  If not, please do this and rerun, hopefully we will see some good traces.

In the meantime, I've asked a MSGQ expert for assistance on this issue, please expect further response from him shortly (he said "probably not until tomorrow", i.e., Friday).

Regards,

- Rob

 

 

Robert Tivy said:

Is is possible that some other SW or HW in your system is trying to use that same interrupt 29?  I don't know how you would check this directly, you probably would just need to know about the other system components.

I'm using the EVMOMAP-L138 (Logic PD), I have looked the sample 'message' from dsplink_1_65_00_02 (which work fine, I can see interrupts counter incrementation) to develop my application. There is no modification on the HW and I don't use no more SW than MSGQ.

 

Robert Tivy said:

When you enabled TRACE for your dsplink.ko, did you enable ID_OSAL_DPC and ID_OSAL_ISR?  If not, please do this and rerun, hopefully we will see some good traces.

I have enabled all traces and I don't see more informations around MSGQ_open or MSGQ_get than the other time.

 

Robert Tivy said:

In the meantime, I've asked a MSGQ expert for assistance on this issue, please expect further response from him shortly (he said "probably not until tomorrow", i.e., Friday).

OK, I waiting for.

I have tried with dsplink_1_65_00_03, TI_CGT_C6000_7_3_0, bios_5_41_10_36, xdctools_3_20_08_88 and the result is the same ...

 

Regards

David

I finally found where is the issue : this is just that the MSGQ_Queue variable's name was different in the MSGQ_locate call and the MSGQ_put call on the DSP side.

Sorry.

 

Regards

David