Crazy idea, multiplexing a pickit 3 programming lines to program more mcus?

[JPortici]

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 panel


e.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 housing


a 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 / veryfing


Is this something that could work?

what about VPP? should it be multiplexed too?

[Ian.M]

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.

[JPortici]

Thanks ian, i was hoping to hear some insight from you i 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. 

[alm]

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?

[mikeselectricstuff]

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?

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

[Ian.M]

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.

[mikeselectricstuff]

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.

But doing them a whole panel at a time would be a lot quicker.

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.

That'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.

[JPortici]

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 pics
basically 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

[Ian.M]

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.

[mikeselectricstuff]

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 pics
basically 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)

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

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.

So have them auto-pair and send the info to a label printer

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

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

[mikeselectricstuff]

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.

You 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

[JPortici]

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

[KL27x]

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.

[forrestc]

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.

I'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[0xe234]=0x12 ), then another to write the hex file out.

[JPortici]

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

[forrestc]

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.

Thought #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.

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 panel
e.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 housing

I 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'.

[mikeselectricstuff]

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

Take a look at the ASIX programmer http://www.asix.net/prg_presto.htm

This has extensive options for serialisation, You can run their SW in demo mode without the hardware

[JPortici]

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 time

i 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

[free_electron]

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

[mikeselectricstuff]

BTW there are some PICs that come with a unique ID (They call it MUI - Microchip Unique Identifier) already programmed, e.g. PIC16F15325

[Ian.M]

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. 

[mikeselectricstuff]

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.

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

[NorthGuy]

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.

[mikeselectricstuff]

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.

That'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.

[KL27x]

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,

So.... 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?