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.

Problems connecting to C64x+ core on the IOMAP3530 with CCS debugger using BH560M

Other Parts Discussed in Thread: OMAP3530

I am using the BlackHawk 560M USB emulator with the LogicPD OMAP3530 board. I first connect to the ARM Cortex Core and there is no problem there. I run code on the ARM that sets up the DSP core frequency and brings it out of reset. This ARM core also sets up the DSP MMU. I then connect to the 64x core. I always first get this message from the debugger

Error connecting to the target:
à(€

When I click on Retry the target is successfully connected. Now I can read registers. Now from here on it becomes flaky. Sometimes I have been able to load code into the DSP from here and successfully run my DSP application. But other times I cannot load code, seems like there is a problem accessing the DDRAM from the DSP core although this has been set up for that. Also if I do a memory view I get the following message "Trouble Reading Memory Block at 0x80000000 on Page 0 of Length 0x100:
Error 0x00000002/-1202
Error during: Memory,

CPU pipeline is stalled and the CPU is 'not ready'. This means
that the CPU has performed an access which has not
completed, and the CPU is waiting. The target may need to be
reset. The user can choose 'Yes' to force the CPU to be 'ready'.
When this is done, the user will have the ability to examine
the target memory and registers to determine the cause of the
CPU stall. If CPU hang is caused by application and it has been
forced to be 'ready', the CPU should not be run without a reset.

  Yes  - force CPU ready (might corrupt the code)
  Disconnect - disconnect CCS so that it can be reset
  Retry  - attempt the command again
"

Please help.

  • I was setting the IVA2 Boot Mode to 0x0 and providing a Boot Address as is required when the board is booted from flash. But for debugging using the emulator this does not seem to work as the processor starts executing the code that does not yet exist for the DSP. I found that the deterministic method of making this to work is to put the Boot Mode to 1 when using the emulator and then loading the DSP code and then letting the DSP and ARM code to execute. Any other suggestions are welcome.