MPLAB ICD 4 is EOL!

[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.