This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/TSC2003: erroneous X coordinate

Part Number: TSC2003
Other Parts Discussed in Thread: TSC2007

Tool/software: Linux

Hi everybody

We designed custom hardware including the TSC2003 controller. We are dealing with the following problem. Occasionally, the TSC2003 reports an erroneous press. When this happens, the X coordinate is wrong, while the Y coordinate is correct.

We noticed that when the reported X coordinate is erroneous, the z1 value is 0. This is the code that implements the conversions following a touch event.

    /* y- still on; turn on only y+ (and ADC) */
    tsc2007_xfer(tsc, ACTIVATE_YN);
    tc->y = tsc2007_xfer(tsc, READ_Y);

    /* turn y- off, x+ on, then leave in lowpower */
    tsc2007_xfer(tsc, ACTIVATE_XN);
    tc->x = tsc2007_xfer(tsc, READ_X);

    /* turn y+ off, x- on; we'll use formula #1 */
    tsc2007_xfer(tsc, ACTIVATE_YP_XN);
    tc->z1 = tsc2007_xfer(tsc, READ_Z1);
    tc->z2 = tsc2007_xfer(tsc, READ_Z2);

    /* Prepare for next touch reading - power down ADC, enable PENIRQ */
    tsc2007_xfer(tsc, PWRDOWN);

If we understand correctly, z1=0 is inconsistent in the sense that z1 should never be 0. Is it possible that z1=0 is due to a hardware problem? In general, what could explain such an inconsistent value?

Thank you in advance.

  • Hello,
    It is possible for the Z value to be zero, but it seems unlikely this would also coincide with having erroneous X/Y values. Have you tried probing the SCL/SDA pins of the TSC2003 to determine if the I2C communication looks correct? Basically, is the device putting out all zeroes, or is the controller registering all zeros?
  • Hi Collin,

    we'll try to capture the I2C transaction associated with the z1 conversion. However, we think that if we had a problem related to the I2C bus, it would probably affect the other conversions as well.


  • Hi Collin,

    we managed to capture the I2C transaction we talked about. The TSC2003's conversion result is actually z1=0. Please see the following image.


  • Hi Andrea,

    Thanks for sharing the scope capture. The communication looks proper and you're waiting more than the requested 10us before beginning to read the conversion so that looks proper.

    When things look proper but aren't working right we like to verify the basics. Can you confirm the schematic connections to the TSC2003? Have you used a local decoupling capacitor directly at the V+ pin of the device? Are there any input filters applied to the inputs to reduce possible interference from noise generators in the system?
  • Collin,

    attached you can find the schematic diagram related to the TSC2003.

    We have used this circuit in several products successfully. We can't exclude a design error, however (for example a poor PCB layout in the TSC2003 area).

    C1211, C1212, C1213, and C1214 are optional capacitors that we use to fine-tune the resistive membrane interface. We have tried different values but we have gotten no significative improvements.

    When you say V+, do you refer to the pin #1 or to the pin #9?

  • Hi Andrea,

    Thanks for sharing. I was referring to V+ but the same applies when applying an external VREF voltage. The 100nF capacitors will result in a delayed settling time of the analog inputs but this can be overcome based on the sampling rate. Have you tried removing them all together to see if the behavior resolves? Otherwise, I'm not sure it will make a difference but if you remove the L1202 inductor and replace it with a 1-10R resistor does the issue get resolved?

    Also, if you switch the orders of your reads around does the erroneous channel follow? If that doesn't help then can you confirm if this behavior is present on one or multiple boards? If it's only on one board, does reflowing the board or swapping the unit reduce the behavior?
  • Hi Andrea,

    Any updates?
  • Hi Collin,
    we implemented a software workaround at driver level that makes the touch screen usable. Our customer approved this implementation.
    I think we will investigate this issue further, however, in order to figure out the root cause.

    Thank you,
  • Hello Andrea,

    Thank you for sharing. Can you provide any details regarding the update? Did you add delays, change the measurement order?
  • Hi,

    the workaround is very simple: when z1==0, the event is discarded.