• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 485 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.

TUSB322I: Proper way to detect port attachment and detachment and VCONN overcurrent

Pengzhao Zhu
Genius 11385 points
Part Number: TUSB322I
Other Parts Discussed in Thread: TUSB322, TUSB320

Hi experts,

I have 2 questions.

If am using the TUSB322I on a prototype on the I2C bus.

1. May I ask what is the proper way to detect attach and detach of the USB C port using this part? Currently, I am triggering the MCU on the INT_N pin and checking "ATTACHED_STATE" field (bits 7-6) of register 0x09.

2. So I am doing number 1 (trigger I2C communication using INT_N, and then check "ATTACHED_STATE". However, once in a while, after I unplug it, "ATTACHED_STATE" would still read ATTACHED_SRC and VCONN_FAULT is also occurred. This then messed up the logic for my code. Please see waveforms attached:

CH1= INT_N, CH2 = VBUS, CH3 = SDA, CH4 = SCL

Normal Cycle (expected behavior)

 A quick type C port plug-in and unplug, VBUS comes up and down as expected


After the unplug, interrupt occurred and I read register 0x09. ATTACHED_STATE IS not attached which is expected. The 9 bits on the screenshot is 8 data bits read from 0x09 plus the NACK bit. So the read from 0x09 is 0b00110000.


Fault Cycle (unexpected behavior)
A quick type C port plug-in and unplug, VBUS comes up but doesn't go down because 0x09 communication is not as expected.

After the unplug, interrupt occurred and I read register 0x09. ATTACHED_STATE is still ATTACHED_SRC which is not what I expect. The 9 bits on the screenshot is 8 data bits read from 0x09 plus the NACK bit. So the read from 0x09 is 0b01111000. Because I read ATTACHED_SRC, the sequential I2C commands from the MCU is not correct and my VBUS rail never went down.

It could just be my hardware setup as I am modifying multiple EVMs (including the TUSB322I) to test the prototype instead of using a customized PCB. However, I do want to know what could be the potential cause of this issue. There seem to be a timing issue when the TUSB322I is detecting the detach.

Thanks,

Peng

  • 0
    TI__Guru*** 146055 points

    1: can you mark in waveform signal vs different color?

    2: you need to clear INT_status bit everytime a register changes. write 1 to clear this bit

  • 0 in reply to Brian Zhou
    TI__Genius 11385 points

    Hi Brian,

    1. The signal vs color are in the bottom left of the screenshot. It is also here:



    CH1= INT_N, CH2 = VBUS, CH3 = SDA, CH4 = SCL


    2. Yes, I did, otherwise the interrupt pin still stay low the entire time.

    I noticed that I was using an active cable. So I did not use the cable and just manually connect one of the the CC (on the source side and the sink side) pin together. In this case, there would be no "Ra" and only "Rd" is present. So far I don't see this problem any more (500 cycles) so I think it is because the VCONN overcurrent.

    Why would VCONN overcurrent? I modified the TUSB322I EVM and used a standard USB C cable.

    Thanks,

    Peng

  • 0 in reply to Pengzhao Zhu
    TI__Guru*** 146055 points

    what is current mode? can you start with lower current mode and try again?

  • 0 in reply to Brian Zhou
    TI__Genius 11385 points

    Hi Brian,

    May I ask why would current mode matter? 

    Sometime it occurs on default current mode as well. For example, I had the system (1st TUSB322) detect an unpowered TUSB322 (dead battery mode, 2nd TUSB322) and it would occur once in a while (although it is less frequent). When I did this test on an unpowered TUSB322, the system is not actually delivering any power as I was just testing the control logic so I don't think the current mode matters.

    I am more interested in knowing what would cause VCONN to overcurrent. VCONN is powered off the 5 V on the computer USB port. I do not actually need this feature.

    I used this cable:

    https://www.digikey.com/en/products/detail/jae-electronics/DX07518S10N18747/7784253 

    Thanks,

    Peng

  • 0 in reply to Pengzhao Zhu
    TI__Guru*** 146055 points

    do you need DIR? if not you can try TUSB320, it doesn't support VCONN and we can see if it's VCONN issue or timing issue

  • 0 in reply to Brian Zhou
    TI__Genius 11385 points

    Hi Brian,

    This is just a prototype to demonstrate that the TUSB322 and the BQ Chargers can work well together for the major Type C power functions. We picked TUSB322 after some discussions with Malik earlier in the year as it has DIR to support USB 3.1. I didn't need DIR or VCONN in my testing, but our customers will probably do.

    My setup does consist of a lot of board reworks in both the tester circuit as well as the DUT. As I didn't find any issue last Friday if I just do a direct CC (source) to CC (sink) and it seems like it is not a quick answer from you guys, I think we can close the ticket. 

    If I have more questions in the future, I will come back to E2E and link this post.

    Thanks,

    Peng