• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 662 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.

DSPLINK Application and Codec Engine Application Sharing DSP

Craig Haskins
Prodigy 50 points

Hi,

I have a project where I'm trying to run both a Codec Engine application and a DSPLINK only application (but not at the same time of course).  I have both applications sharing the same DSPLINK build and both apps can run the DSP successfully if they are started first but when I try to switch from one the the other, the DSP fails to start.  I though that since Codec Engine and my DSPLINK application are both using the same DSPLINK PROC_* api's to load the DSP, these apps would coexsist happily, but that doesn't not appear to be the case.  Does anyone know if what I'm trying to do is possible and what the error might be?  I'm using DSPLINK 1.61/Codec Engine 2.22.

My test case is as follows

1. run DSPLINK only application which calls PROC_setup/PROC_attach & PROC_load

2. DSPLINK application runs OK

3. end this application ,calling PROC_stop/PROC_detach/PROC_destroy

4. run my codec engine application.

5. A time out occurs in the PROC_start call inside Codec Engine's procCreate (TRACE is below)

Thanks

Craig

@0,468,013us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Adding DSP segment #0 to Link configuration: name='DDR2', startAddress=0x8f000000, sizeInBytes=0xe00000, shared=1, syncd=0
@0,468,184us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Adding DSP segment #1 to Link configuration: name='DSPLINKMEM', startAddress=0x8fe00000, sizeInBytes=0x100000, shared=1, syncd=0
@0,468,350us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Adding DSP segment #2 to Link configuration: name='RESET_VECTOR', startAddress=0x8ff00000, sizeInBytes=0x80, shared=1, syncd=0
@0,468,512us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Adding DSP segment #3 to Link configuration: name='DDRALGHEAP', startAddress=0x8d000000, sizeInBytes=0x2000000, shared=0, syncd=0
@0,468,673us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> DODSPCTRL was=1; now=0
@0,475,163us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Attaching to DSP PROC...
@0,501,047us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Opening MSGQ pool...
@0,504,562us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Loading /dsp/dsp_armce.x64P on DSP (1 args)...
@0,613,614us: [+2 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Starting DSP PROC...
@21,850,411us: [+7 T:0x40eaa490 S:0x40ea9d44] OP - Processor_create_d> Loading and starting DSP server '/dsp/dsp_armce.x64P' FAILED, status=[0x80008017] (look for error code 'DSP_EBASE + 0x17' in dsplink*/packages/dsplink/gpp/inc/usr/errbase.h)
@21,853,807us: [+0 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Enter (proc=0xde810)
@21,855,710us: [+2 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Closing remote transport...
@21,857,780us: [+6 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Closing remote transport FAILED, status=0x80008000.
@21,859,801us: [+2 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Stopping DSP...
@21,861,755us: [+6 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Stopping DSP FAILED, status=0x80008000
@21,863,868us: [+2 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Closing pool...
@21,866,033us: [+2 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Detaching from DSP...
@21,880,621us: [+2 T:0x40eaa490 S:0x40ea9d24] OP - Processor_delete_d> Destroying DSP... (object, that is)

  • 0
    TI__Expert 4930 points

    Craig,

    I dont see any reason why you should see this behavior.Ideally a second run should work:

    To get some more clues, do you see a PROC_start failure in the second run for following scenarios as well:

    1) DSPLink only sample run back to back

    2) CE application run back to back

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 50 points

    Hi Deepali,

     

    Thanks for the reply.   For both back to back cases, I don't see any errors, it's only when switching between the two.  I have found a workaround by using the lpm_dm6446 power management kernel driver and running lpmOFF/lpmON between the runs.  It seems that this is resetting the DSP allowing the other application to run.  I'm a bit confused though as I thought that PROC_attach/PROC_detach were resetting the DSP as well.

  • 0 in reply to Craig Haskins
    TI__Expert 4930 points

    Craig,

    DSPLink API PROC_stop does a power down of DSP and PROC_detach API does reset of DSP. Is the order of calling these API's correct in your application?

    lpmOFF will power down the DSP. I am not sure whether it resets it.

    Deepali

     

  • 0 in reply to Deepali Uppal
    TI__Genius 12025 points

    Craig,

    I don't have an explanation for the failure cases, but here are some thoughts to consider. Are you running on a DM6446?

    1. The Codec Engine application powers on the DSP when it starts and powers off the DSP when terminating. This leaves the DSP powered off. If your DSPLink-only application is not using LPM to turn on the DSP, it would fail at this point.
    2. When the board is powered on, the default power state of the DSP is determined by dip switches on the board. It might come up powered on. Then you DSPLink application would appear to work correctly. But if you ran the CE application, it would leave the DSP powered off which would then cause the DSPLink appliction to fail.
    3. Using lpmON does issue a reset of the DSP domain.

    My recollection is that DSPLink does *not* do power management, contrary to what Deepali says above. Deepali might be correct, but I would try to verify this as it would be critical to your application success.

    ~ Ramsey

  • 0 in reply to Ramsey
    TI__Expert 4930 points

    Ramsey,

    The default release of DSPLink ships with Boot Mode "DSP_BootMode_Boot_Pwr" which does basic power management i.e. power up/down in PROC_start/PROC_stop, reset/release in PROC_attach/PROC_detach.

    There are other modes:

    Normal Boot Mode: DSPLink loads and starts the DSP running
     -   DSP_BootMode_Boot_NoPwr
     -   DSP_BootMode_Boot_Pwr - Default
    External Load Mode: DSPLink only starts the DSP running
     -   DSP_BootMode_NoLoad_NoPwr
     -   DSP_BootMode_NoLoad_Pwr
    External Load and Start Mode: DSPLink does not load or start the DSP running
     -   DSP_BootMode_NoBoot

     

    If CE is using DSP_BootMode_Boot_NoPwr, there will be no power management.

    Deepali