New test prog causing leakage failures?

Guest

What is the best way to know if our new test program is the one causing our new failures? The test program was qualified before release but we now see a higher percent of leakage fails after it's used on the line.

Joined: 31 Aug 2026 Posts: 16

Midi, I think the best way to know if you're program is causing the leakage failures(or not) is to verify these ATE leakage failures on bench(if possible). The bench data is the "TRUE" data.

By the way, I would like to ask additional information.

1. What is the datasheet specs of the leakage current parameter?
2. What is the typical leakage current failing value?
3. How was the leakage current measured? Is it directly(through VI's) or through some other circuits(ie. in-amp - resistor combination)?
_________________
Asmoth72

Joined: 08 Mar 2026 Posts: 1

I agree with Asmoth. The failures you are seeing should be verified either through bench or in another ATE. Check whether the testers are correlated. This way, you will know if the failures are valid or not.

If the failures are valid, you might want to do further failure characterization and analysis.

If the failures are verified passing, check whether you have a marginal distribution or not. If the distribution is not marginal to your limits, check your handler and program. Sometimes, oscillations (tester/handler set-up related) could be remedied by increasing your sampling points and test time. Be careful with the test time though. You might be significantly slowing down production.

Check also your test sequences. Leakage testing done after a test parameter in the linear operation of the device would usually overreject. Leakage testing is best done after cut-off region testing (breakdown tests).

Hope this helps.
_________________
Markus

Joined: 20 Jun 2026 Posts: 76

If the failures are confirmed valid by bench testing, I would also suggest to Midi that he/she first confirms that the increase in leakage failures can be observed in a wide spectrum of unrelated lots before concluding it's due to the new test program. Rule out first that the problem is not confined to a single fab lot or date code or test eqpt, etc. In fact, following Markus' suggestion, running two fresh splits from a single lot using the old and new program on the same ATE would give valuable info.

Joined: 31 Aug 2026 Posts: 16

Once validity of leakage failures is confirmed through bench, then the next thing to do is verify if the program is causing the said failure, or if the device is indeed having large leakage.

To do this, I would recommend that you confine your evaluation on the lot in question and the test program, before you introduce other variables(ie. other fab lots, verifying using old program).

To do this, you can simply re-test all good parts using the new program, but this time, using the QC option. If all good parts passed QC test, then it is likely that the new program is not causing the leakage failures. You can therefore conclude that the leakage problem is concentrated on the lot.
_________________
Asmoth72

Joined: 20 Jun 2026 Posts: 76

Hi Asmoth,

At the risk of confusing Midi, I just want to clarify my earlier recommendation.

I was thinking that Midi needs to see the leakage issue on a more widespread scale than just a single lot to be able to conclude that the test program is the culprit. That's why I think it is more prudent to stratify the leakage fall-out data first in various ways, before actual evaluations are done. After all, a paper review of the data is not that difficult.

Anyway, Midi should be able to decide what to do, since he or she's the one seeing his/her data right now.

Midi, pls update us if you find something good to share.

Joined: 31 Aug 2026 Posts: 16

Hi FARel Engr,

I'm looking at the problem from a test developement engineering point of view. In our field, we usually identify the problem at its minimal variable factors level.

Although spreading the evaluation by using parts coming from different wafer/fab lot is not discouraged, I just think that it is more advisable to identify first the cause of the problem, by just only considering the factors involved on this issue(new software, lot in question). If we can pinpoint the cause of this leakage current failures(assuming verified valid on bench), then we can immediately apply the corrective action.

By testing parts coming from different fab lot/s, we will only encounter the same issue if we were not able to identify the problem on its first occurrence. Like for instance, after testing different fab lot/s, we still encountered some valid leakage failures, what would our conclucion be?Can we conclude that it is due to the new software? Of course not.

Testing one lot by two way split, wherein half will be tested using the old software while the other on the new software is also a good idea to determine if there are some problems on the new software. However, what if the old and new software produce similar test results? This would mean that the new software is not causing the leakage failures, because if it does, then the test results on the new software would produce more leakage failures.

This is the reason why I strongly recommend to just confine the evaluation on new software and the lot in question for now. If we can find out the problem at this level, then there will be no need to include other wafer/fab lots in the evaluation. If the problem is on the software, then we can immediately apply the corrective action.
_________________
Asmoth72

Joined: 20 Jun 2026 Posts: 76

OK, Asmoth. At least all points have been clarified, so we can leave it at that. After all, maybe Midi has already moved on and is already working on a new issue without telling us?