Guide for Timer-based Driven Shield on SAM Devices

Driven shield is an essential feature to have 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.

Figure 1 shows 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.

Figure 1

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 Figure 2.

  • 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.
Figure 2

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 below.

  • 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 in Figure 3 to avoid a closed loop.
Figure 3

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

Figure 4 represents the typical control when driven shield is NOT used.

Figure 4

Figure 5 represents the flow control when driven shield is used.

Figure 5

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.

In Figure 5, 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.

Figure 6
  • 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

Figure 7

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

Figure 8

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

Figure 9

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.
Figure 10

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.

Figure 11

Change the timer instance and select the desired pins.

Figure 12

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.

Figure 13

It lists the total number of channels with a drop-down menu for each channel as shown in Figure 14.

Figure 14

The channels' pins are assigned as follows.

Figure 15

From the device datasheet, these pins have two timer options as shown in Figure 16.

Figure 16

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.

Figure 17

Similarly, select the timer for other channels.

Figure 18

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 Figure 19, 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.

Figure 19

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 below.

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;
© 2019 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.