Microchip ICD5 : Firmware Update?

[Martin72]

Hi all,

I bought an ICD5 for work and can't get it to work.
More specifically, when I try to connect the ICD5 to a controller, I get the message "Transmission failed (Error Code -109).
I googled it and found that someone had success by performing a firmware update.
I went to the Microchip website and found everything—except firmware updates.
My work computer runs Windows 10 and has IPE 6.20 as the programming software.
The programmer is recognized in IPE, but then I get the error message when I try to connect the programmer to a controller to upload a hex file.
I hope that I can solve the problem with a firmware update.
But where can I get an update?
Thank you for any helpful advice.

Martin

[0xdeadbeef]

Question is which controller you want to reprogram. I recently reprogrammed an AtTiny814 with a PicKit 5 using UPDI.
At least in this scenario there are cases where the PicKit5 5 has to create 12V pulses on the UPDI pin to re-enable the UPDI functionality (as the pin is also a reset pin).
So, I had to enable "high voltage pulses" (or so) somewhere in the project setting to finally be able to read out the fuses from the AtTiny and finally reprogram it.
Without that, I would also just get some failure messages.

[mikeselectricstuff]

MPLABX IDE/IPE will usually update firmware automatically as required, at least that's how it's supposed to work. Have you tried with latest version ?

[fchk]

I googled it and found that someone had success by performing a firmware update.
I went to the Microchip website and found everything—except firmware updates.
My work computer runs Windows 10 and has IPE 6.20 as the programming software.

The firmware is delivered with the MPLABX IDE/IPE. You should update to 6.25.

[Martin72]

Thank you guys.
OK, then I guess we'll have to install version 6.25.
Or rather, let our administrators do it, because only they can install programs on the computers.
What bothers me a little about this is that one of our external software developers also has an ICD5, and it works without any problems...

Question is which controller you want to reprogram.

We develop our own control electronics and use only Microchip controllers.
The models vary depending on the complexity of the tasks and can be simple 18F types, but also larger DSPics.
Originally, I wanted to buy ICD4 programmers for the test field, but they are obsolete, so I chose the ICD5 instead.

[Martin72]

Interesting thing today....
Our ICD5 works for another colleague, so it must be a problem with the notebook or the system.
Once we've figured it out, I'll post the solution here, because judging by the search results, I'm not the only one with this problem.

[SiliconWizard]

I so do not miss Microchip dev tools.

[Martin72]

The entire Microchip environment is a disaster in terms of productivity.
The task in the test lab is simple: load an existing program onto a controller and then test the system.
My employees should just do their job, which is testing.
But it's always a pain in the ass with Microchip.
What worked without any problems yesterday can cause extra work tomorrow because the whole system is acting up.
What worked with the ICD3 now only works with the ICD4—even though it worked differently before. Five circuit boards were programmed successfully, but the sixth one doesn't work. Restart everything, and then it works again, etc., etc.
Terrible.
You could also use a different programmer/software, because the test field is only concerned with transferring a hex file.
But then the previously calculated checksum would be incorrect, which is a problem.
Ergo, we have to use the Microchip stuff.
And that junk is simply unreliable.
Enough crying.

[free_electron]

That's why i refuse to use any longer micros that do not have a built-in bootloader over USB (DFU or HID) or UART. I have a whole drawer full of those programmer dongles. 6 generations of Segger, Two Keil generations, Hitex, IAR, Atmel, pickit 1 through whatever, stlinks and a number of others.  They are all outdated, no longer supported, work only with version xyz of the tools, only on this flavor of OS,  and are an endless headache to get going and maintain. And they need connectors, or a tag-connect footprint on the board.

If it can't be loaded using a simply UART or USB<>UART i don't want it anymore. Plug a USB cable in and go.

[SiliconWizard]

SWD works just fine and there are tons of available and reliable adapters at all kinds of prices. Of course, that "restricts" it to the ARM-based MCUs.

[0xdeadbeef]

Yup, I usually only use ARM cores, also because I can debug with SWD (or JTAG) and I use the same Segger Plus since many, many years which is supported by all ARM IDEs and you can debug and reprogram with Segger standalone tools without bloated IDEs.

[mikeselectricstuff]

If it can't be loaded using a simply UART or USB<>UART i don't want it anymore. Plug a USB cable in and go.

...except both of those are often slower than a dedicated programmer, which can get annoying real fast when using for development. Ant develompent setup that doesn't have one key to build & program in no more then 5 seconds is a non-starter for me.

IME Pickit 4 was "Peak Pickit", and things are doing downhill from there. When they work, Microchip programmers have the very useful ability to download the code to them and operate as standalone programmers, which is a huge benefit for production. Knockoff Pickit 3's are cheap enough to treat as consumables.
Unfortunately Microchip have never understood how to properly protect programmers from overvoltage abuse, or deal gracefully with errors.
Luckily they offer a no-quibble replacement for faulty units, even out of warranty.