• Locked Locked
  • Replies 1 reply
  • Subscribers 52 subscribers
  • Views 2095 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS4: DSP held in reset on a BeagleBoard (OMAP3530)

Marcus_v70
Prodigy 130 points
Other Parts Discussed in Thread: OMAP3530

Hi,

I´m using an OMAP3530 on the BeagleBoard with CCS4.0  (90 days evaluation). The GPP uses Linux Ångstrom with kernel 2.6.29. I have been able to run the DSPLink (version 1.63) examples on the Beagleboard after crosscompilation. My itention is to be able to debug the DSP-side of the DSPLink examples in CCS but unfortunately I can not connect to the DSP because the received error message: "target does not have a CPU clock". After using the commands: lpmOFF.x470uC and then lpmON.x470uC that problem seems to disappear but then new problem is that the DSP is held in "wait-in-reset"-state. Using the DSPLink example "message" I have tried to force the DSP-side to get stuck in a while-loop and the GPP-side with getchar() and then try to connect with no success. This was made after Linux auto-boot-up.

I have also tried to connect to the OMAP3530 (both DSP and GPP) before the Linux auto-boot-up. Then I get the error message: "target does not have a CPU clock".

Any suggestions?

  • TI__Guru**** 450031 points

    On an OMAP3530, I've pulled the DSP out of reset by using a the GEL call provided in the startup GEL file for the ARM. However you do not have a debug session for the ARM, you just want to leave that running and connect to the DSP. I'm not sure what the common procedure for pulling the DSP out of reset in this case. You may have some better suggestions from the OMAP35xx forum.

    ki