• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 7888 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CE : Universal copy demo for Centaurus

Pranjal Chakraborty
Prodigy 70 points
Other Parts Discussed in Thread: SYSBIOS

Hi ,

 

We are trying to run the "Universal copy" demo from CE release 3_21_00_19 which was released along with SDK 2.1.59 release in remote mode and we see the execution getting stuck. However we have been able to run the same in local mode.

After debugging we found that the execution is stuck in function "doCmd" in the file "Processor_dsplink.c". It is stuck in the line

                 SemThread_pend(dcmd.replyPresent, SemThread_FOREVER, NULL);

In the same file i found out that the post for this semaphore happens in the function daemon(). Now my question is from where does this daemon thread receive the message so that the semaphore can be posted?

By the way i am using the DSP binary from \codec_engine_3_21_00_19\examples\ti\sdo\ce\examples\servers\all_codecs and A8 side binary "./app_remote.xv5T" from \codec_engine_3_21_00_19\examples\ti\sdo\ce\examples\apps\universal_copy. I want to run the universal copy example demo with server on DSP. No other slave cores are loaded except DSP.

Any pointers will be very helpful.

Regards
Pranjal

  • 0
    TI__Mastermind 18260 points

    Pranjal Chakraborty said:
    In the same file i found out that the post for this semaphore happens in the function daemon(). Now my question is from where does this daemon thread receive the message so that the semaphore can be posted?

    The daemon thread runs on behalf of the Processor module.  Its purpose is to allow serialization of the use of ProcMgr, so that only one thread is calling ProcMgr at a time.

    The doCmd() function issues a command to the daemon and posts a semaphore to alert the daemon to the presence of this command.  doCmd() then waits for a reply from the daemon.  The daemon thread unblocks when it receives a command, and when it's done processing the command it issues a reply to doCmd() and posts a semaphore to alert doCmd() to the presence of the reply.

    It appears that your application is getting stuck waiting for a reply from the daemon "worker" thread.

    Setting CE_DEBUG=2 or 3 will show traces of the main CE-using application thread, as well as the daemon thread.  Please try setting CE_DEBUG=2 or 3 (3 is a bunch more output, but might be the level needed in order to show the problem) and running your app, and post the resulting output here.  I will take a look and  let you know if I see anything pertinent to your hang.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Prodigy 70 points

    Hi Rob,

    Thank you for replying.

    I am attaching the ARM side log with CE_DEBUG set to 2 and 3. With both i see that the execution is halted at  "> Starting DSP ...".

    I am also attaching the DSP side snapshot after connecting DSP via CCS.

    Please check and let us know why we are not able to run the universal copy demo shipped with the CE release.

    Regards
    Pranjal

    0334.log_CE_DEBUG_2.txt

    3365.log_CE_DEBUG_3.txt

     

     

     

  • 0 in reply to Pranjal Chakraborty
    TI__Mastermind 18260 points

    Thankyou for supplying the CCS screenshot.  It indicates to me that you're hitting a problem that we have encountered before on Centaurus.  With this problem, the dmtimer is running much faster than SYS/BIOS thinks it is, and the DSP gets stuck processing mostly timer code since the timer is firing too fast.

    You need to tell SYS/BIOS how fast the dmtimer is actually running.  My guess is that SYS/BIOS currently thinks that the timer is running at 32KHz but in actuality your board's timer has been programmed (by Linux probably) to run at 20MHz.

    In order to tell SYS/BIOS of the different timer frequency, you should modify your application's .cfg file as follows:
        var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
        Timer.intFreq.hi = 0;
        Timer.intFreq.lo = 20000000;
    The above configures for 20MHz, and your board might be something different (perhaps 24MHz), so modify accordingly.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Prodigy 70 points

    Hi Rob,

     

    With you suggestion, we are able to run the universal copy demo in remote mode. Thank you very much for your support.

     

    Regards

    Pranjal