As I mentioned previously, I am working on adding an officially supported CDT integration with gdb that can be used with JTAG hardware debugging devices. As a quick primer, JTAG devices allow you to have full control over the CPU and memory on a embedded computing board using a special connector that is now pretty much standard on all such boards. With debugging support, that means you can read and write memory and any memory mapped registers, read and write CPU registers, and set breakpoints. A lot of the JTAG vendors are starting to support integration of their devices with gdb as a front end to give developers a familiar interface, and for us on the CDT, allows us to leverage almost all of our existing gdb integration to provide an Eclipse UI interface.
JTAG debugging does have limitations. It's not overly fast, especially when compared to native debugging. Stepping through code takes around a second in the setup I have. And with most configurations, the JTAG debugger hardly works at all once virtual memory is turned on in the CPU, making process level debugging, as you normally do with OS's like Windows, Linux, QNX, etc, impossible. The biggest value of JTAG in the past has been for the initialization code that sets up the board and starts the operating system kernel. But that is starting to change though as JTAG debugger makers are figuring out how to do the virtual to physical and back translation and adding OS awareness in the debugger itself allowing for the full debug experience.
So I have the integration working now. With permission, I borrowed a lot of ideas from the Zylin Embedded CDT plug-in. Again, my hopes are to bring those guys and their customers on board to avoid the need for forking the CDT. It was pretty cool when I did my first debugger launch, and everything just worked. This is really the beauty of Eclipse and the CDT and the focus on extensibility, that makes adding new features a breeze.
Below is a picture of my set-up. I have a little TI OMAP board hooked up to a Abatron BDI2000 JTAG device hooked up to a network hub that eventually hooks up to my laptop. You can't see the screen, but trust me :), the CDT has reset the board, loaded in an image, started it up, and hit the breakpoint I had set. And you get all the CDT goodness like the variables, registers, and disassembly view. Tres cool!
My next step is to hook up qemu, the board emulator, with it's built in gdb remote stub, which works just like a JTAG device, to this whole thing so you can try it out without having to fork out money for real hardware...

Are you intending that your extensions are solely to support JTAG, or will this include BDM?
ReplyDeleteWe use Zylin's extensions with CodeSourcery's m68k-elf toolchain which comes with a gdb-elf-bdm stub (although it now seems to be called a sprite). This works well for us.
I don't know enough about the intricacies to know if the JTAGness or BDMness of the hardware debug interface is relevant, but I'm hoping to see built-in support for embedded debugging in CDT4.0.
Cherrs,
Paul.
We're closely replicating what Zylin has done, so I assume it'll handle BDM as well. The interface is really to gdb, and I don't think there is anything JTAG specific that we're doing. But then I don't really know the difference between JTAG and BDM. Feel free to raise bugs if it doesn't work for you.
ReplyDeleteHi Doug,
ReplyDeleteI'm not sure where I can post feedback about these extensions (CDT Newsgroup sometimes appears to be a bit of a black hole when all the developers are busy!) and I don't wish to become a pain so feel free to direct me elsewhere...
I've tried a couple of the nightly builds with a FreeScale mcf5282 cpu and CodeSourcery ColdFire GNU ELF toolchain using a P&E USB BDM interface and it all seems to work well.
I'll continue to test. When will it be worthwhile reporting any issues that I find?
Can you consider losing the JTAG in the name? Most embedded versions of GDB seem to hide away the messy communication details with stubs, sprites or whatever behind the pre- and post-launch commands. If you keep JTAG in there you may put off people using BDM, RS232, Ethernet, etc.
Maybe 'C/C+ Remote Application' would be an OK name for the launch configuration and cdt-gdbremote- for the extension?
Cheers,
Paul.
Feedback is posted in bugs or the cdt-dev mailing list.
ReplyDeleteThe launch configuration type is "GDB Hardware Debugging". I use that term everywhere except in the plug-in names. And then only because I needed something short, really only knew about jtag at the time, and because it's too hard to change once we get going.
I can't call it "C/C++ Remote Application" since there is another launch configuration type integrated with RSE which does that as well. This work is really targeted at Hardware Debugging where you need to change how the target get's initialized and run.
So is this available in CDT 4.0? Is it an additional plugin?
ReplyDeleteDoug,
ReplyDeleteThe jtag bdm enhancements are in CDT 4.0.2 right?? I am a newbie to the Eclipse,CDT package and was wondering are there any tutorials for setting up a gdb debug session with an embedded board that has JTAG/BDM??? I looked on the CDT site under news & noteworthy, it shows a tab under debug called startup that I don't see in my debug configuration dialog. Any help would be greatly appreciated!!
Thanks,
Brian