Technical Blog

Specialised R&D equipment is expensive, usually takes many months to arrive, has to be interfaced with, and never quite does what you want it to do! The aim of this blog is to share a few hints and tips on some of the items of equipment and tools we at EnSol have used, and custom built as part of our own R&D work. Please have a look below: • Qartz Deposition Rate Monitor • AVR-32: o Powering up and Getting Started With Ports. o Serial Communications With the USART. o Using the ADC and outputting the data to USART. o Using a timer- A simple time delay.

Quartz Deposition Rate Monitor

One great asset in a deposition system is a deposition rate monitor. This is crystal of quartz that is set to resonate at its natural frequency. As material is deposited onto the crystal, this frequency changes, and from the rate of frequency change, a deposition rate can be calculated. In many cases even a relative deposition rate is of great use; to identify if a rate has dropped off after a deposition cycle for example, or simply if there is any beam there! For the rate monitoring specialist crystals are commonly available for around $3 per piece (see figure). They consist of a thin slab of a single quartz crystal with (typically) gold or silver contacts on front and back. The challenge with operating the crystals is that the front (solid contact) surface is usually in contact with a metal crystal holder and grounded to the rest of the deposition system. This avoids any build-up of charge on the surface when used in sputter systems for example, but makes the electronics of any oscillator more complicated.

The Oscillator Circuit

The figure shows a simple free-running crystal-driver circuit based on the MC100EL16 or MC10H116 differential line driver ICs. The sine wave output from the drivers are converted to a TTL square wave, via a TLV3501 high- speed comparator, for subsequent processing.

Counting the Pulses

To calculate a deposition rate, the frequency change over time must be measured. The simplest way of doing this is to just count the number of oscillations per second. However, for low density materials and low deposition rates, the frequency change that needs to be measured can be less than 1Hz, which can ultimately lead to long measurement times. To slightly speed this process up, an alternative is to “gate” a second higher speed counter with a certain number of pulses from the crystal. Such a circuit is shown in the figure to the right. The 74LV8154 IC’s are both used in 32-bit (4-byte) counting mode. The first IC is set to count, and transfer the counts to the output buffer, with every incoming crystal pulse. It is set up to output the 3rd byte of data on its outputs. A set of jumpers allows a particular counter bit to be selected e.g. for the 22nd bit corresponding to 4,194,304 counts – which will clock in less than 1 second with a 6MHz crystal. A second 74LV8154 IC is implemented and clocked from an active oscillator module. (In this case 30Mhz – 5 times the crystal frequency). Counts from this counter however, are only transferred to the output buffer when an incoming pulse is received from the first 74LV8154 IC. The result gives; the number of 30MHz pulses in every 4,194,304 crystal oscillations, from which the crystal frequency can be calculated – but at 5 times the speed of counting the crystal pulses directly. The second counter can simply be left running and software used to determine when the counter has rolled-over (and started from zero again). Interfacing to the two counters is done with an Atmel AVR-8 (atmega-168) microcontroller. This does the basic housekeeping for the timers, resetting them, collecting the bytes of data and sending them to wherever they are needed. In our case, they are transmitted via a simple RS-485 interface to a computer which controls the whole vacuum system, where the deposition rate can be calculated and plotted. The figure to the right shows the final oscillator and counter module with microcontroller. (The RJ-45 connector is used as a cost effective interface for supplying power and RS-485 connections, allowing several units to be daisy chained together)

The Mechanics

A considerable expense with installing a deposition rate monitor is the mechanics; the crystal housing, wiring and electrical feed-through into the vacuum system. One great draw-back is that water cooling is often implemented to prevent any shift in the crystal frequency as a result of temperature change. (This is particularly the case when it is desirable to move the deposition rate monitor in and out of a beam). For thermal deposition systems, this temperature variation may be a significant source of error (typically of the order of 1ppm / oC). Compensation systems, such as temperature monitoring, or using a hidden reference crystal could be implemented as an alternative to the water cooling, but if the likely thermal drift is acceptable, then the whole system can be made much more flexible and simple, without compensation or water pipes. (Increasing the “thermal mass” of the crystal holder can also be used to help reduce the effect where only intermittent rate checking is needed). The first two figures show a simple deposition monitor housing. Small, plated, spring loaded “pogo-pins” are used to hold the crystal in place and provide electrical connection to the back of the crystal. A printed circuit board, allows for a very cost effective way of providing an electrical connection, in this case through an MCX connector . (Though not ideal for Ultra High Vacuum (UHV) systems, the component outgassing rate has been found insignificant for our own HV system particularly when used in conjunction with lead free solder.) Finally for connecting the crystal through the vacuum chamber and to the outside world, today’s large selection of small RF connectors are idea for the application. The insulators of such connectors are usually PTFE and whilst it’s doubtful that the metal parts are gold plated and not simply titanium nitride coated, they are equally compatible with a vacuum system. The last figure shows a few such connectors, the threaded SMA style to the left and the smaller MCX to the right. Smaller cables and connectors are available, but the ones shown, area a nice size to use, being compact and space saving but not too fiddly. For the cable connectors the “windowed” style is highly recommended. These have the central pins moulded in-place and the central wire can be soldered directly to it via an access window in the connector housing. So there is no trouble with having to cut the various cores to precise lengths and insert the central pin afterwards. To the rear of the photo a length of RG-316 cable is shown, which is used in conjunction with these connectors. This can be purchased with silver plated wire, and PTFE or FEP insulator (around $1 /m). In some cases, to minimise virtual leaks, the outer jacket of the cable can be removed, however this does adversely effect the flexibility of the cable and has been found unnecessary in our own vacuum system.

AVR-32:

Atmel’s 32-Bit UC3C Microcontrollers:

Atmel’s AVR-32 series of microcontrollers offers a tremendous increase in power and flexibility over its AVR- 8 (8-bit) controllers, but there is little information available on the net about them. Atmel does have extensive documentation with its AVR-32 framework files, but this can be a little hard to get into, and not very easy to understand what’s actually going on. Most of the examples also tend to be specific for a particular demonstration board, so it can be a bit of a leap in at the deep end developing your own application. These pages are aimed at helping making the transition.

Basic connections:

For ease of availability and soldering I have chosen the 32UC3C264C-U controller. To make sure you have all the connections needed for your application for these UC3 C devices Atmel does have the handy AVR32768 application note with schematic check-list. The schematic (opposite) shows the very basic connection for powering, programming and de-bugging. (With an additional 3 LEDs connected for demonstrating the port functions.) For my own testing I am using a JTAGICE MKII with AVR visual studio 6.2. I found that version 6.0 had a few bugs in it like not showing up some of the ports when debugging.

Getting to grips with the ports:

The first important information you need from the data sheet is found in section 3.2.1 table 3-1 (page 11) which shows the various pin functions and allocations on the controller (an extract is shown opposite).We can see pin 42 (PC18) is linked to General-Purpous Input/Output – GPIO number 82. Like the 8-Bit controllers the AVR-32 also have a series of different ports, with associated (32-bit) registers to allow access to them. However the various Port C, Port D.. etc are not as strictly defined. So the correct GPIO port number is calculated by dividing the GPIO number by 32 (and rounding down). GPIO Port Number = floor (82/32) = 2 The corresponding GPIO pin number is now calculated as the remainder of the GPIO number divided by 32: GPIO Pin Number = remainder (82/32) = 18 (See page 461 of the data sheet for more information.) Now we know which pins we are dealing with we need to set them to outputs and switch them. There are several different commands available for switching the GPIO functions: (S)et – Sets a particular pin or pins to 1. (C)lear – Sets a particular pin or pins to 0. (T)oggle- Toggles / cycles a particular pin or pins 0, 1, 0, 1 etc. (And the direct command without suffix which sets all the pin values.) Firstly we need to enable the particular pins using the GP Enable Register command, in this case we use the Set command gpers: As the commands are typed into Atmel studio the auto-complete function will assist with finding the correct commands. The statement is interpreted as; using the AV32_GPIO functions, working on port [2], using GPIO (set) enable register, and writing a 1 to bit No. 17 (ie. 1 left shifted 17 places). Next we need to set the pins as outputs, by enabling the pin drive function with the Ouput Driver Enable Set command: Finally we’re ready to switch the LEDs off and on. This is done using the OVR command, to set all the pins directly or using Set, Clear and Toggle options for only changing a particular pin (in a similar way to the sbi and cbi functions used with AVR-8 programming. (See page 461 of the data sheet for more information.) So we can now put together a simple program to sequentially light the LEDs. (Note the AVR-32 does not support the _delay_ms() function of the AVR-8 so the LEDs will flash rather quickly!!

Serial Communications with the USART:

Again whilst the AVR-32 framework offers examples of using the USART they are not so transparent and easy to configure for your own use. This section will demonstrate how to set up the USART to send characters. These can be picked up on a computer using a “com-port” viewer such as “RealTerm” using a simple “USB TTL RS-232” interface which can be purchased very cheaply from china. A schematic for wiring up the microcontroller is shown opposite. Ports PC16 (and PC15) will be used for the USART. This choice is made with reference to section 3.2.1 table 3-1 (page 11) of the data sheet shown opposite. We see these chosen pins can be used as USART0-TXD & USART0-RXD if we select GPIO function D. The first thing that must be done with the microcontroller is to change the system clock, as by default this is set to RCSYS which is 115kHz, (see page 60 of the data sheet), and is a little slow for useful baud rates of serial communication. For convince we will switch to the built in 8MHz system clock. Before we can switch the main system clock to the internal 8MHz clock it first has to be enabled. This is done with the RCR8 register, which is part of the System Control InterFace module (page 114). The 8MHz clock is calibrated at start-up, in order to preserve this calibration value we will first copy it to a variable before rewriting it, with the enable bit, to the register. This register is protected by a lock however, and in order to unlock the register, to make changes to it, we have to write both a key (0xAA) and the address offset of the RCR8 register (0x0048) to the SCIF UNLOCK register (page 100). Again the auto-complete function of AVR studio is a great help, and has values for these already implemented. (The actual value of the auto complete AVR32_SCIF_UNLOCK_KEY_VALUE variable is shown as it is selected. Placing the cursor on this text brings up its defined value at the top of the code window.) Having unlocked the RCR8 register we can now write to it and enable the clock: Once activated and running, we can now switch the main system clock over, using the Main Clock ConTRoL registers in the Power Manager module (page 60). Again this register is lock protected: Having unlocked the MCCTRL register we can now write to switch over the clock source: Next comes the job of setting up the TX output pin. Firstly we switch the PC16 port pin to peripheral mode by clearing the corresponding GPIO bit (page 462). This allows the pin to be used by one of the other peripheral functions of the port: From the GPIO function table (show at the start of this section) we can see that function D is for using this pin as USART0 TX. This is selected by programming the corresponding Peripheral Mux Registers in the GPIO module for that pin. For Peripheral function D we need to set PMR2, PMR1, PMR0 to 011 (see page 267). We can now initialise USART0. In this case we will set it up in simple asynchronous mode, 8-bits, no parity, 38,400 Baud. The first of these parameters are set using the Mode Register of the USART module. All bits in this register are reset to zero at start-up as shown in table 25-16 page 625 so only the following need to be changed: Next the correct Baud rate for an 8MHz clock is set using the Baud Rate Generation Register and changing the Clock Divider bits to 13 (see page 569): We can now activate the transmit function using the TX ENable bits of the USART Control Register (page 626): The USART is now set up and ready to transmit data by writing a character to the TX CHARacter bits of the Transmitter Holding Register. An additional while loop can be used for when transmitting many characters to delay until the Transmitter Holding Register is again empty (page 635).

Using the ADC and outputting the data to the USART:

In this section we will set up the ADC of the microcontroller to do a simple single conversion and then send the value to the USART (after converting it to an Ascii character string).

Initialising the ADC:

If you have run through the previous sections in this AVR-32 blog, you should be feeling more confident with accessing the various registers and functions of the 32-bit microcontrollers. So we can launch straight in with the initialisation of the ADC: The code itself is fairly self explanatory. The ADC section of the data sheet gives more information about the registers used. It’s worth noting the reset values of the various registers (typically zero), and what functions are set up by default as a result. This allows only the bare minimum of register changes to be set. A couple of notes regarding the auto-complete function, which tend to cause a few compiling errors if not spotted: • Be very aware that something like: AVR32_ADCIFA_INNSEL00_CNV0 is actually a defined value where as: AVR32_ADCIFA.INPSEL00.cnv0 refers to a section of a register. • Similarly: AVR32_ADCIFA.innsel00 refers to the whole value of the register (and is expected to be followed by =[value];where as: AVR32_ADCIFA.INNSEL00 refers to part of a register (and is expected to be followed by which part you wish to address e.g. .cnv0)

Converting a number to a string of characters:

One useful routine to have around is for converting a number to a string of Ascii characters that can easily be viewed on something like RealTerm com-port viewer (after sending over the USART). To avoid complicating the routine with pointers, the variables ADC and Sign are made public in the initial part of the code.

Full ADC to character string code:

The code shown below combines the above sections with the previously introduced code. The 10-bit ADC value from differential inputs on pins PA4 and PA19 and continuously sent as a character string. The main routine: • Signals for the start of a new ADC conversion, and then waits for it to complete. • Copies the value to a variable and sends this to be converted into a character string. • This is then sent over the USART before resetting the ADC end of sequence flag. A couple of notes on the code: AVR studio in its many guises often has issues with returning actual values from variables in debugging mode. In this case the variable ADC_Value could be stated as an integer however when debugging it always has the value of zero. Forcing the variable to be a volatile solves this problem, and the value can be check. However it was found that the value would not be updated properly if the code was interrupted each ADC cycle, only if the code was allowed to proceeded and then paused after some interval. The subroutine Send_Serial could use a simple loop to send each character of the string to the USART. However from experience with AVR-8 microcontrollers, this can sometimes lead to loss of data as the loop takes too much controller processing time and the synchronisation of the serial data is lost. “Carriage return” and “line feed” characters are added to the end of the data. This formats the data nicely in the com-port viewer, returning placing the cursor to the start of the next line.

A Simple Timer routine:

Accessing the timer / counters on the AVR-32 chips is a little harder than you might expect, as finding the actual registers in the AVR studio software takes a fair bit of trial and error! The simple routine shown below initialises Timer0 and programs the Compare register of part A of this timer. A simple while loop is included for illustration, which waits for a compare match before exiting the loop. An LED previously set up, (on port PC18) is toggled with each cycle to allow the execution to be verified. In this case the timer is reset by the software with each cycle, rather than using it in continuous wave mode, as it is the ultimate intention to use this timer a simple one-shot time delay. Note that the clock source is selected to be TIMER_CLOCK2 (see page 850) which according to page 869 is PBC clock / 2 and more details of this clock are found in the Power Management section of the data sheet. By default PBC clock runs at the main system clock frequency (see page 63). (See the USART section of this blog on how to change the system clock settings). One thing to note with the timers is that each Timer actually has 3 channels A, B & C although only A & B can access input & output pins.) .