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.

omapl138 audio_soc_example hangs.

I built the audio_soc_example kernel and the audio_soc_example programs. I boot my board and run the audio_soc_example. I it just hangs. Any suggestions? Anything I missed?

 

root@arago:/usr/share/ti/audio_soc_example/Release# ./audioSoc_gpp ./audioSoc_dsp.out ../davincieffect_clip.pcm
========== Application started ==========
Calling PROC_setup()
Calling PROC_attach ()
Calling POOL_open ()
Calling POOL_alloc ()
Calling POOL translate address
Calling MSGQ_open () for GPP MSGQ
Calling PROC_load ()
Calling PROC_start ()
Calling POOL_makePoolId ()
Calling MSGQ locate for DSP message
DSP message located

It hangs right here, and even control-c or kill from another terminal will not kill it

  • hit the same issue,

    my code hang on Calling PROC_start (), 

    anyone can help us, thanks. 

    BTW,my dsplink sample work well.

  • Hi,

       You might be hitting resource conflicts issue between audio app in DSP and ALSA in linux kernel side.

       I do not know about your software component versions.   But for DVSDK this information is documented in Software Developers Guide at section "Running the Audio SOC example"

       DVSDK4.x FAQ at section Why do audio_soc_example application on OMAPL138 hung? has more info on this issue.

       This is also documented in Release notes of Audio SOC example component

    Best Regards,

    Velan

  • Hi Velan,

    the the ALSA in linux kernel side was disabled, but still hang on the PROC_start().

    here is a BIOSPSP in the DVSDK4 package, I assume the biospsp library file had already  been build on windows.

    How can I make sure the BIOSPSP work well?  

    Shall I the run the BIOSPSP  test audio program on  windows CCS first?

    thank you so much!

    James

  • There is another info i missed in the above reply that there is a I2C resource conflict with LCD touch screen driver at linux & audio driver at DSP. SO ensure not to run LCD touch screen driver at linux side.

                  This issue is discussed in more detail in forum thread http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/109856/394604.aspx

    For PROC_start issue, Please let us know your DVSDK version, to understand your issue better.

    Best Regards

    Velan

               

  • James,

           It is strange that PROC_start () itself hung, the original message for hung during app execution, in your scenario DSP not started execution, so this might not be anything to do with audio_soc application.

           You might be required to re-run you app with CE_DEBUG to 3 environment variable ie as below & create new post.

           # export CE_DEBUG=3

    Best Regards

    Velan

  • Velan,

    Thank your for your great help,

    sometimes,  hung at "PROC_load ()".

    I will try with # export CE_DEBUG=3 

    thanks

    James

  • When run to PROC_start, does it will start audioSoc_dsp.out in DSP automatily?

    I hung at PROC_start also.And I cann't get any error log.

  • Hi Changsheng,

    Some ideas on how to debug this:

    - Check if the DSP has started and got to main() by putting in a while() loop and connecting with JTAG. See http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP-L138_using_CCS for details. You can then step thru the DSP code to see where it gets stuck.

    - If the DSP is stuck spinning waiting for a handshake from the ARM, make sure you are using the same version and configuration of DSPLINK on both the ARM and the DSP sides. A configuration mismatch between the two sides would prevent the initial handshake from happening between the two cores. This topic may help: http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues#Problem:_PROC_start_failed_with_configuration_mismatch.2Ffailure

    - If the DSP is stuck in reset, and you cannot connect to the DSP with JTAG, you may want to take a look at the DSPLINK trace for hints: http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink

    Best regards,

    Vincent

  • Hi Vincent:

        Thanks very much for your help!

         Check if the DSP has started and got to main() by putting in a while() loop and connecting with JTAG. ----->No. I can get any printf's log.  So DSP cann't started. Why?

         What's wrong about this?

         In file system, there only same version dsplinkk.ko file.

         dsplinkcfg.pl run error! So I can get any trace information.

        Can you help me to continue?

         Thanks very much!

     

  • Hi Changsheng,

    It's not clear from your reply whether you were successful in connecting to the DSP with JTAG. If you can connect, even if you do not see any printf's you can still load the program symbols and step thru the code. Were there any error popups when you try connecting?

    If on the other hand you are unable to connect to the DSP, and you are having trouble enabling the trace, make sure you are following the instructions on how to rebuild DSPLINK: http://processors.wiki.ti.com/index.php/Building_DSPLink

    Could you share the output of dsplinkcfg.pl when it fails?

    Best regards,

    Vincent

  • Hi Vincent W:

       run to PROC_start, hung at:

    status = (drvState->interface->handshake) (dspId,drvState->linkDrvId,hshkCtrl) ;

      It  seams that DSP not run. Because I cann't get any log from DSP main.c.

       What's wrong about this? 

     

  • Hi Changsheng,

    This handshake function waits for the DSP to write a value into a shared memory location to establish the initial handshake, so your ARM program is likely stuck in a polling loop. There can be many reasons why the DSP fails to do the handshake on its end. Here are a few:

    - The DSP is stuck in some initialization code and never reached the point where it is supposed to do the handshake

    - The DSP did the handshake, but wrote to the wrong location because DSPLINK was misconfigured

    - The DSP was not loaded correctly with the right program and was executing wrong code

    - The DSP did not come out of reset and was not started correctly

    To find out why, you would need to try connecting to the DSP with CCS, and if successful, see how far it gets in the execution of the DSP code. The execution may or may not reach the point where logging is done, so it is worth connecting with CCS to find out more.

    Another thing to do is to sanity check your setup. See if you can run the samples in DSPLINK. This should tell you whether it is a general issue or it is just a misconfiguration in your audio soc application.

    Best regards,

    Vincent