• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 535 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.

DSP Side program crash

Paul Isaac
Intellectual 340 points

Other Parts Discussed in Thread: OMAPL138

Hi,

I am developing an Encoder application on OMAP L138 EVM. For this I modified 'read write' program in the DSP/BIOS Link sample applications.

But now I am getting error on DSP side program.  If I execute a particular function in my application, the code gets hangs after 'MSGQ_put()' function call.

If I disable that  function and run my program, its works fine.

Even I increased the stack and heap sizes, the problem remains.

If i remove all arguments from the function call, and create all those variables local to that function, the code is working.

But if I put any arguments(even a dummy variable), the code hangs. 

Please help me to solve this problem.

Thanks in advance.

  • 0
    TI__Genius 12865 points

    Hi Paul,

    Have you tried to connect to the DSP via JTAG using CCS and step through the MSGQ_put call to find out where exactly the code hangs? You may not have access to the BIOS source of the MSGQ implementation, but if you set a breakpoint in the transport it uses in DSPLINK you may be able to observe part of the call stack. My guess is that "ZCPYMQT_put" in dsplink/dsp/src/msg/zcpy_mqt.c could be a good function to step through. That would help figure out if there is a bad pointer somewhere. You will need to link against the debug version of the DSPLINK libraries for this.

    Here's a page that discusses how to debug the DSP side of a DSPLINK application using CCS on OMAPL138: http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP-L138_using_CCS

    If you have many user tasks on the DSP side, it may also be good to try simplifying things by disabling some of the other tasks. Make sure you verify the stack and heap sizes for all tasks in the system, along with the global ones.

    Some BIOS and DSPLINK debugging resources:

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

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

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Intellectual 340 points

    Hi Vincent,

        Thanks very much for your reply.  I am managed to solve that problem. The problem was with the stack.

    From my knowledge I thought that, for increasing the stack size for my application I have to modify the entry 

    'prog.module("MEM").STACKSIZE= stack_size'  in the memory configuration file 'dsplink-omapl138gem-base.tci'.

    But one of my colleague suggested me to add a new  entry 'prog.module("TSK").STACKSEG = stack_size' in the configuration file

    'readwrite.tcf' . This solved my problem. 

    But still I am confused of these two entries. Can you say what the difference between those two stack configuration..?  

    Expecting your support. 

    Thanks and regards,

    Paul

  • 0 in reply to Paul Isaac
    TI__Genius 12865 points

    Hi Paul,

    Glad you got your problem resolved.

    In a nutshell, prog.module("MEM").STACKSIZE refers to the system stack size (e.g. for HWIs, SWIs), whereas prog.module("TSK").STACKSEG refers to the default stack size of each task instance, which you can override during task creation time. These two fields are described in the BIOS API guide, so I'd recommend you look there for more details.

    Best regards,

    Vincent