Have you ever had to learn a new, complicated software application or programming language? Most of the time it’s not that difficult, but it takes time and can be frustrating when you’re trying to meet deadlines and make forward progress. In the test engineering world, coming up to speed on a new test environment typically requires learning a new development environment, maybe even new programming language, as well as new instrumentation and hardware details. And the stakes are high – get it wrong and you ship bad parts or throw away good parts. There are nuanced issues and pitfalls in all test environments and most of the learning curve associated with operating a new ATE platform is spent trying to figuring out what to do and what not to do.
In this blog, I’ll focus specifically on Teradyne’s IGXL test programming environment for the J750, FLEX, and UltraFLEX ATE platforms and discuss some of the common problems that have been uncovered through some painful lessons over the years. These can be helpful for those just coming up to speed with IGXL, and even the seasoned veteran may find a few nuggets of wisdom.
No Error Bin Defined – Found in the program’s main flow file, the Error Bin identifies the default handler bin to be used in case of a program run-time error. Test programs without an error bin definition may cause a handler or prober to lock up during production testing or worse, a device may be binned as good when actually the device had an error (known as a test escape – a failing or unknown device sorted as passing device).
No Default Bin – Also in the flow file, the Default Bin identifies the bin to be used in case a requested bin does not exist. Test programs without a default bin definition can also cause a handler or prober to lock up during production testing or may result in a run-time error. Similarly to the Error Bin, a test escape may happen if no default bin exists.
Missing Bin – Bin numbers (aka ‘Hard Bins’) are used for sorting devices according to their major failure category. Found in the flow file, these bins tell the handler how to sort the passing and failing devices. Each test or limit should have a hard bin value – a test without a hard bin value may result in devices being sorted into the wrong physical category, again resulting in a potential test escape.
Missing Bin Result – The Bin Result category allows a test to assign a pass or fail result for a test run. Each test and use-limit statements should have a bin result, which informs the test program what to do with a device when it fails a tests. A missing bin result may cause a test escape if a part fails and there is no bin result.
Error Handler Definitions – Error handlers tell the VBA module code how to proceed when a run-time error is encountered. If an error is encountered while running, the error handler should manage the error and allow the test program to continue without interruption. In the case of multi-site test programs, the Teradyne-recommended error handler allows the test program to recover from an error on one device and continue testing the remaining multi-site devices. Code without the proper error handler has a very high likelihood of skipping tests for some devices. As an example, say a test requires a serial loop to make a calculation and perform a test. If the first device of the multi-site program encounters a run-time error in the serial loop and an improper error handler is used, the code may branch (exit) the test without actually doing the calculation and test on the remaining multi-site devices. This is a very common cause of test escapes that is easily avoided by using a proper error handler.
Option Explicit and Compile – If I had to pick one item from this list that can result in better, more robust code, it’s using Option Explicit and compile. Option Explicit tells the VBA compiler to check for variable definition and provides extra compile-time error checking. The simple act of adding this construct to the head of every VBA module and then using the Compile function can quickly and easily identify many typos, logic problems, and type casting issues. Without Option Explicit, variables of any type can be created on the fly without dimensioning and no warning is given. For example, say you have a measurement that is stored in a variable called compcalc and mistakenly, later in the code, you use the variable compcal (notice the missing c) to test to limits of +/- 0.1v. Magically, the test passes every time… because the variable compcal is defined on the fly and initialized to zero. With Option explicit and compile, the compiler would tell you the variable compcal hasn’t been defined and you would catch this problem before you ever set foot on the tester.
Site Active Check – When a test program runs and a device fails, the tester instrumentation used by that site is deactivated and disabled. Once the site instrumentation is disabled, any setup calls to the hardware will result in a run-time error. This occurs frequently when using a functional template and the pattern test fails. Any setups or measurements made in the PostTest, PostPattern, or PostBody interpose function can cause a run-time error if there are no active (alive) sites. When a device fails the functional test it is disabled and all the hardware associated with it is disabled. A check should be done before doing any setup or measurements at the head of these ‘Post’ functions to prevent errors. Another common problem is disconnecting channels or opening relays after a limit test or pattern run within your VBA code. After any test is done (functional pattern test or variable test), the VBA code should check to see if there are any active sites before doing any hardware-related setup.
Default Global Specs – A global spec that is referenced and does not contain a value for a particular job will result in a run-time error. When multiple jobs exist, you should ensure a global spec value is defined for each job, or include an additional spec definition with the Job field left blank (default). For example, if there are three jobs (Final, QA, Char), each global spec should have definition for each job or a blank (no job specified) spec to use as the default.
Disabling Alarms – Disabled alarms may mask an issue that can result in run-time errors or damage equipment and devices. Sure, there are legitimate situations that require disabling alarms but I would argue those situations are very few and far between. Too many times, alarms are screaming indicators of test issues that should trigger a closer look at the code (peer review) to ensure disabling alarms is appropriate and that the alarms are re-enabled as quickly as possible.
If you’re looking for even more information, Test Spectrum has a new software application that automates the process of screening known issues and bugs in test programs. CodeReport scans IGXL test programs for the problems listed below along with several others. CodeReport also allows you to generate your own, custom set of rules to catch your own set of “gotchas”. You can create rules for ensuring your program standards and requirements are correctly implemented before releasing your program to production. Find out more at codereport.testspectrum.com.