• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 166 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.

CCS v4 on OMAPL138 Experimenter's Kit --does it stop the ARM side from running?

Elisa Pasquali
Prodigy 50 points
Other Parts Discussed in Thread: OMAPL138

Hello,

I have a LogicPD  Zoom Experimenter's kit for the OMAP L138 and I'm running CCS v4 that came with the kit. I have a question about what happens when you start the CCS debugger.

Basically, I've connected my kit to an Ubuntu virtual machine running on Windows to provide the TFTP boot. The EVM boots correctly from TFTP with no problems and I can log in as root using a TeraTerm terminal, where I can also see all the boot messages, etc.

I then fire up CCS and open my DSP project. I build it, and then launch the debugger, and the first thing I see that happens is that it sends the ARM side into a reboot. Can someone explain why this happens or if CCS is intended to behave this way?

Anyway,  after CCS connects to the target, it loads the DSP, and I can run it. However, this also means that as soon as the DSP has been connected to, all TeraTerm messages stop. I'm not sure if the booting actually stops or if it is just the serial port that has stopped, it just looks like the ARM side no longer accepts serial port input, nor does it seem to output anything.

The DSP code runs in CCS without any problems.

The problem is, if I cannot monitor the ARM side via the terminal while the DSP is running via CCS, then it makes it very difficult to debug the ARM and DSP interaction.

Is this normal/intended behavior with CCS? And if it is, what's the best way to kick start or stop an ARM-side application so that you can debug the DSP after it receives an input from the ARM side?

Thanks,

-E.

  • 0
    TI__Guru** 116170 points

    Hi Elisa,

    Could you describe/list the procedure you follow while connecting to device using CCS. Note when linux is running the device clocks, PSC, SDRAM, PINMUX are already configured so when you connect to the ARM you should make sure that you remove the GEL file. Also if you have a GEL file on the DSP side, you should ensure that on on Target connect, you don`t configure the clocks, Pinmux and PSC as altering this setting can adversely affect the ARM Linux.

    OMAPL138 is an ARM boot device so to run something on the DSP, some piece of code needs to bring the DSP out of reset. What piece of code/GEL are you using to bring the DSP out of reset. Are you using DSPLINK/SYSLINK or some other IP mechanism in this use case.

    You may want to follow the steps described on the following wiki while connecting to the target.

    http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP-L138_using_CCS

    Regards,

    Rahul