ICD2 vs. ICD3
A few months ago, Microchip announced the new ICD3 In Circuit Debugger. There is only very limited information available on the advantages of the ICD3. So I decided to buy one, test it and compare the new unit with my 3 years old (still working) ICD2.
First, let's have a look at the debuggers (the ICD3 is on the right hand side on all pictures):
At the first glance, both devices look very similar. Both have a Hockey-puck shape (diameter 3.8", thickness: 0.9"), both have the same ICSP (RJ-11) and USB connector. On the new unit however the RS232 port and the 9VDC power supply connector is missing. The ICD3 is powered over USB.
Opening the plastic cases shows, that there have been a hole lot of changes. Indeed I did not find any active component that survived this redesign:
And even the bottom is populated now:
In the following, the part numbers are correct, but the connection between the parts is guessed. There are a lot of components on the board witch are not listed on the diagram.
The most prominent part on the PCB is the Spartan 3 FPGA XC3S100E-4TQG144 from Xilinx. Opposite to the FPGA there is the RAM located (2 x 512kB AS7C34096). The FPGA seems to be connected to the dsPIC33FJ256 (30MHz crystal, probably with 4x PLL) which might control the three DC to DC converters and the USB interface chip NET2272. One of the MCP1630 produces the adjustable 3..5V power for the target device, the other one generates the Vpp voltage. Both MCP1630 are clocked by an external 420kHz. The third step-up (MCP1652) produces a strange +17.7V and a whining at 5kHz. I don't know what this voltage is used is for, but you can find it at C18. Next to the DSP there is a 3.3V low drop regulator MCP1726, and near the FPGA we find the same linear regulator twice but for 1.2V and 2.5V. Both are powered from 5V (USB).
LED Color Description Power Green Lit when ICD3 is powered Active Blue Lit when power is first applied or when target is connected Status Green Lit when the debugger is operating normally – standby. Red Lit when an operation has failed. Orange Lit when the debugger is busy.
Trying to program without a target attached, results in "Active" off, "Status" red, and MPLAB hangs until you disconnect the ICD3 physically from the PC. I hope this changes in the near future.
- the ICD3 of cause
- a CD with the last stable version of MPLAB IDE (v8.3 right now)
- an USB A->B cable to use with the ICD3
- a small test target board: Populated with a PIC12F202, all FLASH-ROM programmed to 0x000, maybe code protected and labeled with v1.0:
- a RJ-11 cable
- a short instruction, a poster how to use the debugger, some more papers
- a notepad - first I thought it could be a printed manual, but I was wrong. How can I use this for debugging?
Forget about all that extra stuff: Grab the ICD3 and the USB cable, download and install the most recent version of MPLAB IDE here, and you are ready to go.
In the ICD3 there are are a lot more components compared to the ICD2. And these components are much more complex, too. So what are the advantages we developers gain from this redesign, and is this worth the higher price (ICD2 130€, ICD3 200€)? Lets have a look at the information Microchip gives us:
Features ICD3 (copied from )
- Real-time Debugging
- Ruggedized Probe Interface
- Microchip Standard Connectivity
- Portable, USB-powered and RoHS-Compliant
- High Speed Programming
- Low Voltage Emulation
- Test Interface Module.
- Ease of Maintenance and Feature Upgrade
- Low Cost
- Powerful Debugging
Features ICD2 (copied from )
- USB (Full Speed 2 M bits/s) & RS-232 interface to host PC
- Real time background debugging
- MPLAB IDE GUI (free copy included)
- Built in over-voltage/short circuit monitor
- Firmware upgradeable from PC
- Totally enclosed
- Supports low voltage to 2.0 volts. (2.0 to 6.0 range)
- Diagnostic LEDs (Power, Busy, Error)
- Reading/Writing memory space and EEDATA areas of target microcontroller
- Programs configuration bits
- Erase of program memory space with verification
- Peripheral freeze-on-halt stops timers at breakpoints
When comparing the features, there are not many advantages of the ICD3 left:
- ICD3 is promised to program up to 15x faster then ICD2
- ICD3 has a more ruggedised probe interface
- ICD3 can supply up to 100mA to the target with a programmable voltage (3..5V), the ICD2 only supports 5V supply
- ICD3 supports software breakpoints (only on devices that support them)
Personally I don't need the adjustable power supply in the ICD3. Most of my projects are 5V, and if I have a 3.3V target device, I have a laboratory power supply at hand. So no need for that feature. The software breakpoints are only supported on some devices. See the ICD3 Help under "Device Limitation" for your current device.
And there is a drawback: Using software breakpoints for debug impacts device endurance. Therefore, it is recommended that devices used in this manner should not be used as production parts (from ICD3 help).
The more robust interface to the target is really necessary: I managed to blow the I/O driver chips of my ICD2 (SN74AHC126) twice. So I hope this has now stopped.
Speed can never be enough, so I appreciate this point. But I want to know what "up to" means. For this test I took one of my older projects (PIC18F4680 on 40MHz) and measured the timing:
ICD2 ICD3 Time to connect to debugger first time after removal < 2 sec ~ 10.5 sec Program device (32kB) 10 sec ~2.8sec Read Program (32kB) 8.5 sec ~2.8 sec Debug: animate, "File Register" tab open (4kB read) 1100ms/step 77ms/step
So the speed is increased indeed, but not the programing times are reduced by a factor of 15: The animate function is now much faster! And its fun to see the registers changing.
When looking at the programing specifications of the PIC18F4680, we can determine the theoretical limit for programing this PIC:
My program is 32kByte so including some overhead there are around 320kbits to be transmited to the device. Let's assume a clock cycle time of 1MHz (the max at minimal Vdd) this needs 0.32sec. But the PIC18F4680 needs some additional time for programing the data to flash. This is a minumum of 1.1ms each 64 bytes payload resulting in additional 550ms. Taking into account the verify procedure that needs additional 320ms we get 1.27 sec for one write/verify cycle. This can just be a rough estimation, but the ICD3 is quite close to it.
To be honest, I think the ICD3 is an overkill: Now you have a FPGA with 1MB of RAM and a high performance DSP what an ordinary PIC16F877 has done before. With this effort you only gain a little more speed during programing, most likely the hardware is not used efficiently.
If you have tried the animate functionality together with the "File Register" tab and ICD2 and recognised the slow update rate, then maybe you discovered the "Watch tab" and the advanced breakpoints. For ICD2 this is the way to go. And you will hardly need the higher animate speed or the shorter programing times of the ICD3.
However, if you already blew up your output drivers once, then you know what a pain in the ass a dead debugger can be. And you will wish to have an ICD with more robust or easily replaceable buffers. The ICD3 is an option here, but please consider buying an third party ICD2 clone as well. They are available for a fraction the price of the ICD2, and have easily replaceable buffers.
There is no real reason to buy an ICD3: Nearly every chip you can debug with the ICD3 you can debug with ICD2 too. There is one exception: The dsPIC33FJ256GP710A is not available for ICD2 and in beta stage for ICD3 (MPLAB IDE ver 8.33). If you have some money left and don't know what to do with it, or if you are just interested in buying and trying new hardware, then go ahead and get the ICD3. 200€ is a fair price for such a bulk of complex hardware, but don't expect any miracle.
So far I have not heard of any ICD3 clone, but there is a nearly dead thread on edaboard.
So it's been over two years now since I wrote this little article, an while I am currently using the ICD3 I thought it is time for a short update: The ICD3 proved to be a very reliable tool in debugging PICs: It is fast, the ability to power small circuits of the debugger is great and I make heavy use of being able to set low Vdd voltages as well. I never managed to blow one of the output buffers (happened three times to me with the ICD2). So far there is still no clone of the ICD3, so get the original one now! And no, I am not associated with Microchip.
|< Prev||Next >|