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

regarding ti ipc messageq open error from ARM(Linux)

Naveen Shetti
Intellectual 690 points
Other Parts Discussed in Thread: SYSBIOS

Hello sir,


We are trying to open ti  ipc messageq created on the DSP(sysbios)
from arm(linux).

If we are putting  ARM  binary  and sysbios dsp1 image  directly on
the   SD card. Arm and DSP cores are communicating perfectly through
ti ipc messageq.

We are using gdbserver for arm binary debugging  and jtag for
debugging sysbios image on dsp core.

But when we are trying to debug through ccs v5.5 arm is not able to
open ti ipc messageq created on the dsp side. While opening the
messageq it is give messageq status = -6 (timeout).


There is snapshot  for the error log  displayed on  linux console.

Please help in this regard.

Regards

Naveen Shetti

  • 0
    TI__Genius 12025 points

    Naveen,

    When the Linux side attempts to open a message queue on the DSP, it must get a response back within a short timeout value (less than 1 second). If the Linux side does not get a response, it will fail.

    If you have the DSP halted in CCS, then it will not be able to respond to the Linux side. You must take care to set breakpoints at places where the Linux side is not waiting for a response. This is difficult to achieve, because most applications send many messages.

    You have two choices:

    1) Once you hit a break-point on the DSP, ignore the Linux side error. Use ROV to get any information you need. You might be able to step through some code, but eventually, you will need to restart the system.

    2) Use log events to capture runtime data. Then halt DSP during some idle time and use ROV to read the log data.

    ~Ramsey

  • 0 in reply to Ramsey
    Intellectual 690 points

    Hello Ramsey,

    This issue occurs when we try to load the DSP.out image from the CCS using JTAG. When we load the DSP image through CCS we are not able to communicate with the ARM core. The transport layer communication which is called by IPC_startup() is getting stalled.

    However we tried to boot the images (ARM & DSP) through the SDCard and the connectivity goes through fine. We later tried to hook the debugging of DSP by separately  loading only the symbols through the CCS. This way we can allow the DSP to initialize along with ARM during board init and later we can proceed with DSP debugging by loading the symbols through CCS.

    This activity even though works fine, but is time consuming (during development stage) since we need to copy the images to SDCard every time when there is a change in source code.

    Please shed some light on the same wherein we can have the flexibility of loading the DSP image and testing directly though the CCS.

    Thanks Naveen

  • 0 in reply to Naveen Shetti
    TI__Genius 12025 points

    Naveen,

    The debug process you described above is the same flow that we use. I understand it is tedious to reload the SD card each time you build a new DSP executable. But I don't know any other way to achieve DSP side debugging with CCS in a Linux environment.

    You must load and boot the DSP through your Linux side loader (remoteproc) because it will build runtime objects necessary for IPC communication. When you load the DSP directly from CCS, Linux does not have the necessary references to your executable.

    ~Ramsey