MPLAB ICD 4 is EOL!

[Zucca]

Probably already known for most of you, but to me it was a suprise...

https://www.microchip.com/en-us/development-tool/dv164045

Product is End of Life (EOL), please consider MPLAB® PICkit™ 4 or MPLAB ICE 4 for your design needs.

Probably the business case for the ICD 4 was deep red... and they are now trying to get some traction on the new ICE4....

[bentyler]

The price of the ICE4 is $1800.. What a throwback to the good old days lol.

[BradC]

At least the Pickit 4 is still current.

[JPortici]

https://www.microchip.com/forums/FindPost/1218954
ICD4 used Spartan 6
AMD/Xilinx EOL'd with no last time buy possibility

[SiliconWizard]

Crazy. So now it's either an expensive professional tool or crap for hobbyists. Nice move. Well maybe the Pickit 4 is not that crappy? But previous versions certainly were. I stil have an ICD 3.
I don't regret having switched to other vendors, with that and their software tools and compilers. Even if some of their products were good.

[JPortici]

Well maybe the Pickit 4 is not that crappy?

It's not. I've not touched the ICD3 since MPLABX 5.50
The only PITA is that we have to use the IPE instead of the standalone to program one offs, but that may change soon, since someone took the time to reverse engineer the protocol.
https://www.microchip.com/forums/m1221852.aspx
and now a certain someone has to find the motivation to learn python and rewrite the script into a nice Qt application

[Karel]

There's also the "Snap": https://www.microchip.com/en-us/development-tool/PG164100

But indeed, it's a pitty the ICD 4 is EOL. Fortunately for us,  we use STM32 for new projects.

[Zucca]

Are there any µC supported by ICD 4 but not by Pickit 4?

Yes we are losing  with the ICD 4 the advance triggering and the high current to target.... but I think we can all survive without those...

[Zucca]

we use STM32 for new projects.

and what debugger?

[Karel]

we use STM32 for new projects.

and what debugger?

For programming only we use ST-LINK/V2, for debugging we use a serial port and/or some gpio pins.

[JPortici]

Are there any µC supported by ICD 4 but not by Pickit 4?

Yes we are losing  with the ICD 4 the advance triggering and the high current to target.... but I think we can all survive without those...

I don't use ancient devices, nor devices that have just come out, but usually support for new devices is added at the same time in all fourth gen tools (and i see no reason why it shouldn't be this way)
curious: what do you get from the advance triggering that you can't do with the regular/data breakpoints?

[Zucca]

what do you get from the advance triggering that you can't do with the regular/data breakpoints?

Oh mamma! Believe me between me and you surely you are the expert here.
I was hoping you would have an answer to the very same above million dollar question.

I can only assume if your firmware is done in a clean way you should never need any esoteric obscure advanced triggering.

Do you believe MC will continue to add support for new devices in the ICD 4? I hope you are right! 

[JPortici]

what do you get from the advance triggering that you can't do with the regular/data breakpoints?

Oh mamma! Believe me between me and you surely you are the expert here.
I was hoping you would have an answer to the very same above million dollar question.

I can only assume if your firmware is done in a clean way you should never need any esoteric obscure advanced triggering.

Do you believe MC will continue to add support for new devices in the ICD 4? I hope you are right! 

I'm genuinely asking, as i've never had the pleasure to use the ICD4 way out of budget.
I skimmed again through the manual but i didn't see anything that indicated more complex debugging over the pickit.
Guy from microchip said they will continue adding support, the only thing we can do is believe them, or not. Maybe they are already redesigning using a new FPGA, who knows.
I honestly don't know what the FPGA does in the first place, probably hardware acceleration of the debug interface ? One of the things they claim is debug at full speed, but i don't have serious problems in debugging a dsPIC33C at full speed (100MIPS) with the pickit.
AFAIU the SNAP, PK4, PKOB4 and ICD4 all use the same firmware as a basis, as all use the ATSAM E51

[Zucca]

Well I don't know either... I never had a ICD 4 as well... but I was looking for a cheap one used since years...

[IDEngineer]

This massively sucks. I've avoided the whole ICD4 phase, sticking with the trustworthy ICD3 and even buying a backup unit just in case. Now it appears I'll be two full generations behind. Doubt there will be many updates in the future.

Every single board we have in production uses the Tag-Connect ultra small footprint connector and cable. I don't even know if they have a compatible cable for the $1800 unit.

I seriously hate being orphaned by companies. We buy 10K+ PIC's annually. Might be revisiting that choice as we update our boards.

[Karel]

The reason for me to buy the icd 3 was only because the pk2 is slow when programming pic32.
But the icd 3 & 4 are still slow compared to an st-link/v2 & stm32.
Microchip's gcc is also slower than arm's gcc compiler.
Microchip tools, despite their fancy looks, are becoming dinosaurs.
When I'm developing and debugging firmware, the speed of the tools matters a lot.

[IDEngineer]

My workflow must be weird. I hear people say that the compile speeds and download speeds are a huge factor, but honestly I don't experience that. From the time I click the "reflash" icon until I turn my chair 90 degrees and pick up a scope probe, the code is flashed and running.

What matters to ME is having a bunch of production designs whose debugging connectors aren't supported. Guess I'll have to look at the PICkit4... though I was always led to believe that the little PICkits were substandard compared to their ICD big brothers.

[Zucca]

I feel your pain IDEng...

If something goes wrong in the future you are probably responsible to deliver solutions, and the excuse of tools EOL of whatever is something that could not be accepted.
You designed it, you will fix it. Maybe it's a good situation to get the ICE4 approved by management.

I don't have my designs in production, but  in the current situation I am forced to buy a Pikit4 [PK4] and see it's a good boy or not for my stuff.... I will be surprised if it is not the case, the general feedback about the PK4 is quite good.

Sensible also the suggestion from Karel going STM32, but I recall it was heavily impacted by the "chipageddon" shortage shit show.

[JPortici]

I feel your pain IDEng...

If something goes wrong in the future you are probably responsible to deliver solutions, and the excuse of tools EOL of whatever is something that could not be accepted.
You designed it, you will fix it. Maybe it's a good situation to get the ICE4 approved by management.

I don't have my designs in production, but  in the current situation I am forced to buy a Pikit4 [PK4] and see it's a good boy or not for my stuff.... I will be surprised if it is not the case, the general feedback about the PK4 is quite good.

Sensible also the suggestion from Karel going STM32, but I recall it was heavily impacted by the "chipageddon" shortage shit show.

In case you need help with the PK4, and it involves PIC devices, feel free to PM me. (PIC only because i currently don't use ATSAM parts so i can't provide any insight)

Though usually the solution is to update things: Monday there was an update under the hood that blocked the 4th gen tools - don't get me started i am extremely pissed off that things happen and are updated without your control - but luckily the IDE gave an helpful message that hinted you had to update the tool packs and some device packs. And yet there are at least four threads on the microchip forum from users that willfully ignored the message because "i don't want to update what i don't need" except the IDE told you to do that and then you complain that things don't work anymore.

Are you in italy now? ISTR from your posts in the past that you lived/worked in munich?

[IDEngineer]

usually the solution is to update things: Monday there was an update under the hood that blocked the 4th gen tools - don't get me started i am extremely pissed off that things happen and are updated without your control... users that willfully ignored the message because "i don't want to update what i don't need"

Have to say, I'm sympathetic to those "don't update what I don't need" feelings. Generally I don't update what isn't broken for my needs. Yes, I know bug fixes are cumulative and all that. But I've been burned far too many times by following the lemmings over the cliff, and blindly updating just because an update was available, only to find that the update itself caused new problems. I didn't have problems before, but after the update I do. Talk about frustration!!!

Yes, we're heavily into PIC's especially the PIC18 family. If the ICD# is unavailable, we must have something that has an available TAG-Connect cable. Sounds like that may force us back down into the PICkits. I'm not opposed to the PICkits, but as I said I was given the impression they are a step backwards from the ICD's. Just seems odd to be moving backward.

[Zucca]

Thanks Portici,
I will PM you in case I stumble in unsolvable PIC problems.

No I wish to be in Italy all the time, right now I am in USA, SC trying to become rich so I can then spend all my money in Italy where I will be retiring in 30 years.
I was in Munich 15 years, but they offered me a job in USA I could not refuse....

[SiliconWizard]

This massively sucks. I've avoided the whole ICD4 phase, sticking with the trustworthy ICD3 and even buying a backup unit just in case.

Same here, good thing I'm not designing anything new with Microchip MCUs, and the ICD3 is fine for the occasional maintenance of older projects.

[JPortici]

Thanks Portici,
I will PM you in case I stumble in unsolvable PIC problems.

No I wish to be in Italy all the time, right now I am in USA, SC trying to become rich so I can then spend all my money in Italy where I will be retiring in 30 years.
I was in Munich 15 years, but they offered me a job in USA I could not refuse....

you wouldn't need to do that if you didn't live in the most expensive city of continental europe and one of the most expensive in the US 
ah, it was just so i could send you a contact for a local distributor that does miracles, local area only i'm afraid

[IDEngineer]

I've just remembered that Microchip historically recommends AGAINST using PICkits for production programming. If ICD's aren't available, that pushes us into RealICE's... except I don't see a TAG-Connect cable for those.

I've reached out to TAG-Connect to ask their advice. But I cannot believe Microchip would orphan people like this.

[tumbleweed]

You should be able to use an AC164110 RJ-11 to ICSP Adapter to connect a Pickit4 to a TagConnect cable.

I think the recommendation for not using the pickits as production programmers was simply because they don't verify at high/low VDD voltages.
Other than that there's not really much difference.

RealICE's are EOL too, so currently it's ICE4 or pickit4.

[JPortici]

I've just remembered that Microchip historically recommends AGAINST using PICkits for production programming. If ICD's aren't available, that pushes us into RealICE's... except I don't see a TAG-Connect cable for those.

I've reached out to TAG-Connect to ask their advice. But I cannot believe Microchip would orphan people like this.

I know, though we used scores of Pickit 3 in the past for production. Back then we would get 8-10 pickits for one ICD3. Even if one broke..
But still, using pickit/icd for production is not what i would recommend doing if you're programming more than say 20 per production lot. One month ago we finally invested in the ICP2-COMBO production programmer from softlog, it will have repaid itself by the end of the year

[IDEngineer]

What are its to-target connectors? Remember, our PCB's have TAG-Connect footprints... it would need to mimic the RJ-11 output connector of an ICD (or theoretically the 6-pin inline connector of a PICkit).

Then there's the question of cable lengths. How long can its target cables be? That will control how many of our devices could be programmed at once.

Finally, to minimize PCB space (a lot of our boards are standardized at 2x2 inches) we use the TAG-Connect footprint that doesn't have mechanical locking, which means the user must physically hold the connector against the spring pressure during programming. There are locks that go on the back of the board, but they're meant for R&D. If you spend the time to set up a "bulk flashing" by individually holding each cable while securing the lock on the back, flash them, then go back and individually remove each cable lock, I doubt there's any time savings on a per-unit basis.

Another option is bulk programming by Microchip, but sometimes our customers request one-off modifications to the firmware so having a bunch of preprogrammed parts doesn't really buy us anything.

I appreciate the suggestion, but we've looked at most techniques and at the end of the day, we just need to be able to flash them at the board level using the connection style that Microchip has supported for what, 10+ years?

[JPortici]

What are its to-target connectors? Remember, our PCB's have TAG-Connect footprints... it would need to mimic the RJ-11 output connector of an ICD (or theoretically the 6-pin inline connector of a PICkit).

you make your own, you interface to the programmer using din41612 connectors. we made a simple PCB that has the connector, then a bunch of wires starts with our own connector/pinout on the other side. or you can wire wrap on the connector (we really looked into trying tag connect, nice idea but it's not for us, we usually need another connector anyway for final programming, device monitoring when installed etc, boards are dense and the full footprint with locking takes up as much space as a 2x5 2.54mm header, which is what we keep using)

Then there's the question of cable lengths. How long can its target cables be? That will control how many of our devices could be programmed at once.

that's in the manual, i don't remember. But we use 50cm unshielded cables, and are already in the thousands of boards programmed with no issue

Finally, to minimize PCB space (a lot of our boards are standardized at 2x2 inches) we use the TAG-Connect footprint that doesn't have mechanical locking, which means the user must physically hold the connector against the spring pressure during programming. There are locks that go on the back of the board, but they're meant for R&D. If you spend the time to set up a "bulk flashing" by individually holding each cable while securing the lock on the back, flash them, then go back and individually remove each cable lock, I doubt there's any time savings on a per-unit basis.

and that's why we don't use tag connect (besides the cost of the cable, but it's understandable as it's their only revenue)
we have grown from programming handful of boards every few days to at least 500 per week (and even before every few months we would have to program 3-500 lots, all one at a time with a pickit and the IPE. One wonders how we could make it before without going crazy) programming one at a time is just time wasted. And more time is wasted every time by inserting and removing the connector so we are trying to move to a programming/test fixture with pogo pins (which are really cheap to make these days, thanks to 3d printing), insert the panel, a couple of clicks, done.

Another option is bulk programming by Microchip, but sometimes our customers request one-off modifications to the firmware so having a bunch of preprogrammed parts doesn't really buy us anything.

I appreciate the suggestion, but we've looked at most techniques and at the end of the day, we just need to be able to flash them at the board level using the connection style that Microchip has supported for what, 10+ years?

We have the same problem, we solved it for 99% of the cases by using the same firmware, different configuration. But i know it's not always possible. Another option (but i'm sure you considered it) is a single bootloader + the standard image, you progam that in bulk, you reprogram only those that you need to reprogram

[thm_w]

Who would care what Microchip says to use their programmer for, lol.

They had a built in "program" button on the Pickit3, if thats not for production, what would it be for.

[IDEngineer]

We always used that for in-place R&D reflashing. Never for production, per their warning.

[SiliconWizard]

We always used that for in-place R&D reflashing. Never for production, per their warning.

Same here. The reality behind it is that with high-voltage programming, the low-cost/hobbyist programmers were usually not using the most robust programming algorithm to ensure long-term retention, and simplified algorithms were usually used in the low-cost programming tools. I think the more expensive programmers were also using various voltage levels, which cheaper ones weren't. MIcrochip's ICSP algorithms were actually convoluted enough that they went as far as programming a new firmware for each different device family (and sometimes for devices of the same family!), and requiring a relatively beefy FPGA (for the task at hand at least) in their more expensive ICDx. Crazy.

Now with low-voltage programming, it has an extremely low probability of making any difference whatsoever.