Long running time using the DSPLink sample "LOOP" in OMAPL138 DVSDK

You have to provide more detail about the code. What is your timer code? Where is your timing code placed? Perhaps your timer is not handling wrap-arround. Perhaps your process got swapped out for that one transfer.

The system function gettimeofday() declared in <sys/time.h> was used to record the time.The difference of the time begining and finishing transferting the message was noted as the looping-back time interval.

/*=============================================================================
@func    SysGetTime 
@desc   This function gets the present system time.  
=============================================================================*/
int SysGetTime(void)
{
      int dwMTime= 0; 
      struct timeval t1;

     gettimeofday(&t1, NULL);
     dwMTime = t1.tv_sec * 1000000 + t1.tv_usec;
     dwMTime &= 0x7fffffff;
 
     return dwMTime;
}

source code  4606.loop.zip

The SysGetTime() function has a limit of 2147483648 usec or 35.79 minutes. There is possibilty of wraparound every every 35 minutes. The stop time will be less than than the start time. I suggest that use an unsigned 32 bit rather than signed 31 bit. That will take care of the wrap-around automatically.

File: loop.c
Uint32 SysGetTime(void)
{
    Uint32 dwMTime= 0;
   
    struct timeval t1;

    gettimeofday(&t1, NULL);
    dwMTime = t1.tv_sec * 1000000 + t1.tv_usec;
   
    return dwMTime;
}

I got some analysis of the issue as follow:

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

We found below issue:
The issue with the application getting stuck on the 34464 is that the number of iterations (buffers) passed from the GPP top the DSP is being truncated on the DSP side.
 
100000 = 186A0 (Hex).
34464 = 86A0 (Hex).
 
On the GPP side, the buffers are a Uint32 but on the DSP it’s a Uint16.  You can modify the DSP-side application (located in dsplink/dsp/src/samples/loop) to ensure the “numTransfers” variable is of type Uint32.  Make sure you also change it in the TSKLOOP_TransferInfo structure.  Just search for  “numTransfers” and ensure they are all Uint32.
 
As for the time discrepancy, I’m also seeing it but not consistently on the same buffer.  I suspect either the time calculation code is suffering from a wrap around or this is somehow cache related.
 
A curiosity question, is there a reason why you’ve chosen to use CHNL/SIO to transfer data between GPP and DSP verses the newer and most commonly used MSGQ method?

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

Thank you for your analysis.

For your first and second issues, I have tested the loop program again after I changed the type to Uint32 with the variable “numTransfers” in the "tskloop_transferinfo" structure, but it was still appeared to delay large, and it did not appear the law with "stuck on the 34464" which you said.

For "your curious problems", I found this question is very important, "MSGQ" is the most commonly method between GPP and DSP. I used the messageg program to test it, and it was still appeared delayed larger when running the process, but not often appeared.

like this one:
root@arago:~/samples# ./messagegpp.xms message.out 65535
========== Sample Application : MESSAGE ==========
Entered MESSAGE_Create ()
Leaving MESSAGE_Create ()
Entered MESSAGE_Execute ()
test times 12927 using = 1113.
test times 37056 using = 1230.
test times 48114 using = 1000207.
test times 49529 using = 1294.
test times 56865 using = 1766.
test times 65224 using = 1044.
Transferring 65535 iterations took 21 seconds 947664 microseconds.
RoundTrip Time for 1 message is 334 microseconds.
min 90  max 1000207
Leaving MESSAGE_Execute ()
Entered MESSAGE_Delete ()
Leaving MESSAGE_Delete ()
====================================================
But for messageg program, I have also a problem. The maximum length of GPP and DSP messages are only support 32. Now I want to run a message which length are 1K bytes, but the program is not support thought I have change the macro definition (DSP_MAX_STRLEN). I don't know why. But it was used more than one second when transported only 8 byte of a message. This one can also illustrate the problem.

Thanks a lot.

The problem is sovled by using the  DSPLink 1.65.00.03 (the GA quality release) and insmod the  newly built dsplink.ko.