I think my ICD3 is shagged

[Pineapple Dan]

I can still use it to program the chip but only the first time I launch MPLAB-X otherwise I get "failed to program device". If I change some setting prior to programming it always works such as changing from 'Allow ICD3 to select memories to program' to 'manually select memories and ranges' it also works

Debug plain doesn't work.

Have installed mplab on 2 other computing machines and same problem. Mplab IPE does allow me to program multiple devices in succession without changing settings. Any ideas before I horse it into the bin?

I changed from PIC16 to PIC8 and back to make it re-load firmware/fpga and it spewed out loads of errors but did eventually load them, however upon going back to pic16 which I am using now it does the same thing. Have tried a couple of PIC16 chips to rule out that it's the chip.

[AaronLee]

Try to manually reprogram the firmware in the ICD3. Don't trust MPLAB to do it correctly automatically. You may need to unplug the USB cable after completing and the plug it back it. It's very temperamental. Also, if you use a combination of the old MPLAB and MPLABX, you may need to use the driver switcher utility to get it to work correctly. Those two points are what typically caused me headaches with the ICD3 in the past. If all else fails, reboot your PC and again manually reprogram the firmware.

[fcb]

Try MPLAB 8.92 (before MPLAB X) before you consign it to the circular file.

[NorthGuy]

Looks like a bug in MPLAB X to me. Try few different versions, including older ones, especially if your PIC16 is old. For each version you may need to update the firmware, as it changes from version to version.

[SiliconWizard]

I would first try with a different version of MPLAB X, and/or MPLAB 8.xx as suggested above, before anything else.

If the same still happens... then I dunno. The hardware may be borked in some way? I've seen ICD3 and ICD4 interfaces go flaky too. AFAIR, Microchip wasn't too difficult to deal with and would replace them relatively easily. Dunno if that's still the case.

But I'm definitely glad I do not use Microchip parts anymore. And to think I was still almost "swearing" by them a few years ago. But dev tools really started annoying the heck out of me.

[AaronLee]

But I'm definitely glad I do not use Microchip parts anymore. And to think I was still almost "swearing" by them a few years ago. But dev tools really started annoying the heck out of me.

I would love to not need to use Microchip MCUs anymore. Unfortunately whenever I try to change, it seems that other comparable parts from other companies don't have as good of availability as Microchip, and tight production schedules mean we must stick with Microchip. And with years of experience, you get to know the quirks. It still annoys me though how lame their development tools are.

[Pineapple Dan]

Thx for replies everyone. I will try the old mplab. Am using it with 8bit MCUs the past few day and has been fine, will see what happens when I go back to the 16

[NorthGuy]

But dev tools really started annoying the heck out of me.

About half a year ago, it finally got me when it took 3 minutes to open because it was doing "background scanning of projects". So, I switched to a text editor and it works much better for me.

I don't think MPLAB X is so much worse than others. Most all bloated and buggy. And this is not likely to change any time soon

[mazurov]

Do you still have a test module which comes with ICD3? P/n AC164113. With this thing attached you can test your puck right from MPLAB-X. Also, the previous pucks (ICD1 and 2) were covered by a lifetime warranty, I have to use it once with ICD2. Perhaps, ICD3 is covered too?

[SiliconWizard]

But dev tools really started annoying the heck out of me.

About half a year ago, it finally got me when it took 3 minutes to open because it was doing "background scanning of projects". So, I switched to a text editor and it works much better for me.

I don't think MPLAB X is so much worse than others. Most all bloated and buggy. And this is not likely to change any time soon

Yep. I didn't care much about this - when I was still using Microchip MCUs, I never used MPLAB X either. But too bad most Microchip MCUs didn't support standard tools, so you still had to use MPLAB X for certain things. I would use their standalone programming software for flashing the MCUs, much lighter than launching MPLAB X, but still pretty annoying to use.

Oh, and how much I hated all Microchip programmers (from the entry-level ones to the ICD4) requiring a firmware update every time you wanted to connect to a different family of PIC... lasting a couple minutes sometimes. How fricking annoying. To the point that if you were ever working with several PIC families at the same time, you would usually end up buying several programmers. Seriously Microchip... 

[AaronLee]

But dev tools really started annoying the heck out of me.

About half a year ago, it finally got me when it took 3 minutes to open because it was doing "background scanning of projects". So, I switched to a text editor and it works much better for me.

I don't think MPLAB X is so much worse than others. Most all bloated and buggy. And this is not likely to change any time soon

Yep. I didn't care much about this - when I was still using Microchip MCUs, I never used MPLAB X either. But too bad most Microchip MCUs didn't support standard tools, so you still had to use MPLAB X for certain things. I would use their standalone programming software for flashing the MCUs, much lighter than launching MPLAB X, but still pretty annoying to use.

Oh, and how much I hated all Microchip programmers (from the entry-level ones to the ICD4) requiring a firmware update every time you wanted to connect to a different family of PIC... lasting a couple minutes sometimes. How fricking annoying. To the point that if you were ever working with several PIC families at the same time, you would usually end up buying several programmers. Seriously Microchip... 

Ditto for most of what you said. MPLAB had lots of bugs/issues and could be annoying at times, but MPLAB X was a huge step backwards in my opinion. I'm forced to use it because MPLAB doesn't support the newer parts/tools, but I'd gladly choose MPLAB over MPLAB X if it supported everything.

Yeah, it's so annoying how it has to redownload firmware, not just when changing to a different PIC family, but also when changing between MPLAB and MPLAB X, or even a different version of MPLAB X. I ended up buying several PIC KIT 3's for the same reason as you did, and marked each one for which family it's for, and then just used those for programming using a fixed version of their IPE, so that I didn't need to wait for reprogramming the firmware each time.

[AaronLee]

Thx for replies everyone. I will try the old mplab. Am using it with 8bit MCUs the past few day and has been fine, will see what happens when I go back to the 16

If it's working with 8-bit PICs, then your ICD3 is probably fine. If you use MPLAB, realize you almost certainly can't just load a project from MPLAB X and have it work in MPLAB. They're not compatible. If you want to use MPLAB, you'll need to remake your projects in MPLAB and I'm not sure if MPLAB can use the newest compilers or not. MPLAB also can't be used with the newest PIC MCUs that came after the last version of MPLAB was released.

Now if you switch between MPLAB and MPLAB X, it's imperative when using the ICD3 to run Microchip's driver switcher and tell it if you're using MPLAB or MPLAB X with the ICD3. If you don't do that, it'll almost certainly not work. I think the PIC Kits work ok without switching, but not the ICD3. And as I mentioned earlier, if you still have a problem manually force the reprogramming of the ICD3 firmware. I run into this issue almost weekly where the programmer doesn't work until I manually do it, rather than letting MPLAB / MPLAB X do it automatically.

I had a customer who had a box of a dozen Microchip programmers he claimed were all dead. He gave them to me and not one of them were dead, but all of them magically started working again just by manually downloading the firmware. I gave him back his box of programmers, all working, told him what to do if they stopped working again, but a year later he told me they all stopped working. I asked him if he manually downloaded the firmware, and he gave me a puzzled look. Sure enough, he didn't take my words seriously, and manually downloading the firmware once again magically fixed all his "broken" programmers. If you're just using one dedicated PIC series, and one fixed version of MPLAB or MPLAB X, this typically isn't an issue. But if you're switching around, the problem will almost certainly rear it's ugly head and you must manually reprogram the firmware to clear it.

[Sal Ammoniac]

Ditto for most of what you said. MPLAB had lots of bugs/issues and could be annoying at times, but MPLAB X was a huge step backwards in my opinion. I'm forced to use it because MPLAB doesn't support the newer parts/tools, but I'd gladly choose MPLAB over MPLAB X if it supported everything.

I was so glad to leave MPLAB behind when MPLAB X came out. I hated its dated, Windows 3.1-style MDI interface. Yuck. 

[AaronLee]

Ditto for most of what you said. MPLAB had lots of bugs/issues and could be annoying at times, but MPLAB X was a huge step backwards in my opinion. I'm forced to use it because MPLAB doesn't support the newer parts/tools, but I'd gladly choose MPLAB over MPLAB X if it supported everything.

I was so glad to leave MPLAB behind when MPLAB X came out. I hated its dated, Windows 3.1-style MDI interface. Yuck. 

But MPLAB was fast. I can't overemphasize how the speed of an IDE is a critical factor for me. A slow IDE slows my productivity way down. For minor changes, the edit/build/debug cycle on MPLAB is several times faster than with MPLAB X. I don't need all the bloated functions of most modern IDEs. Just give me a basic one built for speed, and without major bugs, and I'm happy. I couldn't care less how dated the GUI is, as long as it gets the job done, and it functions like all standard Windows applications.

[SteveyG]

Newer versions of MPLAB have increased the programming speed. Make sure the PGC and PGD lengths are short - even the original 200mm programming cables that used to come with the ICD2 no longer work. On the latest version of MPLAB total length usually needs to be less than 150mm.

[Sal Ammoniac]

Ditto for most of what you said. MPLAB had lots of bugs/issues and could be annoying at times, but MPLAB X was a huge step backwards in my opinion. I'm forced to use it because MPLAB doesn't support the newer parts/tools, but I'd gladly choose MPLAB over MPLAB X if it supported everything.

I was so glad to leave MPLAB behind when MPLAB X came out. I hated its dated, Windows 3.1-style MDI interface. Yuck. 

But MPLAB was fast. I can't overemphasize how the speed of an IDE is a critical factor for me. A slow IDE slows my productivity way down. For minor changes, the edit/build/debug cycle on MPLAB is several times faster than with MPLAB X. I don't need all the bloated functions of most modern IDEs. Just give me a basic one built for speed, and without major bugs, and I'm happy. I couldn't care less how dated the GUI is, as long as it gets the job done, and it functions like all standard Windows applications.

MPLAB X runs very fast on my development PC. I suppose if you have an older machine or a less capable one that would be an issue.

[AaronLee]

Ditto for most of what you said. MPLAB had lots of bugs/issues and could be annoying at times, but MPLAB X was a huge step backwards in my opinion. I'm forced to use it because MPLAB doesn't support the newer parts/tools, but I'd gladly choose MPLAB over MPLAB X if it supported everything.

I was so glad to leave MPLAB behind when MPLAB X came out. I hated its dated, Windows 3.1-style MDI interface. Yuck. 

But MPLAB was fast. I can't overemphasize how the speed of an IDE is a critical factor for me. A slow IDE slows my productivity way down. For minor changes, the edit/build/debug cycle on MPLAB is several times faster than with MPLAB X. I don't need all the bloated functions of most modern IDEs. Just give me a basic one built for speed, and without major bugs, and I'm happy. I couldn't care less how dated the GUI is, as long as it gets the job done, and it functions like all standard Windows applications.

MPLAB X runs very fast on my development PC. I suppose if you have an older machine or a less capable one that would be an issue.

In thinking about my reply more, and my workflow, I need to qualify it.  I don't use the editor in MPLAB, or MPLAB-X. I use an external editor.  When thinking though about someone who did use the editor in MPLAP, I realized your complaint about it using MDI. Yeah, that was a pretty stupid approach, and even during debugging sometimes if I wanted to set a breakpoint in a different file, it was a bit of a pain. Anyways, the point where the speed difference is very noticeable to me is in the programming of the device. MPLAB-X seems to be going through hoops just to connect compared to MPLAB. Also on initialization (starting the app), MPLAB-X must be 10x or more slower, and inevitably needs to be restarted at least a few times during the day, and dealing with the ridiculous initialization time again. I've used it on many different PCs, including very modern and speedy systems, but still notice the speed difference in those two areas.

[Sal Ammoniac]

Ditto for most of what you said. MPLAB had lots of bugs/issues and could be annoying at times, but MPLAB X was a huge step backwards in my opinion. I'm forced to use it because MPLAB doesn't support the newer parts/tools, but I'd gladly choose MPLAB over MPLAB X if it supported everything.

I was so glad to leave MPLAB behind when MPLAB X came out. I hated its dated, Windows 3.1-style MDI interface. Yuck. 

But MPLAB was fast. I can't overemphasize how the speed of an IDE is a critical factor for me. A slow IDE slows my productivity way down. For minor changes, the edit/build/debug cycle on MPLAB is several times faster than with MPLAB X. I don't need all the bloated functions of most modern IDEs. Just give me a basic one built for speed, and without major bugs, and I'm happy. I couldn't care less how dated the GUI is, as long as it gets the job done, and it functions like all standard Windows applications.

MPLAB X runs very fast on my development PC. I suppose if you have an older machine or a less capable one that would be an issue.

In thinking about my reply more, and my workflow, I need to qualify it.  I don't use the editor in MPLAB, or MPLAB-X. I use an external editor.  When thinking though about someone who did use the editor in MPLAP, I realized your complaint about it using MDI. Yeah, that was a pretty stupid approach, and even during debugging sometimes if I wanted to set a breakpoint in a different file, it was a bit of a pain. Anyways, the point where the speed difference is very noticeable to me is in the programming of the device. MPLAB-X seems to be going through hoops just to connect compared to MPLAB. Also on initialization (starting the app), MPLAB-X must be 10x or more slower, and inevitably needs to be restarted at least a few times during the day, and dealing with the ridiculous initialization time again. I've used it on many different PCs, including very modern and speedy systems, but still notice the speed difference in those two areas.

What debugger are you using? I've found the PICkits to be unbearably slow. ICD3 is much better and ICD4 is better still.

[AaronLee]

What debugger are you using? I've found the PICkits to be unbearably slow. ICD3 is much better and ICD4 is better still.

I have several PICKit 3's and several ICD3's, along with one PICKit4 and one ICD4. I haven't used the PICKit 4 enough to really gauge it's speed, but definitely the PICKit 3's are very noticeably slower than the ICD3. And the ICD3 isn't as fast as the ICD4. Both the PICKit 4 and ICD4 are incompatible with MPLAB, AFAIK, being they were introduced after the last version of MPLAB was released. So the PICKit 4 and ICD4 are only used with MPLAB-X, meaning comparing MPLAB with MPLAB-X is only meaningful for me with regard to PICKit3 and ICD3. I've not actually sat down and timed them, but just from what I feel is the situation based on real-life use, there's two parts of concern: the initial handshake/initializing and then the actual hex file download. The actual hex file download I believe is the same between MPLAB and MPLAB-X, and is highly dependent on the size of the hex file and whether using PICKit3 or ICD3. For the initial handshake/checking, it seems relatively similar between PICKit3 and ICD3. But between MPLAB and MPLAB-X, MPLAB is very quick, and MPLAB-X is very slow. That is where my big complaint is about MPLAB-X.

I have a few projects running on a graphics PIC32MZ, with the hex file being multiple megabytes. This is painfully slow on a PICKit. And noticeably faster on the ICD4 compared to ICD3, so I use the ICD4 in those cases, along with MPLAB-X, being MPLAB doesn't support the PIC32MZ. By far, the majority of the download time is in the actual hex file data being transferred, not in the handshake/initialization. Most of my projects though are much smaller, with hex files in the 1 to 30KB range. For smaller hex files, the slow handshake/initialization of MPLAB-X dominates, and is a significant factor in my edit/compile/download/debug cycle for issues that involve minimal editing/thinking. This type of work is very common when I'm dealing with Microchip MCU work. Thus it's one of my major complaints with MPLAB-X. Furthermore, if the debugger becomes disconnected from the PC (USB interface), MPLAB-X comes up with a dialog box, and if you do the default/intuitive action, it then automatically rebuilds your entire project, further exasperating things, as it ads even more time. I finally figured out recently that if I cancel that, then just download again, it doesn't recompile, but why it thinks it needs to recompile otherwise, I'll never know. This problem happens very frequently because on the ICD4 they made a poor decision to use a USB Mini connector rather than the USB B on the ICD3. At least on my ICD4, as well as lots of USB Mini gear, the connection is not tight and frequently comes disconnected. Perhaps my ICD4 is defective, as it seems to happen much more frequently on it than on any other USB Mini gear I own. It can happen dozens of times in a day. MPLAB with the ICD3 or PICKit 3 handles well if the connection is disconnected. MPLAB-X handles any debugger being disconnected very poorly.