AM3352 4-wire touchscreen

What is the capacitors value? LC filters are not recommended on the TSC lines.

Initially we had ferrite in the lines. We observed some unwanted interrupts from these lines. Assumed penup interrupts. Hence added a 10nF capacitor on all lines. This avoids the issue to an extent.

Try removing both ferrites and capacitors.

We have nearly 30-40 cm length for touchscreen cable. That why we placed bead on these lines.

This cable is too long. Sorry, I cannot help.

We have reduced the cable length to 5cm . Still the issue exists..

You should check if your ADC power supply isn't too noisy. Do you have a ferrite bead on VDDA_ADC? Also VSSA_ADC should be separated from common ground. They should be connected in one place only via a ferrite bead. Check how ADC power supply and reference voltages are implemented on the AM335X EVM boards: http://processors.wiki.ti.com/index.php/AM335xBoards

It is not at all noisy. We have placed beads on both ADC supply and ground .

Then it must be either a case of faulty or out of specs touchscreen, or noise being coupled into the TS lines from other sources.

Well, touchscreen is a resistive load and ferrite adds more or less some inductivity factor, changing current rise/fall times. Same is valid for capacitors, but they change voltage rise/fall times.

Thank you Biser.

One more thing, currently we are using ADC clk of 24MHZ. Im a hardware engineer and little idea about the driver side. I need to change the clk to kHZ range. Is it software configurable? If so, by which register?

Unfortunately I'm also a HW engineer and don't know the answer. If you are using the Linux SDK this should be already configured.

Ok Biser. Let me go through TRM :)

Why do you need to change the clk to kHz range?  I assume you need to do this to decrease the ADC sample rate.

My reply below is from the hardware perspective.  I cannot comment how this is done in various software drivers.

Increasing the value of the ADC_CLKDIV register decreases the frequency of ADC_CLK. This is one way to decrease the ADC sample rate. ADC_CLK is sourced from OSC0 which is normally connected to a 24MHz crystal.

The FSM sequencer in the ADC provides two programmable delays for each step. Open Delay is used to control when the acquisition begins after the step starts and Sample Delay is used to control the acquisition period. Delays for each of the 16 steps can be configured independently via the respective STEPDELAYx register. Open Delay defaults to a value of zero which causes the acquisition period to begin as soon as the step starts. The start of the acquisition period can be delayed one ADC_CLK clock period for each incremental value of Open Delay. Sample Delay defaults to a value of zero which causes the acquisition period to be equal to two ADC_CLK clock periods. The acquisition period can be extended one ADC_CLK clock for each incremental value of Sample Delay.

The maximum sample rate for the ADC is 200ksps and it takes at least 2 ADC_CLK cycles to perform an acquisition and 13 ADC_CLK cycles to convert the acquired voltage to a digital value. This will allow the ADC to sample a single analog input at 200ksps if ADC_CLKDIV is configured to provide a 3MHz ADC_CLK and the values of Open Delay and Sample Delay are both zero.  So increasing the value of Open Delay and Sample Delay can also be used to reduce the ADC sample rate.

Regards,
Paul

uhtis said:

Used linux 3.12. Applied TI patch for avoiding the frequent penup interrupts. 

What's your software baseline and which patch have you applied?

Try using SDK 7.00 and apply the patches from here:

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/319613/1308705.aspx#1308705

Related to false pen-up interrupts you may need to make one further adjustment beyond what's in those patches.  In particular you should edit drivers/input/touchscreen/ti_am335x_tsc.c and change this line (from my patched code)

-    titsc_writel(ts_dev, REG_CHARGEDELAY, 0x400);
+    titsc_writel(ts_dev, REG_CHARGEDELAY, 0xB000);

Just to be clear, if you are not using my complete patch set from the post I mentioned, this change will be meaningless.  You need all of the changes working together.

Using V2 patches of SDK7.0 . Let me check with these delay values.