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.

TSC2007 I2C Address Configuration

Other Parts Discussed in Thread: TSC2007

We are using the TSC2007 touch controller for one of our new projects. As per the datasheet the slave address of the TSC2007 can be configured with two pins A0 and A1, We have pulled up those pins to 3.3V with a 10K resistor such that the address is 4B, but while searching on the I2C bus it shows that a slave with address of 4B is not present in the bus, instead of that a slave with address 48 is detecting ( which is equivalent to connecting the two address configuring pins A0 and A1 to ground), we have verified that the two pins are pulled high to 3.3V by probing the IC pins. Why this address mismatch occurs?? Since this occurs randomly our touch screen functionality is in trouble. Why this address change occurs? Can anyone tell me the reason?? 

Our host processor is Freescale i.Mx6Q and another slave in the same i2c3 bus with adress 18 is working fine all times. Please reply if any one have the solution..

  • Hi Nithin,

    I will take a look at this issue and get back to you soon.

    Andy
  • Dear Andy,

    The interesting thing is that, this happens randomly so that we cannot expect it all time. Since this is a part of a critical customer driven project with annual volume of 1K to 2K we have changed the address configuration pins A0 and A1 to ground and correspondingly changed the driver with address 48, now  it is working fine. But I am curious to know the reason why the above mentioned address mismatch occurs??  

    In the datasheet it is given that The A1-A0 address inputs are read whenever an address byte is received, and should be connected to the supply pin (VDD/REF) or the ground pin (GND). The slave address is latched into the TSC2007 on the falling edge of SCL after the read/write bit has been received by the slave.". We have connected the A0 and A1 pin via a 10K resistor, is there any minimum current requirement to identify the state of those pins??

  • Hi Andy,
    Any updates on the above topic?? We are facing the same issue in the current testing board also, since we have pulled up the A0 and A1 pins directly to 3.3V, we expect a slave address of 4B but out of 6 times we are getting response from the 4B address just 2 times only, in all other occasions we are getting response from the 48 slave ID. please check and let us know the is there any solution..
  • Hi, Nithin,

    The data sheet is quite clear in the section titled, "ADDRESS BYTE" that the address pins must be tied to supply (VDD/REF on the TSC2007) or ground nets.

    Try changing your 10k resistor to a zero ohm resistor, and I think you will find the device works as specified.

    -d2
  • Hi,
    As per the datasheet we have removed the pull up resistors and directly short the pins to Vcc (3.3V) in our current test board, but in this board also the random address mismatch is showing ( the same scenario is explained in the above comment in which out of 6 attempts only 2 times we have received the response from the 4B slave ID and in all other trials we are receiving the acknowledgment from 48 only. ) In the current test application we are reading the full 4x ( x from 8 to B)slave IDs to check which address is currently configured. We are keeping the hardware as such in all the trials but the address configured is changing randomly.
  • Hi, Nithin,

    When you tied the address pins to 3.3V, is this the same 3.3V net feeding VDD/REF on the TSC2007?

    -d2
  • yes the same 3.3V is connected to the A0 and A1 pins.
  • Hi, Nithin,

    So, hard tied to VDD/REF on the TSC2007 results in random behavior, but hard tied to ground works ok?

    On how many units have you experienced this behavior?

    -d2
  • We have tested in 2 of our target board and found that in both of the boards the TSC2007 is showing the random behavior. The I2C lines are pulled up with a 2.2K pull up resistor to same 3.3V rail. Is there any significance in I2C clock speed with this address configuration??
  • Hi Nithin,

    Could you show me the circuits around the TSC2007?

    Now I'm trying to duplicate your issue using a TSC2007 EVM board in my office.

    Andy
  • Hi Nithin,

    I have done some experiments, trying to duplicate your issue in my office. Unfortunately, I couldn't find any i2c issue after changing the i2c address to 0x4B.

    Here is how I duplicated your issue in the lab.
    a) I pulled up the pin A0 and A1 of a TSC2007EVM board to 3.3V with a 9.1k resistor. The actual i2c address became 0x4B instead of 0x48.
    b) I attached a Cortex-M3 MCU board to the TSC2007 EVM and connected a fixed resistor network to the 4 analog inputs of TSC2007 to simulate a constant touch, which caused the PENIRQ pin to stay low forever.
    b) Then I launched the reference firmware for TSC2007. The firmware kept reading data via i2c with a 400k clock from the tsc2007 device.
    c) The firmware was running for over 15 mins. No i2c error ever occurred.

    Did you ever try capturing the waveforms on the SCL and SDA pins using a scope? If not, I suggest you do so to help debug this issue.

    Andy

  • Dear andy,

    I have attached the schematic of the touch controller section here,

  • Hi Nithin,

    I have not found any obvious issue on the schematic. In addition, I assume the SCL and SDA pins are pulled up to 3.3V by some resistors, right?

    Have you found any TSC2007 device so far that could work well without this i2c address issue?

    Andy
  • Yes we have pulled up the SCL and SDA lines to 3.3V via a 2.2K resistor in our board.
  • we are operating the I2C bus in standard operating mode, ie 100 KHz clock is there any dependency on it??
  • Hi Nithin,

    No, I don't think so. As you can find in the datasheet, TSC2007 supports all three i2c modes: standard, fast and high-speed.

    In addition, I just tried the 100k i2c clock using a TSC2007 EVM board with the A0 and A1 both pulled to 3.3V and didn't find any i2c issue.

    Andy
  • Hi Nithin,

    Could you tell me the LOC (lot trace code) of the failing units? It will be better if you can show me the photos of these bad units so I can see the LOC by myself.

    Andy

  • Hi Andy Lui,

    We have done a series of testing in our board for evaluating the address switching issue, and our observation are listed below please check if these observations makes any sense

    1.Initially we have connected the TSC2007 and its address configuring pins to a 3.3V rail with a rise time of around 1 ms, during this testing we observed the random switching of Address from 4B ( as per hardware configuration) to 48, also sometimes the I2C bus get hanged during the power ON time( during this time the SDA line is below low). So we modified the circuit to give provision to RESET the TSC2007 while the I2C Bus is down with a P Channel MOSFET, but surprisingly we couldn't  able to reproduce the issue with this set up, so we have verified the switch on time of the MOSFET and is found to be around 250 uS.

    2. So we changed the power rail to an another voltage rail with rise time of around 100 us and this time also we couldn't able to reproduce the issue, so we could you please confirm is there any dependency in rise of the voltage rail connecting to VCC and address configuring pins of TSC2007. In the datasheet it is mentioned that the TSC2007 will automatically initiate a Power ON Reset once  power is on, so could you please look in to this observation and confirm if there is any dependency with address switch??

     

  • Did you measure the voltages on SCL and SDA, are they not greater than Vdd+0.3V and supplying the TSC?

    Using 2K2 pull-up resistors it looks like you have a long (capacitive) bus, did you try series resistors between TSC and the SCL and SDA bus-signals to protect against high voltage spikes? With 2K2 pull-up they should be between ~100-200R.
  • Hi Nithin,

    One of the most common issues on TSC2007 is the POR issue. TSC2007 has some requirements on the POR timing, which could be found on Page 31 of its datasheet.   Based on your testing and observations, I believe the root cause of the i2c address should be the improper POR timing.

    Below is a link to an application note, which explains this POR issue in details. 

    www.ti.com/.../sbaa161.pdf

      

    Andy