Guide for Timer-based Driven Shield on SAM Devices for Atmel START QTouch Library
Driven Shield is an essential feature to ensure robust moisture tolerance. The Peripheral Touch Controller (PTC) on certain SAM devices does not support the driven shield feature. However, it is possible to implement a driven shield on those devices using PWM output from timers. This article provides details on how to use timers to set up a driven shield and configure such a project using Atmel® START.
Using Timer (TC/TCC) as PWM
The purpose of a driven shield is to generate a synchronous signal on the shield pin, like a Y-line bursting signal (capacitance measurement waveform). The PTC generates three-level waveforms on Y-lines. These waveforms typically have voltages GND, VCC, and VCC divided by two (VCC/2). To have robust moisture performance, it is enough to generate a two-level signal which is in sync with the PTC Y-line signal.
Here is a typical waveform for a self-capacitance sensor, along with a driven shield signal. Refer to the synchronous points: Sync A and Sync B. It is acceptable to have less than 1 microsecond offset for Sync A. Sync B should be perfectly synchronized.
Hardware Design Guidelines
The shield waveform from TC/TCC causes a mutual capacitance effect between the shield and the sensor. Due to this mutual capacitance, the overall sensor capacitance value observed by PTC will be significantly less. To compensate for this significant reduction, the sensor should have the ground shield on the bottom layer as shown in the accompanying image.
- The sensor is on the top layer, surrounded by solid driven shield.
- Hatched ground shield is present on the bottom layer, covering both the sensor and driven shield.
- Ensure that the gap between the sensor and shield on the top layer is 0.5 mm ~ 1 mm.
An alternate option to reduce the coupling between the shield and the sensor is to have a guard ring (connected to the Driven Shield pin) surrounding the sensors as shown in the accompanying image.
- Ensure that the gap between sensor and shield is 2 mm.
- Since the shield is not present all over the PCB, other signals need to be routed far away from the sensors such that water does not bridge.
- The shield can act as an antenna if it is closed loop. Ensure that a cut is provided as shown to avoid a closed loop.
Driven Shield Operation
To implement driven shield using timers, the following resources will be used:
- DMA: 1 channel
- Event system: 1 channel
- TC/TCC: as required
This flow diagram represents the typical control when driven shield is NOT used.
This diagram represents the flow control when driven shield is used.
The driven shield is effective only when the shield signal is synchronous to the PTC Y-line waveform. In order to ensure that the clock difference between PTC and CPU does not affect this synchronization, the shield and PTC waveforms need to be triggered by the PTC itself. This is done by using the event system of SAM devices.
The PTC and shield signals are started by DMA instead of PTC. This is fine as the DMA is started by PTC without CPU intervention.
Driven Shield+
In driven shield, the shield output is routed only to the dedicated shield present on the PCB. When measuring one sensor, all other sensors will be grounded. In this case, when moisture bridges between the sensor and shield, it does not cause false detection. When moisture bridges between two sensors, it may cause false detection.
In Driven Shield+, when measuring one sensor, all other sensors will act as driven shields. Even when moisture bridges between two sensors, it does not cause false detection.
It is possible to implement Driven Shield+ using TC/TCC. In order to do this, the Y-lines connected to the sensor should have a multiplexing option for TC/TCC. It is possible to identify such Y-lines from the device datasheet. Here is an example from the SAMC21 datasheet.
- To have an effective Driven Shield+ solution, all the Y-lines need to have the multiplexing option for TC/TCC.
- It is OK to have Y-lines multiplexed with different TC/TCCs.
Optimizing Y-Line Selection
TC/TCCs are additional resources used to achieve the driven shield or Driven Shield+ feature. Optimization needs to be done on selecting the Y-lines so that the number of TC/TCC used is less. This is required because:
- with the increase in the number of TC/TCCs, the power consumption will also increase, and
- the number of TC/TCCs available for application will be less.
Scenario 1: One Timer Vs Multiple Timers
To use the Driven Shield+ feature on Y20~Y23 lines, there are two options available:
Option 1: Use TC2 and TC3. (Two TCs)
Option 2: Use TCC1. (One TCC)
Option 2 is optimal as it requires only one timer resource. If the application needs TCC and can spare two TCs, then Option 1 can be used.
Scenario 2: Maximum Y-line for One Timer
From the above information, with just TCC0, it is possible to configure Driven Shield+ for six Y-lines. Select the Timer/Y-line so that maximum Y-lines are covered within the same timer.
Scenario 3: Only One Timer Option
These Y-lines do have only one timer option. If these Y-lines are used and the Driven Shield+ feature is required, then these TCs must be used.
Scenario 4: Y-lines without Timer Option
There are cases where Y-lines do not have any multiplexing option for TC/TCC. For example, in the SAMC2x, Y0 and Y1 (and some additional Y-lines) do not have the multiplexing option for any timer. These Y-lines cannot be driven as a shield when other Y-lines are being measured.
When water bridges between these Y-line (sensors) and other sensors, false detection can occur. To avoid such false detection, the gap between the sensors should be greater. This gives better moisture tolerance in the following ways.
- Since the gap is greater, water does not easily bridge between sensors.
- Since sensor-to-shield coupling is greater and compared to that of adjacent sensors, the effect due to adjacent sensors is less compared to sensors placed closer to each other.
If some of the Y-lines have multiplexing options for TC/TCC and some do not:
- Ensure that they are physically separated, and
- increase the gap between the sensors where adjacent driving is not possible.
Configuring Driven Shield in START
After configuring the pins for touch sensors, go to the Driven Shield tab.
The option to enable Dedicated Driven Shield and Driven Shield+ will be available.
Click on Enable Dedicated Driven Shield and select the timer and shield pin which is connected to the dedicated driven shield.
Change the timer instance and select the desired pins.
Note: If the required pins are not displayed, either the correct timer instance is not selected or that pin does not have the multiplexing option for TC/TCC.
If the Driven Shield+ feature is needed, click on the Enable Driven Shield Plus option.
It lists the total number of channels with a drop-down menu for each channel as shown.
The channels' pins are assigned as follows.
From the device datasheet, these pins have two timer options as shown.
Click on the drop-down menu and you will find the available timers for each channel. Select the desired timer as per the application requirement. Any timer will work for touch. Refer to the "Optimizing Y-line Selection" section above for optimal timer selection.
Similarly, select the timer for other channels.
If some of the Y-lines do not have a timer option, leave them as they are. Now the driven shield configuration is complete.
Tuning the Driven Shield
Though care is taken to ensure that the project generated from Atmel START works without any modification, at times it may be required to fine-tune the timings of the shield signal by adjusting TC/TCC parameters.
The complete configuration of TC/TCC timings is implemented in the driven_shield.c file. By modifying a few parameters, you can adjust the timings.
After programming the device, ensure that the shield signal is in sync with each channel’s PTC waveform. Refer to the first section of this article for the example waveform.
Drastic Change in Period/Frequency of Shield Signal
The period value is calculated depending on the CSD and burst frequency options. If the calculated period value is more than 255, then the value is scaled down to half and the timer prescaler value is increased to maintain proper timing.
However, as shown in the accompanying figure, the prescaler value of TC/TCC is not linear beyond DIV16. So, if the period value is too high and to bring it down to 8-bit we keep increasing the prescaler, at one point it may not generate synchronous signal.
To avoid this issue, do not increase both CSD and prescaler; either increase CSD or PTC prescaler. The default values are tested for a CSD value of up to 31 with prescaler one.
Even with just increasing the CSD, if the prescaler is more than four, you may need to additionally scale down the timer values as per the division factor.
Example: If the period value is five, then actual timer calculations assume that the division is 32. But the actual division is going to be 64. So, you need to divide the timer values by two again as shown.
period = period >> 1; count = count >> 1; cc = cc >> 1;
Minor variations
If there are minor offsets in the timings, it can be adjusted by adding or subtracting one from the period, cc, and count values before the following while loop in the driven_shield.c file.
Function: drivenshield_start()
/* !!! do changes to period, cc and count values here !!! */
while (period > 255) {
prescaler = prescaler + 1;
period = period >> 1;
cc = cc >> 1;
count = count >> 1;
}
Note: For SAMD21, SAMDA1, and SAMHA1 devices, depending on the CPU clock frequency, minor changes need to be done in the "count" value. If the CPU clock is less than 24 MHz and after the end of above-said while() loop, the "count" needs to be increased or reduced to adjust the shield to be in sync with the PTC waveform.
Driven Shield operation with multiple interrupts
In timer-based Driven Shield projects, two PTC interrupt occurs within a short interval for each channel. The time duration between the first and second interrupt is very short. For both these interrupts, the PTC ISR PTC_Handler() function should be executed. Otherwise, the touch may not work correctly.
If multiple interrupts are triggered simultaneously by other peripherals there is a possibility that the PTC ISR is not executed for the first PTC interrupt. This could potentially stop the touch operation.
If multiple interrupts are using in the application, ensure that the PTC interrupt priority is more than that of other peripheral's interrupt. This ensures that both PTC interrupts are executed.
