0
\$\begingroup\$

I'd like to put several PCBs in a panel with only one ISP connector routed to each MCU in parallel.

I hope that it will be no problem that many MCU's outputs will be connected together as it is intended that the output data will be always the same.

However I can not be sure that the programming device (STK500 in my case) will be electrically able to handle many devices (and how many in this case?) I think it is hopeless to try to find any specification as the programmers intended to be connected only to one MCU in a single time.

I did find a similar topic here, but Brian asked about parallel programming but I need to do it serially. And the question was related to relatively small amount of MCUs (3 in the picture) when I'd like to do this trick with a 20 or 30 devices!

So is there anything slept out of my sight? I could make an experiment with 2 or maybe 3 devices but I don't have enough boards to provide a full scale test, so probably someone did this? I'd like to have more PoVs before I will place a panel in the production.

Any thoughts?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Consider not only the logical and fan-out issues, but that one bad board in the panel would take the whole thing down and it may be costly of skilled technician time to identify the culprit. The usual approach is a footprint for a spring pin fixture on each board, or even programming the ICs before assembly. \$\endgroup\$ Commented Dec 1, 2016 at 16:19
  • \$\begingroup\$ @ChrisStratton actually I made hundreds of devices programmed and the bugs like the device can not be programmed was so rare (if any). So my estimation is that the bad part probability is so low that even multiplied by 20 or 30 it will be still very attractive from the productivity point of view... \$\endgroup\$ Commented Dec 1, 2016 at 16:23

2 Answers 2

Reset to default
1
\$\begingroup\$

The AVR ISP programing protocol both writes to and reads from the device being programmed during programming. For this reason you will not be able to do this (program multiple devices simultaneously) unless you write your own software to do writes only (and take the significant risk that you miss a dead device on your panel). http://www.atmel.com/webdoc/protocoldocs/protocoldocs.avrispprotocol.html

There are many commercial gang programmers on the market (though you'd expect $2-3k pricing), but given the ridiculously low cost of an AVR ISP MKII programmers on Ebay, you could hook up multiple USB programmers and cycle through the various ports. Not exactly gang programming, but certainly could be faster than a manual single device process. If you are really keen to save time, then you could roll your own software to gang program multiple AVR ISP programmers, it would not be difficult.

\$\endgroup\$
2
  • \$\begingroup\$ I actually didn't get your idea, why write and read will make multiple programming impossible. As I mentioned in the question I'm aware that the connection between multiple outputs is a bad practice in general. But I assume that the read data will be always the same (if the devices are OK). So connection between outputs in the same state is OK. Even if something is wrong I assume that differently stated outputs connected together will not do any harm as the pin can drive just about 40 mA of current which will not damage anything. Do you think that any of my assumptions are wrong? \$\endgroup\$ Commented Dec 1, 2016 at 21:25
  • 1
    \$\begingroup\$ If you connect all the required programing pins together on all the devices and they are all using their internal clocks for data, you will get potentially confused outputs. Yes, you are right if they all responded identically things might work out, but if any fails then you can't tell which one on the panel is failed. \$\endgroup\$ Commented Dec 1, 2016 at 22:30
0
\$\begingroup\$

I'd do the programming during the flying probe testing, which you have to do for each unit in the panel separately anyway.

  1. Upload a test program
  2. Test that all connections are soldered
  3. Test that no solder bridges exist
  4. Upload final program

With JTAG compliant devices, you'd use Boundary Scan for the connectivity and isolation testing, but for the AVR, you need a separate program that implements a response protocol that allows you to test connections easily, like

  1. pull A0 low, switch A1 to input with pull-up, all other ports high
  2. flying probe tests that things connected to A0 are low
  3. flying probe tests that things not connected to A0 (but other ports) are high
  4. give low pulse to A1 to advance program
  5. pull A1 low, switch A2 to input with pull-up, all other ports high

etc.

You need to adjust that program for your board so you don't break any peripherals connected, and optimize so you don't test impossible solder bridges (A0 to A2).

\$\endgroup\$
2
  • \$\begingroup\$ Simon, I actually don't think that a flying probes test is something vital. I will make a full functional test of each device (right in the panel) so if there are any shorts of breaks it will affect on the device functionality. Moreover I always thought that flying probes programming is a kind of a rocket since. Is it that simple? \$\endgroup\$ Commented Dec 1, 2016 at 21:31
  • \$\begingroup\$ My point is that testing and programming usually go together, because you need to be able to connect to individual test points for both. Flying probes testing requires you to turn your test plan into a program for the machine, which can be tedious work if you have a weird programming setup, but I believe there are readymade functions for AVR programming. \$\endgroup\$ Commented Dec 2, 2016 at 7:17

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.