Re: Debugging TMS320, Step 1
- From: korenje <korenje@xxxxxxxxxxx>
- Date: Mon, 17 Aug 2009 22:44:41 -0700 (PDT)
On Aug 18, 4:43 am, Jack Klein <jackkl...@xxxxxxxxxxx> wrote:
On Mon, 17 Aug 2009 09:56:44 -0600, "Not Really Me"
<sc...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in comp.arch.embedded:
Radly wrote:
I maintain the code for a controller based on the TMS320R2811. My
system uses the boot loader to download the execuable code from a
host app, so I need to know how to set breakpoints after the download
is done. Someone else, long since gone, did the original
development, so I missed that stage of the development. So far, I've
been able to get by without a debugger, but those days are over. I
am now trying to figure out how to get started with simple debugging
(breakpoints and reading and setting variables). I understand that I
can order a USB JTAG cable, but then what? Where can I find a good
"getting started" guide? My questions are along the lines of "how do
I tell Code Composer I have the device hooked up?" "How do I set a
breakpoint in code the processor hasn't downloaded yet?" That sort
of thing.
I'm using CodeComposer 3.3.82.13, freshly updated today.
You are right about the USB JTAG for the job. It should interface directly
with CCS. I would recommend the 560 series from TI, but it is also made by
others and may be cheaper.
You can set a breakpoint at any time, so setting it before the code is
loaded is not a problem. When the address you have set the breakpoint on is
reached the code will stop. The bigger problem may be knowing what those
addresses are. The code is presumably linked for where it is loaded, so you
may be able to do debugging with full source information.
As to telling CCS that the device is hooked up, once you have told CCS that
you are using the JTAG emulator it will not start until it can talk to the
JTAG. If I remember right, the CCS setup utility will be invoked
automatically if it can not communicate with the device.
Scott
Scott,
Your advice is pretty good, but there is one point where the OP might
save a little money.
The 28xxx leaves out some of the fancy debug features of some of the
other TI DSP families, so there is no real gain in paying more for a
560 series JTAG debugger over a 510 class device.
--
Jack Kleinhttp://JK-Technology.Com
FAQs for
news:comp.lang.chttp://c-faq.com/
news:comp.lang.c++http://www.parashift.com/c++-faq-lite/
news:alt.comp.lang.learn.c-c++http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
I agree with Jack, the 560 series is an overkill for C28xx devices.
Regarding the breakpoints, I would like to remind you that there are
two kinds:
Hardware breakpoints which are basically program counter comparators
and you can set only two of them and
Software breakpoints which are basically assembly "ESTOP0"
instruction. You can set any number of them, but only in RAM, and they
can be overwritten by the CPU. Therefore SW breakpoints must be set
after the code was loaded. You were warned.
Once you are connected to the CPU you should load symbols from the
compiler generated .out file so that CCS can link the source files
(.c, .asm) with program counter in order to have the ability to step
through the code, not only through disassembly
Good Luck
Mitja
.
- References:
- Debugging TMS320, Step 1
- From: Radly
- Re: Debugging TMS320, Step 1
- From: Not Really Me
- Re: Debugging TMS320, Step 1
- From: Jack Klein
- Debugging TMS320, Step 1
- Prev by Date: Re: Unable to handle kernel paging request at vitual address
- Next by Date: Re: Debugging TMS320, Step 1
- Previous by thread: Re: Debugging TMS320, Step 1
- Next by thread: Re: Debugging TMS320, Step 1
- Index(es):
Relevant Pages
|
