• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 34 subscribers
  • Views 448 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TCA9548A: TCA9548A switch correctly only after sending twice the same command

Dalia Russek
Prodigy 10 points
Part Number: TCA9548A

Hello, 

I have a board with 2 TCA9548A chips. One with address x70 and the other with address x71.

Im using a NI USB-8452 as the I2C Master sending the data from my application. 

The SCL and SDA pins have a pull up resistor of 4.7kOm to Vcc =3.3V

The application is very simple:

  1. Configure the slave address x70 +1 bit Write,
  2. Write a command to switch the channel. For instance, if I want to connect Channel1, I send "x1". I connected the SCL and SDA of CH1 to the scope. As you can see in the image TA CH1.jpg, the yellow signal is the SCL and the green signal is the SDA. This is the expected behavior.  
  3. Close the session and the reference.
  4. Stop application.

Problem: 

After running one time the above application, I changed the command to "x0" (No channel selected) and ran again the application. To my surprise, I see part of the above signal in the scope (see image TA Ch0 Bad). I expect to see No Signal. 

I changed back to Ch1 "x1" and run again the application. I see in the scope the expected data (TA Ch1.jpg). Now, I changed the data to "x2", ran the application and see extra data  in the scope (see image TA CH2.jpg) I expected to not see any signal. If I run again the same application with data "x2", then I don't receive any signal in the scope. This is the expected behavior. 

Note: I verified this same behavior with a different USB I2C Master from FTDI: C232HM-DDHSL.

Conclusion:

It seems I need to run twice the same application in order to "clean" the buffer , Im not sure why I need to run twice the application to behave correctly. 

  1. What could be the problem? 
  2. Is this the expected behavior?
  3. If it is a Hardware issue, what are the recommendations?
  4. Is there a command in order to clean the old data or to clean the left of the data?

Thank you in advance

Dalia

I

  • 0
    Guru 316690 points

    The datasheet says in section 8.5.4:

    When a channel is selected, the channel becomes active after a stop condition has been placed on the I²C bus.

    Do you actually generate stop conditions a tthe correct places?

  • 0
    TI__Genius 17885 points

    Hello Dalia,

    This seems to be a software issue like Celemens mentioned. Please check if the stop conditions are generated correctly, and if the issue continues. I recommend to connect the RESET pin of the TCA9548 so the system master can reset the device in the event of improper operation. Asserting a low input to the RESET pin will reset the TCA9548A.

    Thanks,

    Nir 

  • 0
    Prodigy 10 points

    Hi Clemens and Nir, 

    Thank you for the answer. 

    Using the NI USB I2C device it sends automatically the Stop bit after giving the number of bytes to write. 

    Using the FTDI C232HM I2C device I specify to send the Stop bit. 

    Using the driver it should be the stop bit, however Im not 100% if the TI chip receives it properly. Tomorrow I will double-check this point, and I will post the result of the test. 

    Regarding the RESET, the  FTDI C232HM I2C has some GPIO lines, Im considering to use one of them to control the Reset pin. 

     

    It is strange to me that if I run twice the command, it works. I will check it tomorrow, 

    Thank you and I will be back...

    Dalia

  • 0 in reply to Dalia Russek
    TI__Genius 17885 points

    Hello Dalia,

    Thank you for the reply, please keep us updated.

    Thanks,

    Nir 

  • 0 in reply to Nir Gilgur
    Prodigy 10 points

    Hi Nir and Clemens, 

    Here are some more inputs: 

    The input to the TCA9548A from the NI USB-8452 is the following: 

            

    I'm using pullup resistors of 4.7k on SCL +SDA + internal 2K resistors from the NI-USB8452. Without the internal pullup 2K resistors it doesn't look nice the signal. However, I'd also tried without the 2K internal resistors. 

    As you can see from the above images, Im sending the address x70 +0bitW, then it waits from the ACK from the slave and it sends the data "1" to connect Channel0. 

    The output looks like this: 

         

    Doing zoom the output address looks like this: 

       

     

    I ran several tests in the output and what I saw was the ACK coming from the slave changes. Sometimes comes, sometimes with a delay of 300ms, sometimes more, and sometimes less. There is a wrong behavior with the ACK coming from the slave. 

    From your experience, what could be the issue?

    Any insight will be appreciated it.

    Thank you in advance

    Dalia

  • 0 in reply to Dalia Russek
    TI__Genius 17885 points

    Hello Dalia,

    Have you tried to reset the software and resend the signal? 

    Also resetting the device using the RESET pin after a faulty ACK signal might fix its behavior. 

    Please let me know if you tried the suggestions above and keep us updated. 

    Thanks,

    Nir 

  • 0 in reply to Nir Gilgur
    Prodigy 10 points

    Hi Nir, 

    I reset the software in each run, I mean, I run the application once, not in a loop.

    Regarding the RESET pin, I will try it, but it will take time to implement it, hope this week.

    Did you see this behavior in the past? 

    Thank you for the help

    Dalia

  • 0 in reply to Dalia Russek
    TI__Genius 17885 points

    Hello Dalia,

    Understood, thank you and please keep us updated with the RESET pin implementation. 

    I can't recall if we had a similar issue with this device in the past. This is a new behavior. 

    Thanks,

    Nir