• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 639 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA7XX DSP : Discrepancy in sleep time provided by Task_sleep()

Naveen Shetti
Intellectual 690 points

Hello,

We are working on dra7xx-evm(OMAP5777)  board with following setup :

1.  linux-3.12 kernel

2. Toolchain- gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux.

3. Filesystem- arago-glsdk-multimedia-image-dra7xx-evm.

4. glsdk_6.10.00.02

5. ipc_3_23_00_01

6. bios_6_37_03_30

7. xdctools_3_25_06_96

8. CCS5.5


We tried to profile Task_sleep (1000) on the DSP1 core ( The clock is set to 1millisec tick. ) .

This Task_sleep call is expected to provide 1sec sleep interval, but it provides around 955millsec sleep. How can this be possible ?

Scenario of profiling:

1. We have used both ARM and DSP cores to profile this activity. IPC Message  Queue is used for sending to & fro messages between ARM &  DSP.

2. On the ARM we have used linux timer (clock_gettime ()). This timer is started before a message is sent to DSP. The DSP core on availability of this message goes to Task_sleep (1000) and sends a response message to ARM core. The ARM core on availability of this message stops the timer.

3. The time elapsed (stoptime - starttime) on the ARM core evaluates to 959millisec. We had earlier profiled the MessageQ transport for 4millisec to and fro commute time. 

Hence 959 - 4 = 955 is the actual sleep time which contradicts 1 sec sleep to be produced by Task_sleep (1000) call.


Please advice on the same.

Thanks,

Naveen Shetti

  • 0
    TI__Genius 10260 points

    Hi Naveen,

    Sorry for the delay, this post slipped through the cracks.

    I think the discrepancy may be due to the timers are running at a higher frequency than what SYS/BIOS thinks they are (I think bios assumes they are running at 19.2 MHz by default).  The first step would be to check the device registers to see which clock is selected as the timer source.  Compare the register values to the Timer register tables in the TRM (screenshot below).

    Once you know which is the operating frequency, use Timer.intFreqs[] in your cfg file to set the timer input frequency.

    Hope this helps,

    -- Emmanuel