Scanning the scanners
The IEEE 1149.1 Test Access Port provides a window into the ever-shrinking circuitry that engineers at PSC design into their data-capture equipment.
Rick Nelson, Chief Editor -- Test & Measurement World, 11/1/2006 2:00:00 AM
|
|
READ OTHER NOVEMBER ARTICLES: Contents, November 2006 |
Eugene, OR—
Data-capture equipment has evolved significantly since PSC first deployed a laser scanner in 1974 at a Marsh Supermarket in Troy, OH, where the pioneering system read a bar code printed on a “10 Pak” of Wrigley's chewing gum.
Since that debut, PSC has improved the speed and accuracy of its equipment, added weighing capabilities, introduced handheld scanners, and implemented RFID, Bluetooth, and WiFi features to meet the needs of industrial, manufacturing, distribution, transportation, and logistics sectors as well as the retail sector.
To that end, the company complements its Magellan line of point-of-sale (POS) scanners with three other product lines: the QuickScan family of general-purpose on-counter and handheld scanners for low-to-medium volume POS applications, the PowerScan family of handheld bar-code scanners for industrial users needing scanning capabilities from less than 1 in. to more than 36 ft, and the Falcon portable, vehicle, and fixed-station terminals and scanners that collect business-critical data throughout a supply chain.
|
|
Larry Smith, manager of advanced manufacturing engineering at PSC, says his company’s test-system architecture helps PSC engineers keep in touch with its offshore contract manufacturers without having to travel extensively. |
In addition to adding features like Bluetooth and RFID, the company has steadily improved the speed and accuracy of its laser scanners. “Instead of just having three laser lines, you'll see 12 lines coming out at different angles,” said Larry Smith, manager of advanced manufacturing engineering. Such a configuration, he said, enables rapid bar-code reading at any angle—even on hard-to-read labels. “Net throughput for the clerk is what we are looking for.” And as the company's hardware has evolved, so, too, has the software, with recent handheld products incorporating Windows CE and Windows Mobile 5.0 operating systems.
Test keeps pace with product advances
As the boards and components inside PSC's products have shrunk, the company's test engineers have developed test techniques that keep pace. Karl Radestam, staff electrical engineer responsible for test in Smith's department, explained that the techniques he developed handle not only test, but also device programming and boot-code installation. The company's test software has evolved as well, with QNX-based test programs giving way to ones written in Visual Basic and the Goepel electronic System Cascon suite.
|
|
PSC staff electrical engineer Karl Radestam holds a Magellan scanner, one of the first products for which the company employed boundary-scan technology. |
Radestam is one of 10 engineers in the company's advanced manufacturing engineering department, which ensures that the products designed by PSC's 100 development engineers can be economically built and tested.
A key technology that the company has adopted is boundary scan, which, Radestam said, has become a requirement for ICs that have ball-grid array (BGA) packaging and have direct or indirect boundary-scan-I/O access. “As more ICs move toward BGA and smaller packaging with tighter board designs that allow fewer test points, boundary scan is becoming the industry standard, replacing the older ICT [in-circuit test] methods,” Radestam said. In addition, boundary scan offers programming capability for flash and complex programmable logic devices (CPLDs), so device updates can be done with minimal hardware—even in the field. Radestam first employed boundary scan for the company's current line of Falcon handheld products, which employ PSC's densest, most expensive circuit boards, populated with BGAs.
From a test-development standpoint, Radestam said, his efforts begin with consultations with development engineers and extend to pilot low-volume production runs at the PSC headquarters. Finally, he provides support for the test hardware and software provided to PSC's contract manufacturers (CMs) in Asia.
A basic test system that Radestam develops (Figure 1) employs boundary-scan and analog I/O boards and CION (Configurable I/O Network) boundary-scan modules from Goepel electronic. In addition to boundary-scan test hardware and software, PSC's test systems employ hardware for supplying power, actuating unit under test (UUT) buttons, and measuring voltage and current signals. The hardware can include relay cards, serial-port cards, parallel-port cards, and USB devices in addition to digital multimeters (DMMs), oscilloscopes, and various sensors for LEDs and speakers. All test fixtures use Visual Basic software for the user front end.
|
|
Figure 1. This simplified diagram of a PSC test system shows the principle components and subsystems as well as primary signal and data lines. Other components, not shown here, can include actuators and sensors for testing keyboards, touch screens, and displays, and, for products that work with PCMCIA cards, a card-slider mechanism. |
Notably, despite the amount of press coverage given to instrument interfaces such as PXI and LXI, PSC is not moving toward adopting them. The company relies primarily on not even GPIB but on RS-232. Said Smith, “We won't buy an instrument that doesn't have an RS-232 interface.” He said he grew up around GPIB and worked with some of the authors of the original HPIB spec, and he noted the irony of RS-232 now being the company's instrument interface of choice: “It's hard for me to accept coming back around to RS-232,” but he added that it's the simplest and most cost-effective interface for PSC's test applications.
Fixtures become simpler
In the approximately three years that the company has been using boundary scan, PSC's test fixtures themselves have evolved into simpler, lower-cost systems. For a basic system, Radestam said, “The hardware includes a Goepel analog board for measuring different analog voltages and, in addition, separate Goepel CION modules wired into wherever there is a boundary-scannable connectorized point on the Falcon product under test. It also includes some custom circuitry: a switching relay for power and a couple of voltage regulators. We also included a card-slider mechanism because this product worked with a PCMCIA card slot” whose functionality had to be tested.
The original boundary-scan-compatible fixture, said Radestam, wasn't designed to support hardware reuse—it integrated custom test hardware for a single UUT into one box. “We are limited to testing one product on it,” he said.
The original fixtures also each include a custom test-interface board and require a lot of hand wiring. In addition, each employs a relatively expensive industrial computer with similarly costly software licensing. The move now, said Smith, is toward configuring test systems with individual standard commercial PCs and their own instrumentation, although the company continues to use its original fixturing to make best use of the software licenses it has purchased.
|
|
Interconnect boards that adapt a test fixture’s standard pin-out to the unique needs of a unit under test help to minimize custom wiring. |
The way PSC develops its new text-fixture boards has resulted in significant cost and time savings. Smith explained, “We've gone from producing G10 test-fixture boards that must be individually engineered and hand wired to an approach where we develop and lay out the interconnect boards at the same time we lay out the product board.”
The interconnect boards are designed to adapt PSC's standard Testron test-fixture pin-out configuration to the unique needs of the board under test and are laid out to enable custom hand wiring to be replaced by double-sided Pogo pins. Smith noted that the approach shortens considerably the time needed to get a pilot line up and running. “We get the fixture boards back close to the same time we get the UUT—within a few hours. In the past, it took something like two weeks for the custom wiring.
“The interconnect assembly is basically a sandwich that supports the Pogo pins,” said Smith. “Any time we have a change in the UUT boards, instead of having to carefully dismantle the fixture and send the interconnect boards to a model shop to have new holes drilled, we just get a new set of PCBs made up and swap them out. A real advantage of this is that when we go offshore, in order to make a change in the CM's test system, it's just a matter of sending them this new [interconnect board] stack. In the past, we'd have to physically build up a system and send it to them, and they would have to turn around and send the old one back, which was very cumbersome.”
Regardless of fixture vintage, the test process powers up the UUT, tests its JTAG chain, measures analog voltages, and finally does the complete boundary-scan test where it actually wiggles all the nodes internally. Test programs that Radestam develops determine what tests get performed for each UUT and in what sequence. He designs the user interface that a test technician sees using Visual Basic. The Visual Basic interface also serves as a front end to an SAP SQL database and statistical-processing tool. Radestam said that each test system records results of each subtest to a local hard drive; results are later uploaded to a central server.
Radestam programs the subtests themselves in Goepel's System Cascon software. A typical test sequence might include power-off resistance measurements using a DMM. Subsequent steps include powering up 5-V and 12-V power-supply bricks, measuring power-supply voltage and current, and invoking Cascon to measure analog voltages and perform an internal JTAG-chain test followed by a full JTAG test of all JTAG-compliant circuit nets.
Test development begins at alpha stage
Radestam elaborated on the test-development process, which for him begins when product-development engineers release an alpha electrical schematic. “At that point they don't have the layout done—they just have the electrical schematic developed with a Mentor Graphics schematic-capture tool. I take the netlist and convert it to EDIF [electronic design interchange format], which I can then import into Cascon. I'll also create any other files I might want, such as PDF files,” which he likes to produce so he has a text-searchable version of the schematics that he can work with without using a schematic editor.
Radestam then defines the boundary-scan test points he needs and associates them with particular CION modules. At that point, at the alpha stage, he will usually parse the UUT netlist without merging it with the CION netlist, because he won't be building fixture hardware until later. Parsing the unmerged netlist allows him to create a file that allows technicians to load boot code and CPLD configuration code into a prototype UUT using a low-cost programming cable.
He said that, for the second go-around, “When I get to beta I'll take the same project and do a 'save as,'” a special feature that he asked Goepel to develop for Cascon so he could preserve his work at various stages of the test-development process. “Then, I'll go ahead and merge the UUT's and CION modules' netlists to combine the two.”
At either the alpha or beta stage, the parsing process tends to generate error messages regarding parts in the UUT's bill of materials that aren't supported within Cascon. Radestam can develop missing models himself from the information on the data sheet, but he said he often saves time by obtaining the models from Goepel, a service he pays for as part of his Cascon support package. “It could be time prohibitive for me” to develop the models, he said, “but Goepel has people who do this all day long.”
On having successfully completed the parsing process, Radestam uses Cascon to create scan paths. He then develops executables to perform JTAG and interconnect tests. Sometimes, he will develop RAM tests within Cascon, but he noted that many of PSC's products employ a built-in RAM self-test, making the Cascon tests redundant.
Radestam then develops cluster tests for the non-JTAG-compliant components that often surround a boundary-scan-compatible processor and CPLD. Many of these parts can be tested with proper models or custom boundary-scan tests, he said, but some have special requirements for high-speed serial data, control lines, clocking, and register access that make it almost impossible to develop boundary-scan tests for them. For these special ICs, Radestam develops a custom embedded manufacturing test capability that loads with a UUT's boot code or app code to permit a functional test to be done separately after boundary-scan testing.
|
|
Engineer Chuck Polley examines a test fixture for which he developed the Pogo-pin interface. |
Next, using the Pascal-like Caslan language in System Cascon, he creates manual procedures for analog measurements, delay tests, and so on. In addition, he uses the Cascon environment to develop executables for loading boot code into flash and for loading serial vector format (SVF) files for configuring CPLDs.
Meanwhile, Radestam said, he has passed on his test-point requirements and his connection list for connecting the CION modules to the UUT to engineer Chuck Polley, who develops an electrical schematic of the circuit-board interface, essentially representing those test-point connections. Polley provides his schematic to a circuit-board designer, who matches the test-point connections one-for-one with the UUT circuit board he just designed. And when a product revision comes out, the designer who redesigns the circuit board will revise the test-fixture circuit board as well, often without the need for test-engineering input. “I may have minimal involvement or even not need to be involved at all,” said Radestam.
High-speed port augments JTAG
Radestam noted that while boundary scan is adept at loading boot code and CPLD configuration information, it does have its limits. Those limits come into play for UUTs that also require the uploading of separate applications code. App code, said Radestam, can take up as much as 64 Mbytes in products like the Falcon, and he said that the JTAG port is too slow for loading that much code.
Consequently, the company employs an alternate high-speed serial test port for uploading app code. Radestam noted that the test-port approach enables smarter uploads. “You can look at the binary file and see where the empty spaces are and not load those. It's much more efficient and quicker than JTAG.” He said that the serial test port can't serve for loading boot code because, for products using Windows CE and Windows Mobile operating systems, the boot code must be in place for the serial test port to work. An alternative, he said, would be to buy memory devices with boot code already programmed, but that's an expensive approach that makes revisions difficult.
The test port can also help in testing non-boundary-scan parts, he said. He cited as an example a touch-screen controller IC that requires a 12-MHz crystal on it: “To talk to it through its SPI interface, you'd have to wiggle awfully fast—much faster than JTAG permits. So in that case, I have a built-in self-test for it that operates through my test port.”
JTAG across the board
Radestam explained that although he first employed boundary scan on the Falcon product line, the company has expanded boundary scan's use to the full product line-up. Said Radestam, “Our offshore manufacturers relied a lot on in-circuit testing when we first met them. Now, they're pretty much switching over totally to the test fixturing that we supply them with. I don't think they use their ICT for any product we send them.” He added, though, that they do use optical inspection and x-ray inspection prior to boundary-scan testing.
Smith commented that it's surprising how few trips PSC engineers have to make to assist the CMs. In part, he said, it's because PSC has duplicates of the CMs' equipment at its headquarters, but it's also because of the way PSC has architected its test systems, which allows PSC and CM engineers to stay in touch without having to physically visit each other. Part of that architecture involves a software “kiosk,” installed in PSC's procurement department, which, for example, allows Radestam to sit in his office and log onto a tester at a CM's remote location. If a problem exists, Radestam said, “By the time we are ready to go home at 5 o'clock, we can have answers waiting for them as they start their day.”
A training program that brings CM engineers to Eugene to learn about how PSC's products work also helps, Smith said. “The CMs tend to be very proficient at manufacturing but are much less knowledgeable about how our products work,” which can hinder their ability to respond adequately to unexpected test results. The training program, Smith said, addresses that.
When asked what he hopes to see next, Radestam said PSC purchasers are always trying to save money by buying ICs that aren't boundary-scan compliant. “If test vendors wanted to make boundary scan simpler to use, they could expand their software support of a much wider variety of non-boundary-scan devices (models and options for custom tests) so there is minimal effort setting up new projects.”
No related content found.
- 0 rated items found.
Datasheets.com Electronic Parts & Inventory Search
185 million searchable parts
- Part Number
- Description
- Inventory
- Products
- Manufacturers
View All Webcasts
