• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 610 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.

Original question:

TPS65987DDH: URGENT charge problems on smartphone with a dead battery

TPS65987DDK: PD unable to source power to charge a tablet via USB-C

Jacob Cayetano
Prodigy 70 points
Part Number: TPS65987DDK
Other Parts Discussed in Thread: TPS65987

We are trying to set up a battery-powered board that can be powered by an Android tablet over USB-C when the battery is disconnected, but then switch to being powered by the battery and charging the Android when it is inserted. The setup is essentially identical to the TPS65987 EVM and we have verified the hardware setup with respect to that EVM. However, the EVM and our board behave differently when loaded with the same firmware.

The EVM is able to charge the tablet when system power is provided to the chip. The tablet is also able to power the EVM when system power is not connected. Our board is not able to charge the tablet, but the tablet is able to provide power to the board via VBUS when system power is not connected.

Another wrinkle is that there appears to be different failure modes depending on the orientation of the USB-C cable. In one orientation, the board will simply continue to act as a sink when both the tablet and the battery are connected with the tablet providing 5V to VBUS. If the USB-C cable is then flipped, the VBUS line exhibits unstable behavior and appears to bounce between 0V and 5V. This indicates an issue with CC1 and CC2 as these are supposed to negotiate sourcing/sinking and are supposed to be orientation-agnostic according to my understanding of USB-C.

Our troubleshooting keeps coming back to the chip itself since the hardware and software of the EVM and our board appear identical. We have tried different cables, different boards, verified continuity, etc. Both the EVM and our board were loaded with the same firmware from the configuration GUI. We have also inspected the TPD6S300ARUKR protection IC, which appears to be working normally. I measured voltage pin-for-pin on the EVM while it was charging the tablet and compared it to voltage on our board when it was supposed to be charging the tablet. That effort is attached below. The signals were measured directly on the TPS65987DDH pins.

Controller_EVM_Pin_Voltage.xlsx

A key observable data point is that the CC signal paths have different voltages between the EVM and our board.

One hardware difference is that the EVM's chip's markings are TPS65987DDH TI 11F S399 G4 and our board's chip's markings are TPS65987DDH TI 2AF S351 G4. I'm not sure if these markings indicate a difference of revisions between the chips, but I have seen situations in which the EVM for a chip was designed around an older revision of a chip and gets obsoleted by new revisions. Since we specifically copied a known working circuit (the EVM) but are experiencing different behavior, is it possible that the documentation and EVM are out of date?

Thanks for any help you can give.

  • 0
    Prodigy 70 points

    Additional information found in debug mode:

    0x1A (status register) reads 0x20 with no cable plugged in, 0x29 with cable plugged in.

    0x1A reads either 0x0 or 0x6f when tablet is plugged in, toggles back in forth per the unstable behavior

    0x28 reads 0x1DFB6588A, bits 12:11 correspond to VCONN support and read 0b11 which is "VCONN support as Source/Sink (accept VCONN_SWAP requests)"

    0x29 reads 0x401154C2, bit 10 corresponds to VCONN swap and reads 0b1, which means PD automatically accepts VCONN_SWAP requests from far end device.

    0x69 (Type C State Register BIT Fields), byte 1 is CC Pin for PD, byte 2 is CC1 Pin State, byte 3 is CC2 Pin State, byte 4 is Type C Port State

    No cable attached: Varies between 0x66000000 and 0x67000000, means that it is varying port state between unattached.snk, unattached.src, other values mean not connected

    Cable attached (no tablet): Varies between 0x66000000 and 0x67010000, so still varying unattached states but also varying CC2 Pin State from not connected to Ra detected (source only)

    Cable and tablet attached: Varies between 0x60010201, 0x05010200, 0x64010200, and 0x65000300

    • 0x60010201: attached.src, ra detected, rd detected, cc1 is CC pin for PD comms
    • 0x05010200: ErrorRecovery, ra detected, rd detected, not connected
    • 0x64010200: attachwait.src, ra detected, rd detected, not connected
    • 0x65000300: attachwait.snk, not connected, STD advertisement detected (sink only), not connected
  • 0 in reply to Jacob Cayetano
    TI__Intellectual 2865 points

    Hello Jacob,

    I am sending a friend request to you so that you can share application configuration file, circuit schematics and/or layout of your board in private chat. 

    I request you to read following HI registers 0x03, 0x0F and 0x2D. 

    Best regards,
    Rohit. 

  • 0 in reply to Rohit Parashar
    Prodigy 70 points

    Hello Rohit,

    I am discussing with my team as to whether sharing company data is within our policy.

    In the meantime, I can share the app config file: Cayetano_TPS65987_Firmware.pjt

    Also, here are those registers:

    0x03: 0x20505041

    0x0F: 0xF7071010

    0x2D: 0x30000006a20000001c

  • 0
    Prodigy 70 points

    We have solved this issue. Our regulator was configured to only provide 9V, but USB PD spec dictates that 5V must first be negotiated between devices before changing to a different voltage. We implemented the regulator to provide 5V and 9V based on the EVM and charged the tablet successfully.

  • 0 in reply to Jacob Cayetano
    TI__Intellectual 2865 points

    Hello Jacob,

    I am happy to know that you could resolve the issue.
    If you need any further help. Please do reach out to us. 

    Thanks.