From shott at stanford.edu Tue Jun 1 17:19:09 2010 From: shott at stanford.edu (John Shott) Date: Tue, 01 Jun 2010 17:19:09 -0700 Subject: Field service update .... Message-ID: <4C05A37D.8030603@stanford.edu> STSetch2 community: Frank Monano from STS Field Service arrived mid afternoon. He had time to adjust the rotational alignment of the carousel so that wafers are now well aligned on the chuck as determined both by the mark on the backside of the wafer from the lip seal as well as based on the shadow of the clamp fingers on the top side. That alignment looks good and well matched in both carousel position #1 and in position #2. During the course of the afternoon, we loaded approximately 6 wafers from each of the two carousel positions and did not see the situation that others have reported where a wafer does not actually end up on the chuck but comes back out on the carousel. Others have reported that this happens when the wafer is mounted in carousel slot #1 but not when in slot #2 (the number is stamped in the carousel at the 9 o-clock position of the wafer nearest you when the load door is up and you are standing at the end of the machine). We have cleared the wafer loading shutdown so that some may be able to get some useful etching overnight. To be conservative, I suggest that you load your wafers in carousel slot #2. Note: Frank believes that we may still have to adjust the reed switch that determines when the pins are fully lifted during the wafer loading. If that switch engages too soon while the pins are still lifting, the carousel arm will begin to retract before the wafer is fully lifted. This will result in the failure to load a wafer and it will still be sitting on the carousel arm ... although offset towards the chamber. In any event, we are hopeful that some of you may be able to get some useful etching done this evening. Tomorrow morning we hope to look at the "clearable" RF error and look in detail at the positioning of the lift pins relative to the switch that senses the wafer up position. Happy etching, John From shott at stanford.edu Wed Jun 2 15:04:05 2010 From: shott at stanford.edu (John Shott) Date: Wed, 02 Jun 2010 15:04:05 -0700 Subject: Qualified stsetch2 pilots? Message-ID: <4C06D555.4090500@stanford.edu> stsetch2 community: Frank Montano from STS field service has made some changes that he believes have addressed the issues that folks have been seeing. In particular, he believes that the lift-pins are coming up faster and now lift the wafer off the carousel before the carousel begins to retract. He has also made some adjustments to the RF matching network that he believes will address the drop out issues. At this point, we are looking for someone able to test the machine .... on expendable wafers ... to see where we stand. The machine is currently shutdown but enabled in Elmer's name so you should be able to run it for testing purposes. Note: aside from testing, we will likely leave it shutdown overnight to allow for a complete disk defragmentation to run. The disk has become badly fragments and resolving that is the first thing to do in terms of addressing the painfully slow recipe loading that has been observed recently. If anyone is available and can help out, I would greatly appreciate it. Also, if you are available to help, please "Reply all" to this mailing list so that we don't end up with a group of folks trying to pitch in simultaneously. Thank you for your support, John From mcvittie at cis.Stanford.EDU Fri Jun 25 09:08:21 2010 From: mcvittie at cis.Stanford.EDU (Jim McVittie) Date: Fri, 25 Jun 2010 09:08:21 -0700 (PDT) Subject: STS2 Status Message-ID: Hi, Thanks to help from Elmer and a software engineer in England, STS2 is back up. To make sure that everyone uses updated recipes. We have removed of the old recipes. Please contact Srikant Vaithilingam or myself if you want us to correct, test and restore an old recipe. We were not able to remove or correct the old template recipes which are locked and cannot be changed or removed. Until we can figure out how to correct the template recipes do not use them. The exception is "Jim SOI Templete" which has been corrected and tested. Also do not make any changes to the tolerance file. I am looking into how to make them protected files so they can not be changed by users. The corrections we are making to the old recipes are: 1. Changing the tolerance file from standard to switched or unswitched as needed. This change makes sure a process with excessive reflective power faults out rather than damaging the rf generator. 2. Reducing the max coil power to 2800W or less. We have found that some users have increased the coil power to reduce grass formation. While this may reduce grass, it is wrong approach. The proper approach for increasing ion energy for reducing grass is to increase the platen power NOT THE COIL POWER. Accessive coil power with poor matching settings is the main cause for the power drop out problem. 3. Adjusting the tune and load matching pre-sets for both the coil and platen (low and high frequency) generators, to minimize the initial reflected power. Later, I will send out a list of starting pre-sets for different standard recipes. For ramped recipes, one has to set both a begining and ending valve for each of the four matching pre-sets ( dep tune, dep load, etch tune and etch load). If the platen matching is not set correctly, it can affect the coil matching and cause drop outs. 4. Checking that the pulse mode is set correctly for the low frequency SOI processes. 5. Checking that all switched recipes start with a dep step and if there are multiple steps, that each one starts with a dep step. Thanks, Jim -------------------------------------------------------------- James (Jim) P. McVittie, Ph.D. Sr. Research Scientist Paul G. Allen Building Electrical Engineering Stanford Nanofabrication Facility jmcvittie at stanford.edu Stanford University Office: (650) 725-3640 Rm. 336X, 330 Serra Mall Lab: (650) 721-6834 Stanford, CA 94305-4075 Fax: (650) 723-4659