I think my ICD3 is shagged - Page 1
Forum section: electronics / general

author: Pineapple Dan
author_rank: Contributor
timestamp: July 20, 2021, 08:23:37 am
content: 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 worksDebug 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.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 20, 2021, 08:45:13 am
content: 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.

author: fcb
author_rank: Super Contributor
timestamp: July 20, 2021, 09:20:28 am
content: Try MPLAB 8.92 (before MPLAB X) before you consign it to the circular file.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 20, 2021, 02:20:49 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 20, 2021, 04:41:27 pm
content: 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.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 21, 2021, 12:12:04 am
content: Quote from: SiliconWizard on July 20, 2021, 04:41:27 pmI 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.

author: Pineapple Dan
author_rank: Contributor
timestamp: July 22, 2021, 01:21:00 pm
content: 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

author: NorthGuy
author_rank: Super Contributor
timestamp: July 22, 2021, 02:35:03 pm
content: Quote from: SiliconWizard on July 20, 2021, 04:41:27 pmAbout 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

author: mazurov
author_rank: Frequent Contributor
timestamp: July 22, 2021, 05:18:22 pm
content: 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 22, 2021, 05:38:28 pm
content: Quote from: NorthGuy on July 22, 2021, 02:35:03 pmYep. 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...

author: AaronLee
author_rank: Regular Contributor
timestamp: July 23, 2021, 12:34:28 am
content: Quote from: SiliconWizard on July 22, 2021, 05:38:28 pmDitto 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.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 23, 2021, 12:45:38 am
content: Quote from: Pineapple Dan on July 22, 2021, 01:21:00 pmIf 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 27, 2021, 04:08:08 pm
content: Quote from: AaronLee on July 23, 2021, 12:34:28 amI was so glad to leave MPLAB behind when MPLAB X came out. I hated its dated, Windows 3.1-style MDI interface. Yuck.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 05:42:18 pm
content: Quote from: Sal Ammoniac on July 27, 2021, 04:08:08 pmBut 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.

author: SteveyG
author_rank: Unknown
timestamp: July 27, 2021, 08:14:20 pm
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 27, 2021, 09:58:37 pm
content: Quote from: AaronLee on July 27, 2021, 05:42:18 pmMPLAB 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.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 27, 2021, 10:53:40 pm
content: Quote from: Sal Ammoniac on July 27, 2021, 09:58:37 pmIn 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 28, 2021, 08:39:39 pm
content: Quote from: AaronLee on July 27, 2021, 10:53:40 pmWhat debugger are you using? I've found the PICkits to be unbearably slow. ICD3 is much better and ICD4 is better still.

author: AaronLee
author_rank: Regular Contributor
timestamp: July 29, 2021, 12:19:57 am
content: Quote from: Sal Ammoniac on July 28, 2021, 08:39:39 pmI 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.