• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 637 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.

OMAP3530: ARM-DSP synchronization during CCS debug

RH44284
Prodigy 240 points

Hello,

I have been trying to debug a dsplink application using Code Composer Studio. I have implemented the DSPLINK IPC minimal control scenario with just the PROC and NOTIFY modules linked in.  My default DSP boot mode allows the ARM to start execution on DSP with a call to PROC_start. In order to connect to Code Composer Studio, I follow the steps outlined in:  http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP_using_CCS

When I execute the application, the application hangs after PROC_start. I see that PROC_load succeeded, but PROC_start never returns. So, on the ARM side, I never get to the point where I see the message :

"Hit Enter to continue...\n"

This problem goes away if I take out the infinite loop on the dsp side. But, then when I connect to dsp core from Code Composer Studio some
initialization has already taken place on the dsp side and I don't get the initial state of the dsp. I know that a possible solution is to change
the boot mode of the dsp. The challenges of that option are:

->For production, we have to go with the default boot mode so that ARM can control the dsplink. Even though I would use the same versions
of BIOS, XDCtools and compiler, and the same memory map and bios configuration for development for both boot modes, we do not wish to develop in the 
external/JTAG control/boot mode. The prototype boards we use do not have switches to change boot mode so we would change the dsplink shared memory configuration file
to change the DSP boot mode. It would be helpful to know what TI has to say about developing in the two different boot modes. I know the effect on the PROC API
(from dsplink documentation.) I am interested in knowing about some problems I might encounter if I use external boot mode for earlier stages 
of development and changing to the default boot mode in a later stage. 

More importantly, if using the default boot mode, how can I debug a dsplink application correctly using CCS? Clearly the hint on the wiki page is not working for us.
I was thinking of a generic sleep function to waste time in dsp main before I connect to dsp through CCS and start the initialization. I know there is TSK_sleep 
but it leads to an MMU fault as soon as I connect to dsp through CCS. I am still not sure about the connection between the two. If I use a loop that performs and
multiplication for a long time, I face the same situation as with the infinite loop from the wiki page. Application hangs after PROC_start.  

I hope someone can shed light on why PROC_start fails if there is an infinite loop / any loop in dsp main.c (at the location mentioned in
the wiki page above). I will start exploring proc.c to see if I can find a clue. Thank you in advance for your time.

Regards
RH
  • 0
    TI__Expert 4930 points

    RH,

    PROC_start is a call which does some handshake with DSP. This handshake is complete only when the DSP calls the function DSPLINK_init. The PROC_start call will hang till the DSP side calls DSPLink API DSPLINK_init.

    Can you debug till the point in the link.

    In the message example, the DSP is stuck in the while() loop that was setup previously. To have it continue with the program, right-click on the instruction after the loop and select Set PC to cursor. Now you are able to step through the DSP-side code.

    After that, can you step till after the function call DSPLINK_init. After that you will see PROC_start passing and going on to the next execution line of code on A8.

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 240 points

    Hello Deepali,

    Thank you for getting back to me.  When I try the "Set PC to cursor" option, it seems to work at first (In main, I can see the arrow moving down to the DSPLINK_init call). But then when I run the dsp (without any breakpoints),  PROC_start does not return on the arm side. The arm side is still stuck and finally I get :

    [  529.996887] BUG: soft lockup - CPU#0 stuck for 65s! [IPCstaticgpp:554]      
    [  530003479] Modules linked in: dsplinkk                                      
    [  530.007324]                                                                 
    [  530.008819] Pid: 554, comm:         IPCgpp                            
    [  530.013488] CPU: 0    Not tainted  (2.6.33.5 #1)                            
    [  530.018218] PC is at SHMDRV_handshake+0xf8/0x13c [dsplinkk]                 
    [  530.023864] LR is at LDRV_DRV_handshake+0x110/0x284 [dsplinkk]              
    [  530.029724] pc : [<bf00418c>]    lr : [<bf003974>]    psr: 80000013         
    [  530.029724] sp : c4ac7e48  ip : 87e00080  fp : befe5b34                     
    [  530.041259] r10: bf01f0bc  r9 : c4ac6000  r8 : bf01f0d0                     
    [  530.046508] r7 : 00000002 r6 : c6966000  r5 : 0499a44a  r4 : c69c0100       
    [  530.053070] r3 : 0fffffff  r2 : 00000000  r1 : 00000000  r0 : 00008000      
    [  530.059631] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [  530.066833] Control: 10c5387d  Table: 849c8019  DAC: 00000015

    This time-out is occurring every single time, no matter how quickly I try to skip the infinite loop and call DSPLINK_init(). I am not using codec engine, but I tried the tips given for arbitrary dsp code debugging at the link:

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

    So, the spinloop function is called from project.tcf file. Upon connecting to the dsp, I use the GEL file (mentioned in the link) to come out of the loop. But when I try to the dsp code, PROC_start does not respond. After about 5 to 7 seconds, I get the same "soft lockup" complain from the kernel.  Then the rest of the application fails.

    Let me try to summarize the steps taken to start the dsp and the debug session through code composer studio:

    1. The dsplink custom application is compiled outside Code Composer Studio using the Code Sourcery toolchain for ARM and the TI toolchain for DSP. Most of the development takes place in Linux environment. CCS is used only for debugging. 

    2. A dsp-only project is set up in CCS with the same source files and config files (to enable source debugging). This project is then built in CCS.

    3.  The application is run from the ARM. PROC_load returns. PROC_start is stuck...

    4.  DSP is awake and I connect through CCS. Then I load the program through CCS for source-level debugging

    5.  I  choose the "Set PC to cursor option" and choose RUN from CCS.

    6. On the ARM side, PROC_start does not return. Nothing happens for a few seconds and then I get the "CPU stuck error"

    If you could suggest a workaround, it would be great. Since I am not using CE, I cannot try CE_DSPDEBUG=1

    It would be nice to not have a timeout for the handshake to complete. Thank you in advance.

     

    Regards,

    RH

     

     

     

  • 0 in reply to RH44284
    TI__Expert 4930 points

    RH

    This is definitely a strange issue. The method of using a loop to halt the DSP prior to debugging has been used for many years and is the de-facto default method used for debugging DSP side of DSPLink.

    The PROC_start spins in a loop in the kernel waiting for DSP to write its handshake value.Can you share some details of the Linux kernel version that you are using? Could the waiting in a tight loop in the kernel cause some issues?

    One workaround I can suggest is to put the while loop after the DSPLink_init call. This will ensure that PROC_start will pass at first go and no possible issue due to the tight loop in kernel will happen.

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 240 points

    Hello Deepali,

    The Linux kernel I am using is : linux-omap-2.6.33.5-0

    I don't know if this issue is specific to the version I am using because I have not tried with other kernels. I have a question related to the debugging tips given in the wiki page:

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

    Note! The ARM-side app.out may time out during the above process due to CE using a timeout in DSP Link PROC_start(). We are halting the DSP so early during initialization that the DSP Link "handshake" after loading a DSP image doesn't take place. This means you only have a limited time to do the steps above, and is one reason why using a GEL file is a good idea (you can add the addition of your breakpoints in to this same GEL file to speed up the process further).

    Note!If you are using CE 2.00 or later, you can set an ARM-side environment variable CE_DSPDEBUG=1 before running the ARM app. That will 1) configure the Link "handshake" timeout to "forever", and 2) prompt the user to press Enter to continue. This way, you can leisurely connect to the DSP via CCS.

      If I am not using Codec Engine, is there any other way to set the timeout o forever?


    If I have the while loop after DSPLINK_init(), the driver initialization would take place. Then after connecting to CCS, if I load the program again, DSPLIINK_init() would not need to be called again, right? I can set the PC to the instruction that comes right after DSPLINK_init() and the while loop. I am hoping there would no initialization issues. Will implement your suggestion tomorrow and let you know. 

    Thanks