I have a PICKit 3, but I understand these aren't for production.
What does a production workflow look like? PC -> Programmer -> Chip.
Do people usually verify that the chip copied properly, or is that not necessary (fail rate?)
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.Sign up to join this community
Microchip's "production programmer" distinction is largely only meaningful for old chips. The old flash parts, like the 16F877 for example, had to be checked at both Vdd limits after programming. Microchip defined such programmers as "production". Note that this required the programmer to have variable Vdd.
Microchip dropped the double verify requirement in newer chips a long time ago, and there is no mention of a "production" programming algorithm versus "development" in any of these newer programming specs.
Today I am not aware of any official requirement for a "production" versus "development" programmer. As far as I can tell, this is purely a marketing distinction for newer parts. They don't want people buying a bunch of PicKit2 for programming in production when their other programmers are more robust (less technical support required) and have a higher profit margin.
To be fair, it really isn't a good idea to use a PicKit2 in production where you need to rely on it. It has lower drive levels and the design was optimized for low cost at the expense of robustness and accuracy. However, the "production" distinction is rather hollow without a clear spec of what it takes to be a production programmer.
My USBProg2 programmer was specifically designed to the production spec for those PIC where there was such a thing. It has full variable Vdd and Vpp, and verifies at the Vdd limits anyway, even for those parts where Microchip no longer says you need to. Other than a little extra time, I don't see a drawback. You can turn off this feature with a command line option if you want to.
Some of the newer 3.3 V parts, like all the 16F1xxx but also some PIC24, dsPIC33, and 18F support a new programming algorithm that no longer requires high voltage on MCLR (Vpp) to enter programming mode. Instead, you clock in a special 32 bit signature with MCLR held low. All interactions during programming can be done with signals at Vss or Vdd. This opens the possibility of a much simplified programmer. My LProg is such a programmer. At only $20 or so each, its the cheapest way to set up a bank of programmers for production while maintaining robust operation, if your PIC type supports the low voltage key-entry method.
The program writing is always verified. In addition, production programmers verify the program at Vdd extremes to make sure it 'took' well, in accordance with the programming recommendations for the individual chips. So the chip, when being programmed, must be supplied by a programmable supply with a prescribed resolution etc.
Of course you're free to ignore that requirement and hope that you never get a marginal chip, but if you do, you can't really go complaining to Microchip.
This means that ICSP in-field (re) programming also needs to be done with a production programmer. If you're making a lot of something, you can buy the chips pre-programmed with your code, and shipped directly to your contract assembler.
While for development one usually only cares that the programmer works and allows you access to program and debug the chip there are some additional requirements in production: performance (for lowest possible programming times, time = money), reliability (programming works correctly every time, re-runs cost time = money), robustness (production environment is usually a bit more noisy so you need something that does not fall over if that big machine next to it just switches on).
And yes - you would normally verify after programming. Unless the chip implements some sort of check-sum in which case you might use that if programming time is critical.
PS: That does not mean a production programmer has to be something completely different. It may just be a better, more robust solution compared to the cheap programming cable one would use on the bench during development...
There is a nice comparison between the PICkit 3, ICD 3, and REAL ICE here:
As you can se, the PICKit3 is not recommended for production, while the ICD 3 and REAL ICE are.
The big difference is the PICkit 3 only supports USB 1.1 Full Speed (12 Mb/s), which the LCD 3 and REAL ICE support USB 2.0 High Speed (480 Mb/s), 40 times faster. This makes a noticeable difference for any but the most trivial of programs.
According to tag-connect.com:" The ICSP signals supplied by PICkit 3 do not have the same drive strength as Microchip's ICD 3 and REAL ICE debuggers .... We recommend choosing the ICD 3 or similar over PICkit 3 in order to avoid noise related connection problems."
Production programming, implies a more robust algorithm. That implies the ability to program a large quantity of boards without the risk of errors or subsequent failures due to "weak bits" in the programmed image.
The interface for the Real ICE is on its own little daughterboard, so if you blow the output circuitry, you only have to replace that piece.