Programming devices at In-Circuit Test?

I read a very interesting article recently making the case for programming PLDs and Flash Memory at In-Circuit Test (ICT). What do you think?

EETimes published a well-written article (http://www.eetimes.com/electronics-products/test-measurement/4229012/JTAG-solution-for-Teradyne-ICTs) that made the case for re-considering where in the production cycle to program devices. Nowadays, roughly 50% of devices are programmed pre-reflow. But over the next few years, more devices will use new phase-change memory (PCM) for non-volatile storage; and as it turns out, this technology is quite sensitive to temperature – at 225⁰C all data will be erased for exposures greater than 10µs. Since reflow temperatures are around 210C to 235C, this implies that PCM devices will need to be programmed at purpose-built programmers, ICT, or functional or system test.

The article does point out some of the advantages of programming at ICT. There are no Design for Test (DFT) concerns – it doesn’t matter if the board has been designed for In-System Programming (ISP) or not. And the bed-of-nails provides direct access as well as constraints for any interconnected parts.

There are some concerns of course, the chief among them being the capabilities of the particular ICT system, and beat rate and cost. Not all ICT systems are created equal – many simply cannot program the parts fast enough, can’t source and measure the needed logic values, or may backdrive overvoltage or overcurrent conditions, damaging parts. And of course, device programming is a time-intensive way to use a very expensive piece of equipment.

A good alternative is to do programming at board functional test, prior to the board operating system being loaded. Processor-Controlled Test, for example, supports a function called (appropriately enough) Fast Flash Programming, whereby a design’s processor debug port is used to load a given device’s programming algorithm and data into system RAM in blocks rather than bytes. Then, the algorithm runs independently, at full CPU speed. Programming times of less than 10 seconds per megabyte can be achieved using this method. It doesn’t get much better than that! And it’s a very inexpensive way to do device programming, eliminating the need for dedicated programmers or optional HW/SW on the ICT. To learn more, go here:
http://www.asset-intertech.com/download/app9_fast_flash_programming.pdf.

Alan Sguigna

2 Responses

  1. I am the owner of a tiny sole proprietorship that specializes in flash programming models for ICT GR228X and Teradyne Test Station. I program everything from NAND Flash to most Microcontrollers. My business mission is to eliminate dedicated flash stations and evict the dedicated programmer PODs from all the ICT fixtures in the world.
    One would think that my biggest challenge was writing the drivers and the models and putting these algorithms together. No…
    The biggest challenge is getting the industry to take you seriously and motivating the end user to plug your solution in, turn it on and press the go button.

  2. Thanks for the observation, Dudey. Yes, I agree, there can sometimes be a lot of inertia within the test engineering community, against adopting new technologies and trying out different approaches.