There’s indeed some confusion out there about the new SWD interface. SWD is the new debug interface for all Cortex cores (MO and M3), but there are certain Cortex M3 chips that support both SWD and the classic JTAG interface found on ARM7/ARM9 chips. The LPC1700 family from NXP is an example of this (you can use classic JTAG debuggers with it). Generally, this dual JTAG+SWD interface (called SWJ-DP) is only present on chips with higher pins counts. Many of the smaller Cortex chips ONLY support SWD (the SWD only interface is named SW-DP), such as the LPC1300 and LPC1100 family.
The biggest problem will be with the SWD only chips since there aren’t that many SWD hardware debuggers out there (that I know of). There is Keil’s uLink (tied to their own IDE, uVision), Segger’s J-Link for ARM (which works with most current IDEs), and the LPCXpresso (which is tied to their freely available, 128KB IDE based on Code Red’s Red Suite).
OpenOCD doesn’t currently support SWD and I suspect it may be some time before support is added (though since I don’t use it myself you may want to contact the authors directly to get a better indication of when SWD support might be added). If you’re a hobbiest I would recommend either using the LPCXpresso and the free IDE (the board with a built in SWD debugger is only $29) or purchasing a non-commercial Segger J-Link which works with almost any IDE ($150).
SWD offers a number of advantages over JTAG, but the big one is that you have as many as 8 HW breakpoints (versus 2 with JTAG), and the fact that it’s essentially a two-wire interface meaning the connectors take a lot less board space.
I’m sure new SWD debuggers will start showing up in 2010, but for the moment the choice is fairly limited, and there is pretty much nothing on the open-source side of things.
gussy:
Do you know if it’s possible to use LPCXpresso with non LPC Cortex devices?
Downloading and installing it seems like a lot of work just to see if it does.
I believe that it supports both SWD and JTAG, but LCPXpresso it tied to certain chips. The entire 1100 and 1300 family, the ARM9 3130, and a couple other chips but I don't remeber which off the top of my head. It's really just being offered as an entry point to Cortex development, but clearly Code Red is hoping you'll move up to their full development environment where you can use any chip.
Looking quickly you can use the 1751, 1752, 1754 and 1764 (M3), 2109, 2134, 2142, and 2362 (ARM7), and 3130 (ARM9).
Coocox provide a complete tool chain for Cortxe-M3, include Coocox Builder(integrate GCC), Coocox Debugger(integrate GDB), Coocox flash, Coocox OS, Coocox link(support MDK,IAR and Coocox Debugger).
Thanks for the advice. I’ve heard of LCPXpresso, and now I will look into Coocox as well.
Honestly the new debugger doesn’t interest me much at this point. I don’t even use a JTAG in my personal projects. I plan on using Flash Magic to upload the code through serial. I downloaded the latest version and it has the 1768, so I hope I’m good to go.
I’m about to start drawing the schematic, and I want a warm fuzzy about how I’m going to develop.
LooseTooth:
I think I’m going to try Rowley. At $150 for the hobbyist, it sounds like a good deal and seems to be somewhat ubiquitous.
Crossworks is a no-brainer for the price. It’s definately the best IDE out there for embedded development, and is easy to learn for anyone coming from Visual Studio. You can’t beat it for the fact that it simply works, and works well, right out of the box.
I was just playing around with it a bit for a LPC1343 board I put together and was able to get CTL (the task-scheduler that comes with Crossworks) up and running in about 15 minutes … and I’d never used it before. I’m a big fan of FreeRTOS, but CTL has a smaller footprint which is helpful on parts like the 1343 with only 32KB flash and 8KB SRAM. I’ll stick to FreeRTOS on larger chips, but it’s nice to have an easy-to-setup alternative available.
boothowto:
The CM3 “virtue” is made with the reversed disciplines; extremely short pipleline and cache less memory architecture. Note that longer pipeline and complicated cache mechanics have been the essentials of modern ultra fast processors.
The cacheless microcontrollers are fantastic when coupled with fast SRAM. The smaller cacheless die and 1/4th clock rate to accomplish the same as a cached DRAM pairing makes for low BOM cost and power efficiency. As long as the footprint is small enough to execute out of on-chip NOR flash and fit the data set in 512k-1MB. Which, frankly, is a lot when you don't need e.g. Linux. But as soon as resource needs run into DRAM+NAND territory a cache is a prerequisite IMO or it's just going to be dog slow.