Debugging DSP Code on ARM/DSP processor using CCSV5.2 and Syslink

john3909

Other Parts Discussed in Thread: DM3730, SYSBIOS

I'm using syslink_2_10_06_28, Linux Kernel V3.0.28 on a Beagle-xM. The problem with debugging DSP code on the DM3730 is that the DSP is held in reset after power up and the ARM processor has to configure the DSP, load DSP code and then release the DSP reset. This is normally done using Syslink using slaveloader which does a ProcMgr_open, ProcMgr_attach, ProcMgr_load and finally ProcMgr_start. The problem is that the debugger cannot attach to the DSP until after the DSP is released from reset which occurs after ProcMgr_start, but this means the code is already running. It would have been so much easier if I could have attached the debugger after ProcMgr_load, set the breakpoint and then start the code with ProcMgr_start. Unfortunately, it is ProcMgr_start that releases the reset on the DSP, so until that occurs, I cannot attach the debugger to the DSP. I would like to add some code to slaveloader that would allow it to place a breakpoint so that the processor would stop at that line after ProcMgr_start but before I have a chance to attach the debugger. Adding conditional loops to make the code loop endlessly until the debugger attaches is dumb as this requires a complete build every time I need a new breakpoint.

So here is my question. Given that Slaveloader has access to almost everything I need (map, code, DSP memory Read/Write, etc) how do I set a breakpoint on the DSP side using code on the ARM processor?

Regards,

John

over 13 years ago

0 desouza over 13 years ago

TI__Guru**** 171034 points

John,

I don't know of a way to set a breakpoint before a core is connected via JTAG, therefore leaving your only option as setting the forever loops. Sorry.

If you are using CCSv5 to build your application, you can reduce the overhead of build times by creating a separate project that contains your SYSBIOS configuration file and therefore any changes from a different project would not rebuild the SYSBIOS part of your application (if using CCS to build it).

A good reference is the forum thread below:

http://e2e.ti.com/support/embedded/bios/f/355/p/101656/359035.aspx

Cheers,

Rafael

0 john3909 over 13 years ago in reply to desouza

Intellectual 950 points

Hi Rafael,

That is a pity because the process as you describe is outlined in these two threads:

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

and

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

As you can see, the setup is lengthy and error prone. Given that I probably start a debug session many times each day, this is a complete waste of time. Isn't there a Pragma, Intrinsic or something similar to get the debugger to halt at predefined place in the code?

I am building my rtos and hlos in CCS, and the rtos and hlos output file have to be copied to a folder on the Linux filesystem. I'm trying to minimize the number of steps required between a new build and starting a new debug session.

A good place to start is to use RSE in CCS to save me copying the rtos and hlos files to the target board. How do I setup RSE in CCS since it doesn't look like it is installed by default and I cannot find RSE in "Install New Software"?

Next, it would be helpful to use GEL files on the DSP side to clear the loop variable and start the code. Do you have any examples on how to do this?

Thanks,

John

0 john3909 over 13 years ago in reply to john3909

Intellectual 950 points

Hi Rafael,

I have RSE running by following this wiki:

http://processors.wiki.ti.com/index.php/How_to_setup_Remote_System_Explorer_plug-in

BTW, why isn't it possible to make slaveloader work in a similar way to gdbserver. After all, gdbserver launches the application and enables CCS to connect via a specified port, but once connected, CCS shows the application stopped at the start of main().

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

I also found a wiki on GEL code to release the startup loop:

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

Regards,

John

0 desouza over 13 years ago in reply to john3909

TI__Guru**** 171034 points

John,

john3909 said:

BTW, why isn't it possible to make slaveloader work in a similar way to gdbserver. After all, gdbserver launches the application and enables CCS to connect via a specified port, but once connected, CCS shows the application stopped at the start of main().

GDBServer is a debugger on itself, thus having complete control over setting / resetting breakpoints. Slaveloader, on the other hand, is an application that is not able to programmatically set breakpoints on its own - only "forever loops"... (see below)

Cheers,

Rafael

0 john3909 over 13 years ago in reply to desouza

Intellectual 950 points

Hi Rafael,

I didn't mean to imply that the two programs were similar and I do understand the difference. I was only talking about functionality in that it would be helpful if there was a way to halt the program at the start of main or set a breakpoint at this location. Isn't there something equivalent to DebugBreak() or __debugbreak found in MSVC or __debug() found in the Tasking compiler?

Regards,

John

DebugBreak() or __debugbreak