Crazy idea, multiplexing a pickit 3 programming lines to program more mcus? - Page 1
Forum section: electronics / projects

author: JPortici
author_rank: Super Contributor
timestamp: July 12, 2017, 08:13:16 am
content: Hi,we have product which is a small remote controlled and a receiver both controlled by a pic. given the geometry of the board only a small surface pad header is possible, so we can't use our production programmers.having to program each remote with different codes and other stuff is a nightmware that wastes everybody's time.I don't know what's the standard procedure in these cases but i was thinking to put an extended programmer header directly on the panele.g.: assume there are 18 boards in a panel, the programming connector is 36 PGC/PGD pairs, VDD,VSS,VSS,VPP to connect with a 40 pin cable to a multiplexer board that routes the pair from the programmer to the selected mcu. The programming connector will be on the panel's border, with the signals going through the mouse bites. after programming and testign the parts are snapped off and put in their housinga SBC will run a script that takes the original hex file, edits the parts that need to be edited, change its gpios to route the signal and start the programming / veryfingIs this something that could work?what about VPP? should it be multiplexed too?

author: Ian.M
author_rank: Super Contributor
timestamp: July 12, 2017, 08:46:02 am
content: You can multiplex PICs for ICSP simply by switching Vpp/MCLR to the desired PIC with /MCLR on all unselected PICs pulled low (simple 10K pulldown is adequate). Provided none of the PICs have their CONFIG set to disable /MCLR, that forces their PGC and PGD lines tri-state (together with all other I/O) leaving only the selected PIC actively connected to the programmer. Microchip use this method on some of their own demo boards to allow the on-board SMD PIC to be overridden by one on a plug in PIM and for the same programming connections to be used for both.However with 18 on the panel, I would be a little concerned about the fanout of the PICkit 3 ICSP I/Os and the PGD line from the selected PIC to the programmer, so I would suggest grouping the PICs in threes and multiplexing those lines as well, giving you 18 Vpp lines, and 6 pairs of PGC and PGD lines. With a ground between each PGD/PGC pair (to reduce crosstalk) that would fit comfortably on a 40 pin connector with enough pins spare for Vdd and a polarising pin.

author: JPortici
author_rank: Super Contributor
timestamp: July 12, 2017, 08:53:59 am
content: Thanks ian, i was hoping to hear some insight from youi am also concerned about the fan-out and what the actual implementation will be.. but at this point i just want to know if it's feasible, i'll start thinking about it seriously AFTER i finish to program this batch.

author: alm
author_rank: Super Contributor
timestamp: July 12, 2017, 08:55:33 am
content: You could probably get it to work (although you may need some bus drivers to get the necessary fan-out), but would it not be easier to have the PICs programmed with a bootloader from the factory (this can be quite cheap), and use the boot loader to load the actual firmware? This way you are much more flexible and can use something that is easier to multiplex (like UART) and can easily be built in a custom rig?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 09:05:48 am
content: Quote from: alm on July 12, 2017, 08:55:33 amDefinitely - MicrochipDirect will preprogram parts very cheap. You just include some code for ID assignment.If you have enough pins available, you could encode the board's position in the panel by tying pins per-board, then you could just have a single common serial bus across the panel to do the programming.Or have the boards connected in a chain, passing serial data from one device to the next, so you can address individual devices by their position down the chain.

author: Ian.M
author_rank: Super Contributor
timestamp: July 12, 2017, 09:12:54 am
content: Maybe an effective programming jig would be a better solution? Ideally it should be a one-stop station where the pair of RX and TX boards are programmed and serial number labels (with extra options indicated) attached before they leave the programming station. It should be as simple as clicking the boards into the jig and hitting a 'Go' button then waiting for a green light (or a flashing red one for rejects) Either print the labels on the fly, or have a bar code reader at the programming station if the labels need to be attached earlier.It may still be worth looking at ordering the PICs preprogrammed. You can also get them serialised. Pairing transmitters and receivers could be as simple as grounding a pin to enter pairing mode then the receiver would pair with the next transmitter it 'sees' that's itself in pairing mode. That would also permit easy re-pairing in the field.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 09:24:00 am
content: Quote from: Ian.M on July 12, 2017, 09:12:54 amBut doing them a whole panel at a time would be a lot quicker.QuoteThat's a good point - why are you actually assigning IDs in the first place can you reduce this just to a unique ID? If all you need is a unique ID then I think Microchip offer this.

author: JPortici
author_rank: Super Contributor
timestamp: July 12, 2017, 09:24:38 am
content: I never used microchip direct programming service, because i never really had an idea of the costs involved. plus last i checked it seems it wasn't available for all picsbasically i get the tube / reel of pre-programmed parts and i ship them to my assembly house? (or have it shipped there directly of course)to give more hindsight, this is a product we make for a single customer and he wants the parts already paired together, so we have a list of IDs and other data we have to write on each device.tis because per request the only way to pair a new remote with a transmitter is with a specialized tool so it's either manually, or during programming.I am making a new hardware version in these days and i already put a mcu with more pins/memory but i'm not sure i'll have the space for a bootloader, i'll know after i finish the code

author: Ian.M
author_rank: Super Contributor
timestamp: July 12, 2017, 09:35:27 am
content: Yes. that's the basics. IIRC its something like $30 to set up a firmware image project (and specs for serialisation), then depending on the device (and thus how long it takes to load into a programming jig and actually program it), and what marking options you choose, it can be as cheap as a few cents per device to actually program them. You cant edit an existing firmware image - just pay the $30 fee and upload a new one.Its difficult to compete with MicrochipDirect's programming service in-house unless you are doing SERIOUS volume.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 09:37:16 am
content: Quote from: JPortici on July 12, 2017, 09:24:38 amIt only tends to be very new parts that take a while to be added to the service. Yes they will ship direct to an assembly house.QuoteSo have them auto-pair and send the info to a label printerQuoteThe code to accept & program data fro man external source wouldn't take much space, and even if you had to go to a bigger part, you could probably more than offset the cost in reduced production time.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 09:40:48 am
content: Quote from: Ian.M on July 12, 2017, 09:35:27 amYou can waive the verification step if you're feeling lucky - I don't recall if this also waives the setup charge, as the latter is mostly for the verification samples.Probably not a good idea if you're getting into serialisation though

author: JPortici
author_rank: Super Contributor
timestamp: July 12, 2017, 10:08:50 am
content: I looked up costs... huh. for what i'm going to use making an hundred programmed parts would cost (per mcu) about the same as a single mcu, then at 1000 you really start seeing the costs dropping, plus the hours saved by automating the final programming here

author: KL27x
author_rank: Super Contributor
timestamp: July 12, 2017, 10:33:15 am
content: Has anyone gotten the PK3 to write serial numbers in EEPROM and/or program memory? It appears that the IPE software has options to do this, but whenever I fooled around with it, nothing happened.

author: forrestc
author_rank: Unknown
timestamp: July 12, 2017, 11:17:28 am
content: Quote from: KL27x on July 12, 2017, 10:33:15 amI've had good luck with a script (perl originally, python more recently) to just modify the hex file and call the command line programmer tool. Not so much with using the builtin serialization tools in pretty much any device programmer I've ever dealt with.The python "IntelHex" library makes it really easy - one function to load the hex file, then you just use a few array like assignments to modify the values in memory (i.e. mem=0x12 ), then another to write the hex file out.

author: JPortici
author_rank: Super Contributor
timestamp: July 12, 2017, 11:26:45 am
content: the serialization tool in the PK3 is easy to use, but rather limited. it lets you put serialized data on either flash or eeprom or device information area, not a mix of the three. in the end you have to resort to a script or a piece of software to edit your blank hex file

author: forrestc
author_rank: Unknown
timestamp: July 12, 2017, 11:29:08 am
content: Quote from: JPortici on July 12, 2017, 08:13:16 amThought #1 : have you considered tag-connect cables? They have both a snap in version of the connector, and also a friction fit option (retention clip on the bottom). Just a thought for you... but probably won't work in your application.Quote from: JPortici on July 12, 2017, 08:13:16 amI use a arduino mega in combination with a sainsmart relay board to dynamically connect/disconnect an ICD3 in the automatic test gear.... no problem so far.I like Ian.M's solution (and suspect it will work just fine - I sure don't see any reason why it wouldn't work, and it's nice and elegant), but if that doesn't work for you for some reason, the way I would have approached this would be to tie vdd and vss together, and mux PGC/PGD and MCLR through a relay 'binary tree'.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 12:49:44 pm
content: Quote from: JPortici on July 12, 2017, 11:26:45 amTake a look at the ASIX programmerhttp://www.asix.net/prg_presto.htmThis has extensive options for serialisation, You can run their SW in demo mode without the hardware

author: JPortici
author_rank: Super Contributor
timestamp: July 12, 2017, 02:40:00 pm
content: I gave it a bit of more thought and the more i thought the more i liked to have the MCUs pre-programmed with a UART bootloader then upload the actual firmware when we need to program and test, some hundreds of boards at a timei drew a test panel (manually, diptrace only has a basic panelizing tool), factory that handles production for these boards says it shouldn't be a problem

author: free_electron
author_rank: Super Contributor
timestamp: July 12, 2017, 02:43:33 pm
content: simply use an analog multiplexer and switch to your heart's content.you can run programming traces on internal layers, through mousebites. when you crack the boards out, the traces will snap clean off.74HC4067 is your friend ...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 03:58:02 pm
content: BTW there are some PICs that come with a unique ID (They call it MUI - Microchip Unique Identifier) already programmed, e.g. PIC16F15325

author: Ian.M
author_rank: Super Contributor
timestamp: July 12, 2017, 04:03:03 pm
content: Unless the PICs you are using are strictly LVP only (Vpp=Vdd), you'll need to use something like a CD4067 running from 15V to handle the Vpp signal.Also you'll either need to parallel multiple 4067s to get low enough ON resistance, or follow it by an OPAMP unity gain buffer for each Vpp output.If its a LVP only PIC its a lot easier, Vpp/MCLR is then just a logic signal, but put a strong clamping circuit on it at the PICkit 3 connector just in case a confused PICkit 3 ever attempts to take it above Vdd.You may wish to consider using a DIY or hacked PICkit 3 so you can access the DIR signals controlling the 74LVC1T45 level translating buffers on PGC, PGD and PGM as that makes it possible to buffer the ICSP signals after the switching circuit. The critical one is PGD as that's the only bidirectional one for PIC programming. As PGC is always an output for PIC programming you only really need to tap that one.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 04:41:42 pm
content: Quote from: Ian.M on July 12, 2017, 04:03:03 pmOr you could just feed VPP to all PICs in parallel and only mux the other lines. You might even get away with feeding PGC to all PICs as well - not sufficiently familiar with the protocol to know if it will just sit passively if it sees nothing on PGD.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 12, 2017, 05:08:55 pm
content: On many PICs, you don't need any feedback to program. So, you can simply connect all the PGC, PGD and MCLR lines in parallel, and, given enough drive strength you can program as many as you wish. However, this won't give you any feedback, so you won't know if it programmed Ok. Of course, you will need your own software because most stock programmers will want to receive the chip id before programming.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 05:13:57 pm
content: Quote from: NorthGuy on July 12, 2017, 05:08:55 pmThat's another advantage of using your own bootloader - you can arrange the protocol such that the programming time is guaranteed by enough dummy bytes in the serial stream, so you don't need any feedback from the device.e.g. let's say your programming commands all start with 0xc5, and any other byte is ignored til it sees 0xc5, you send<0xc5> <stuff to program one page> <enough 0xff bytes to exceed the maximum row program time at your baudrate>Use 0xff as filler as it's the easiest value for the UART to re-sync to - during programming, the UART will be being ignored so will overrun, and needs reliably re-syncing.

author: KL27x
author_rank: Super Contributor
timestamp: July 12, 2017, 05:54:58 pm
content: QuoteSo.... question.Say, theoretically, that someone has over the past 6 years invented and refined a machine for flashing of chips, serially, with full verification. That it works on many common SMD packages. And that aside from the initial setup for a given footprint and pinout, and the time to swap tubes of IC's, it takes only the actual flash time plus a fraction of a second per chip. And the flashed chips are tubed when done.Say, theoretically, a very compact and inexpensive version of this machine can be operated, manually. Sitting or lying down... or even walking around (if you have a portable programmer, such as PK2/3, PM3... or I suppose a portable computer). And can be done with your eyes closed. And that a fully motorized version would be also be available, which will wait for verification signal before proceeding to next chip. And it would be of reasonable cost.Say, theoretically, if this machine were available, and if it worked as advertised... would there be any market for this? There are so many other ways to go about it, which have been discussed in this thread. Would anyone be interested in having their own chip flashing factory? Why wouldn't they, right?

author: free_electron
author_rank: Super Contributor
timestamp: July 12, 2017, 06:57:36 pm
content: those are called gang programmers.been around for ages. Data-i/o and the likes ...

author: NorthGuy
author_rank: Super Contributor
timestamp: July 12, 2017, 07:16:47 pm
content: Quote from: mikeselectricstuff on July 12, 2017, 05:13:57 pmStill, you will need a way to find out if everything programmed Ok. I don't think the current ICSP protocols are flawed and need replacing. The problem is that once in a while you do come across a PIC which just doesn't want to be programmed no matter what.

author: Ian.M
author_rank: Super Contributor
timestamp: July 12, 2017, 07:20:56 pm
content: Since the O.P. needs the PICs individually serialised, a simple (dumb) gang programmer is not useful. However, if the objective is to reduce programming time without ordering preprogrammed chips and the PICs have a lot of FLASH, programming serialised bootloaders by ICSP, then using the bootloader to gang-load the rest of the firmware to all the PICs simultaneously, using the same PIC pins, but switching them to a USB <=> logic level serial module might be worth considering.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 07:22:53 pm
content: Quote from: NorthGuy on July 12, 2017, 07:16:47 pmNot flawed, but far from optimal in some casesQuoteAfter programming you'll be testing the product anyway, so any failures will become apparent then.If you have an onboard LED, you could also use this to indicate successful programming.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 12, 2017, 07:25:34 pm
content: Quote from: KL27x on July 12, 2017, 05:54:58 pmI've seen such machines advertised for around $5K. Don't seem to find them now.At any rate, you would probably want to do some sort of QA on your final board. If you do programming and QA together, the programming may be of less overhead than when you pre-program before assembly.

author: KL27x
author_rank: Super Contributor
timestamp: July 12, 2017, 07:34:41 pm
content: QuoteYou'll be testing it for a variety of faults. If you could exclude corrupted firmware and just focus on hardware faults, it may simplify the testing procedure. A failed flash could be just a single corrupted byte. And who knows under what conditions that would be elicited? Maybe your customer will be the one to find it. I suppose if you have done it enough times with similar device and firmwares without any problem, you will be confident. For the first time, I don't know how I would sleep at night.QuoteDo you suppose it's because no one has a legitimate use for a machine like this? (Cuz of JTAG and programming services?) Or because it is too complicated and expensive? I still believe there is some potential benefit for this approach. If the cost were 1/10th or 1/20th, something one could afford for even personal use?

author: alm
author_rank: Super Contributor
timestamp: July 12, 2017, 08:12:58 pm
content: If the parts have a decent JTAG programming implementation (seem to recall JTAG on the 16-bit PICs was only partly functional), then putting all devices on a panel in a JTAG chain could be an easy way to do this. Not sure what the instruction register width on PIC parts would be, probably zero on 16-bit PICs.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 12, 2017, 08:34:20 pm
content: Quote from: KL27x on July 12, 2017, 07:34:41 pmI'm sure they are still alive. For example:http://www.dataio.com/Solutions/PSV3000This one is probably too expensive. I've seen better priced models.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 09:33:11 pm
content: Quote from: KL27x on July 12, 2017, 07:34:41 pmThat's what Checksums/CRCs are for.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 12, 2017, 09:34:40 pm
content: Quote from: NorthGuy on July 12, 2017, 08:34:20 pmBP Microsystems are the other big players in auto production programminghttp://www.bpmmicro.com/programmers/

author: KL27x
author_rank: Super Contributor
timestamp: July 12, 2017, 11:14:26 pm
content: QuoteAFAIK, a bad checksum means for sure there was a transmission error. But a matching checksum cannot rule out error.But besides this point, how do you do checksum in gang programming setup? If you are going to individually connect each board to a programmer at some point, why not flash it, then? With full verification? And why not put the bootloader on there at this point, too, yourself?Is this strategy solely for saving the time of flashing, in itself? For chips which will take on order of minute rather than seconds? This seems to be the case for these expensive chip flashing machines, too... Spend as much time loading the machine as doing the flashing. I am wondering about saving time of making connection to each invidual board by flashing the chips (easier) before they get on the board. The way Microchip factory does it, essentially. But on a smaller scale. Like as in you stick a tube of chips in a machine, press a button, and when you come back, they are all flashed with full verification. And back in factory packaging. Never touched by human hands. (I promise Microchip won't charge pennies per to flash a stack of your boards. The chips are standard size and shape and are handled by machine.)If someone can make this machine affordable and make it available to purchase, would anyone be interested?*edit, sorry. Looked closer at those links. And yeah, they handle the chips via CNC. I'm wondering if someone could sell a machine for smaller volumes which sat on your bench, not in the third factory. And which was hundreds rather than thousands?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 13, 2017, 12:00:14 am
content: Quote from: KL27x on July 12, 2017, 11:14:26 pmI think you misunderstand. This was in answer to how you can be sure, at testing time, that the code was programmed correctly, particularly in a 1-way programming situation.Either the bootloader, or the code itself, checks that the code image satisfies some checksum or CRC criterion that guarantees the image is valid, and either doesn't start or gives an error indication, which means it fails test.e.g. it is common for a bootloader to do a check on the program code before jumping into it, to prevent erroneous code being run, and ensure that it can be reprogrammed.

author: KL27x
author_rank: Super Contributor
timestamp: July 13, 2017, 02:08:48 am
content: You are right, I didn't get it. Lightbulb finally turned on. Bootloader, checksum, LED signal. Thanks for explaining it.