Hi all, I deal with this regularly, I have a project in MPLAB 8.9 with a=20 PIC18F44J10, and a project in MPLAB X with a PIC16F1789 and PIC18F47J53=20 (on the same pcb). I use the ICD3 on Windows 7. It is a frustrating inconsistent nuisance.=20 Microchip has failed to make this work cleanly. I've lost hours to=20 this, but now I have a system in place (wasting some time each time I=20 have to do it) to work around Microchip's FAIL. The problems arise from two issues: 1) switching MPLAB 8 and MPLAB X 2) switching chip families, requiring a firmware download into the ICD3. I have had the killer situation where everything seems ok, i.e. MPLAB=20 8/X thinks the firmware in the ICD3 is correct, but it is NOT. Then you=20 get fail to read the chip errors, and can spend as much time as you want=20 to waste trying to find the fault in the cable, the chip, your design. Here is what I do. If there is ANY doubt as to the ICD3's firmware, go to the driver=20 switcher (running as administrator of course) and switch drivers. If it=20 seems like MPLAB X/8 should be reading the chip but is not, go do the=20 driver switch as well. If you've switched drivers for MPLAB X, go to the "IPE" program and=20 select the chip, then connect to make SURE it is reading it right. This=20 will trigger the ICD3 firmware download as needed. Now in MPLAB X, it doesn't have anything to do, the ICD3 should be all=20 set for it. The "IPE" seems much better at dealing with the ICD3=20 drivers than MPLAB X. Since there isn't a standalone programming utility for MPLAB 8 (at least=20 I don't have something), you can't do this. But it seems MPLAB 8 is=20 better at knowing when the ICD3 needs new firmware. You could do the=20 above in the IPE, verifying that your chip reads ok, then switch drivers=20 to MPLAB 8. MPLAB X usually, but not always, can handle switching between the 18FJ=20 and the 16F chips I have going on the same pcb. (Separate projects in=20 MPLAB, of course). When it fails, maybe 1 time in 4, I do the above=20 rigamarole to get going again. Dozens of times so far in the last 3 weeks. I'm really over the Microchip tool problems. TI's stuff works better in=20 my experience and their forums are much better, with genuine TI=20 employees writing frequently. J Isaac Marino Bavaresco wrote: > What I have noticed is that PICKIT3 and ICD3 get in trouble with MPLAB > IDE v8.92 after entering in contact with MPLAB X IDE. > > If I connect an ICD3 or PICKIT3 to a machine running MPLAB IDE v8.92 and > the debugger's firmware is for a different PIC family, then MPLAB IDE > replaces the debugger's firmware (debug executive, etc.) and it can't > program or debug, although those same firmware versions used to work > previously. > > If I connect the same ICD3 or PICKIT3 to the same machine running MPLAB > X IDE, then MPLAB X updates the debugger's firmware to newer versions > and the debuggers work. An interesting point is that if I switch back to > MPLAB IDE and the debugger has the firmware for the correct PIC family, > it accepts the newer version and programming and debugging works OK. > > It seems that with MPLAB X IDE, Microchip has "poisoned" the ICD3s and > PICKIT3s against the older firmware versions that used to work in MPLAB I= DE. > > > Isaac > > > On 27/02/2015 05:14, embedded systems wrote: >> Just added the correct tag. Else just a few people will see your message= .. >> >> My PICkit 2 lost his firmware while powering up the PC while it was >> connected to the USB. I reloaded the firmware with a Tait programmer. >> Since then I connect it to the PC AFTER the PC turned on. Everything go= es >> ok since then. >> >> Vasile >> >> On Thu, Feb 26, 2015 at 3:08 AM, John J. McDonough >> wrote: >> >>> I have an odd one. >>> >>> For quite a while I have had a PICkit 3 and an ICD 3. Generally I have >>> used them almost interchangeably, until recently when I started doing >>> some PIC32 stuff and the speed difference became more obvious. So the >>> PICkit sat on my desk until I finally put it back in it's packaging and >>> set it on the shelf. >>> >>> I had an ICD 2 which I traded for an ICD 3, and when the new debugger >>> arrived I tried it out, worked fine, didn't change back to the old ICD >>> 3, so put the old one back in the packaging and on the shelf. >>> (Sometimes I do some stuff that needs multiple debuggers, and I plan on >>> a build session for the radio club in a couple months where I could use >>> a bunch). >>> >>> OK, so a friend needed a programmer, I lent him the PICkit, and he >>> couldn't make it work. >>> >>> I had him bring it back here, along with his board, in case there was >>> some wiring or configuration issue. I couldn't program his board, or >>> any other for that matter, with the PICkit, programmed fine with the >>> ICD. So, I got the old ICD back out, and it wouldn't program anything >>> either! >>> >>> Recently almost everything I have been doing has been powered by the >>> programmer, and I never do anything with significant voltages. What >>> could cause multiple programmers to bite the dust in such short order? >>> Any ideas? >>> >>> --McD >>> >>> >>> -- >>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >>> View/change your membership options at >>> http://mailman.mit.edu/mailman/listinfo/piclist >>> > > > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .