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.

Question about Engine_open() error.

I developed a board with DM6446.  The embeded Linux OS was transplant successfully.  But It returned an error  when I used Engine_open() to open an Engine.  The error ID is Engine_EDSPLOAD.  A doc says that it can't load DSP.  What does this mean?  And What could be the cause? 

When I run the same code in DVEVM with the same Linux OS and DSP Link, everything is OK.  

Thanks very much for your help.

  • CE_DEBUG should provide more insight.  Start with CE_DEBUG=1.

    http://processors.wiki.ti.com/index.php/CE_DEBUG

    Chris

  • Thanks, Chris.

    I got the infomations below by using tracing utility module.

    @0x00017bc8:[T:0x40945b60] OP - daemon> thread created.
    @0x00115f56:[T:0x40945b60] OP - Process_create_d> Initializing DSP PROC...
    @0x0011643c:[T:0x40945b60] OP - Process_create_d> Attaching to DSP PROC...
    @0x0011686b:[T:0x40945b60] OP - Process_create_d> Opening MSGQ pool...
    @0x00116ad4:[T:0x40945b60] OP - Process_create_d> Loading ./server_debug.x64P on DSP (2 args)...
    @0x00125697:[T:0x40945b60] OP - Process_create_d> Starting DSP PROC...
    @0x0178dbe3:[T:0x40945b60] OP - Process_create_d> Loading and starting DSP server FAILED, status=[0x80008008]
    @0x0178deb7:[T:0x40945b60] OP - Process_delete_d> Closing remote transport...
    @0x0178df4a:[T:0x40945b60] OP - Process_delete_d> Closing remote transport FAILED, status=0x8000800b.
    @0x0178dfb1:[T:0x40945b60] OP - Process_delete_d> Stopping DSP...
    @0x0178e0bd:[T:0x40945b60] OP - Process_delete_d> Stopping DSP FAILED, status=0x8000801b
    @0x0178e166:[T:0x40945b60] OP - Process_delete_d> Closing pool...
    @0x0178e2f8:[T:0x40945b60] OP - Process_delete_d> Detaching from DSP...
    @0x0178e916:[T:0x40945b60] OP - Process_delete_d> Destroying DSP... (object, that is)
    @0x0178ecc6:[T:0x40945b60] OP - Process_create_d> return (0)
    @0x0178ee0d:[T:0x41146b60] OP - Process_delete(0x29740) freeing object ...
    @0x0178ee9f:[T:0x41146b60] CE - rserverOpen: can't start './server_debug.x64P'; Process_create failed
    @0x0178ffe5:[T:0x40945b60] OP - daemon> thread terminating

    It shows that Loading and starting DSP server FAILED.  But what does the status mean? I still have no idea about the cause. Can you give me more suggestions?

  • Hi ChaoYe,

    Which version of Codec Engine and Dsplink are you using? From the trace it looks like Dsplink was unable to start the DSP for some reason and a call to PROC_start is returning a general failure code 0x80008008. You may want to enable the Dsplink trace (see http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink) to get more information about the failure. Make sure you uncomment the line

    /* TRC_ENABLE (ID_LDRV_PROC) */

    as described to view trace from the PROC component.

    Best regards,

    Vincent

  • Thanks, Vincent.

    I have  enable ID_LDRV_PROC trace and set severity level as TRC_ENTER.  I got the infomation below.

    Assertion failed ((procStates [dspId] == ProcState_Started) || (procStates [dspId] == ProcState_Stopped) || (procStates
    [dspId] == ProcState_Idle)). File : ldrv_proc.c Line : 367

    This error happened at the fuction LDRV_PROC_Stop().  Actually, an error had happened before LDRV_PROC_Stop().   But I don't know how to set the trace to get more infomation.  The referrence doc says it will print all information by setting severity level as TRC_ENTER but it didn't. So I add printk in some place and found that time was out when GPP shaked with DSP in function SHMDRV_handshake ().  The DSP didn't  response to GPP.    Can you tell me how to get information about the DSP side? 

    My Codec Engine is v1.10 and Dsplink is v1.30.

    Best wishes,

    ChaoYe

  • Hi ChaoYe,

    TRC_ENTER is simply the severity level, i.e. meaning that all trace including function enter/exit trace would appear. In order to get trace for more components (looks like you have only enabled trace for the LDRV_PROC component, so if there were errors from other files than ldrv_proc.c you will not see them), you need to enable other ones as well. So for instance if I were debugging the PROC API, I'd enable all IDs with 'PROC' in its name. When in doubt, I usually start with that approach to debug DSP startup problems.

    Meanwhile, if you'd like to do some DSP side debugging, you can refer to this article:

    http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_CE_application_using_CCS

    It explains how to connect to the DSP using CCS via JTAG, so that you can step through your DSP-side code.

    Best regards,

    Vincent

  • Hi Vincent,

    I followed the steps as the article describing.  But it return an error when I tried to connect DSP.  when I set the boot mode to be UART_BOOT_MODE,  it was successful to connect DSP and ARM, and it run the hardware test programs without error.

    What should I do?

    Thank you.

    Chao Ye

  • Hi Chao Ye,

    Note that it is important to connect to the DSP only after it has been pulled out of reset, Perhaps before you changed the boot mode the code was unsuccessful in pulling the DSP out of reset, hence the error message showed up.

    So after changing the boot mode, are you able to run the application and call Engine_open() successfully without connecting using CCS? If so, then maybe you were having a problem with the previous boot mode on your board?

    Best regards,

    Vincent

  • Hi Vincent,

    No. Actually, the embeded Linux OS didn't run after changing the boot mode.  And then it was successful to connect DSP and to ran programs using CCS.   The Engine_open() problem is still exist.

    Thank you.

    Chao Ye

  • Hi Chao Ye,

    Prior to changing the boot mode, after you run the application under the Linux OS, you should be able to run to the point where the DSP would hit the spin loop you have inserted, if you followed the instructions in the article. Note that DSPLINK is responsible to "release" the DSP from reset, so you should not need to do anything extra (ie. no need for GEL file) to release it and can directly connect to it, if the code was successful. So if you are getting an error message, than the error may be pointing to the fact that the DSP was not properly released from reset, and never got to execute any code. In this case you will have to rely on the DSPLINK trace to narrow down on why it is not doing it appropriately for your particular board (e.g. maybe the DSP never got powered up properly?). Given this software worked on the DVEVM but not your board, you will need to identify the exact call in DSPLINK that caused the failure and from there deduce the difference between the DVEVM and your board's design.

    Best regards,

    Vincent

  • Chao Ye,

    I'm wondering if the DSP subsystem has power. On your board design, do you have an external power supply for the DSP? If so, do you have a switch or is it always powered? Also, are you using the same u-boot as on the EVM? Sometimes, u-boot will power on the DSP at boot time. The DSP external power supply must be turned on before the internal DSP power switch is closed. We have a separate software download to help manage the power sequencing.

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/lpm/1_24_02_09/exports/local_power_manager_linux_1_24_02_09.tar.gz

    Open the release notes and follow the "General LPM overview" link. Later versions of Codec Engine manage the DSP power sequencing, but in the version you are using the DSP must be powered on before calling Engine_open().

    Are you using an SDK or did you download the Codec Engine and DSPLink products separately?

    ~ Ramsey

  • Hi Vincent , Ramsey, 

    Thank you. Thanks for giving me the important suggestions.  I have solved the problem. The cause of the problem is that the DSP core power is lower than 1.2V.  When I just connects DSP or ARM alone using CCS, it can work without error.  But when the ARM side app calls the Engine_open(),  the power will be pulled down to a lower level so that the DSP wounld not work.

    Thanks everyone giving me help.

    Best wishes for you.

    Chao Ye

  • Chao Ye,

    Great. I'm glad you resolved the issue. I just want to confirm that on the DM6446, the DSP has two power sources; one external supply and one internal supply. The external power supply must be on first, and both must be on for proper operation.

    ~ Ramsey