Unable to charge a dead battery tablet

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
JaVu_4007791
Level 1
Level 1

Brief overview of our system (Kind of Charge through Dongle application):

-          Our Cypress controlled Hub uses CYPD3125 & CYUSB 3304 & is DRP capable

-          When AC power is available: Hub will be a Source & charges tablet

-          When AC power is Not available: Tablet sources power. Hub + Devices sinks tabler power

Refer to attached image Overview.png

Issue Description:

While most of the Samsung S3 tablets with dead battery tablet are chargeable some are not chargeable. Which means we never see a voltage (Vsafe) on VBus.

Please find the attached logs (Use Teledyne Lecroy's USB Protocol Suite tool to open the CC logs).

a. Good tablet.usb: This is a log for good tablet whose battery is dead & is chargeable.

b. Bad tablet.usb: This is a log for bad tablet whose battery is dead & is NOT chargeable.

c. Bad tablet with a modified Initialization seq as below:

     dpm_update_port_config(0, PRT_ROLE_SOURCE, PRT_ROLE_SOURCE, false, TRY_SRC_TRY_SNK_DISABLED);

To

     dpm_update_port_config(0, PRT_ROLE_SOURCE, PRT_ROLE_SOURCE, false, TRY_SRC_ENABLED);

Note: We initialize the Hub as a 'PRT_ROLE_SOURCE' or 'PRT_ROLE_SINK' based on the AC power availability, instead of a 'PRT_DUAL'.

Bad tablet with modified Initialization seq.usb: This is log for this configuration.

Always configured it to SRC here, so that the Hub always presents Rp, while we see that the Tablet is always presenting Rd. The negotiation still isn't initiated.

No PD logs for the bad tablets.

Let me know if you want more information. Awaiting for your response.

Thanks & Regards

Jai Shankar

0 Likes
1 Solution

Hi Shankar,

It seems like the source did not detect any valid termination and hence did not proceed with default 5V and further PD negotiation.

I am unsure why certain tablets are behaving this way. Ideally they should be exposing RD_DB. Since we do not know the PD implementation details on Samsung tabs, it is difficult to guess what is happening here.

Regards,

Rajath

View solution in original post

0 Likes
8 Replies
RajathB_01
Moderator
Moderator
Moderator
250 replies posted 100 replies posted 50 replies posted

Hi Shankar,

Can you tell us how you are checking dead_battery operation? Is the tablet connected to hub in powered-off mode?

Can we also get voltage level waveforms on the VBUS and CC/VCONN lines?

Regards,

Rajath

0 Likes

Hi Rajath,

Yes the tablet is powered-off mode (it couldn't be switched ON as the battery is dead '0% charge') and when connected to Hub it is not chargeable by AC supply.

However the same tablet (with dead battery '0% charge') could be charged through a standard USB charger unit or when connected to PC. This way when provided 5V at 0.5 Amp for 10 seconds, the tablet is charged to a minimal level. With this minimal charge the tablet is detected & chargeable by the Hub.

But when it is completely dead battery it is not detected & not chargeable.

I can get you the voltage waveforms by tomorrow as these tablets are with our customer in US. As i said earlier very few tablets have this bad behavior of not charging among the same make and same model (Samsung S3). The one's that we have here are having good behavior.

Can i have a call with you? Just to ensure the understanding is clear and i can provide the required waveforms/logs.

Thanks & Regards,

Jai Shankar

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rajath,

Couple of more logs attached. Left (Hub) device & Right (tablet) devices are marked in the logs.

Common observations is that the tablet port is not toggling at all. USB Type-C spec talks about this in section @ 4.5.2.2.7.2 Exiting from Unattached.SRC State

"Note: The times tOnePortToggleConnect and tTwoPortToggleConnect relate to how long

toggling ports may take to sync and detect a connection."

Do you think this is the issue as only one of the port is toggling & it takes indefinite time to connect?

Thanks & Regards

Jai Shankar

0 Likes

Hi Shankar,

The tablet ports are not supposed to toggle if you are checking dead battery. This is correct behaviour.

The tablet should be exposing dead battery termination resistance on one CC line, which should make it possible for entry to attached state immediately.

I am also observing that Good_tablet_CC_logs show around 8.6 seconds of idle before connection and PD messages. This makes me believe there is something wrong with the tablet's battery management / power management system, and not on the Type-C PD system. We can confirm this looking at waveforms (to see if VBUS is being delivered upon dead-battery detection).

What is the cable you are using? Does the cable work with other devices well?

It also seems like the level of drainage of the battery could be affecting the results. I would recommend to consult Samsung and get information on behaviour of the device when you drain out the battery to 0% charge for prolonged periods.

Regards,

Rajath

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rajath,

Thanks for the reply. Voltage waveforms for the bad & good tablets are attached.

1. Yellow - Represents when AC switch ON time.

2. Blue - CC1 line

3. Magenta/pink - CC2 line

Missed out capturing VBus line, i will provide it again tomorrow.

The type-C (EMCA) cable were used mainly to connect S3 to Hub only, we do not have any other device use case to it. Behavior of the bad tablet is consistent with different type-c cables.

You mentioned that 8.6 seconds idle time before PD based on log. Do you think this is too long?

Let me know if you need more details.

Thanks & Regards

Jai Shankar

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rajath,

Please find the attached waveform of VBus vs CC1 vs CC2. 'Bad_Vbus_1Seconds.PNG' observed for 1 second & 'Bad_Vbus_4Seconds.PNG' observed for 4 seconds.

1. Yellow - DC supply derived from AC line. Just to indicate time at which AC is switched ON
2. Blue - CC1 line
3. Magenta/pink - CC2 line
4. Green - VBUS

Note: All the measurements are made at the Hub side only.

Question:

1. What does the voltage pulses on CC lines indicate (~180mV on CC1 & ~60mV on CC2) ?? These voltages are not mapping to the following voltage levels

Table 4-32 CC Voltages on Source Side – Default USB

Table 4-33 CC Voltages on Source Side – 1.5 A @ 5 V

Table 4-34 CC Voltages on Source Side – 3.0 A @ 5 V of USB type-C spec Release 1.4

Here is my understanding:

1. In the waveform it is observed that VBus line is always 0V (VBUS not detected) and hence there is no state transition from AttachedWait.SNK to Attached.SNK, this is also evident from the logs of bad tablet (where Sink never entered to Attached.SNK state).

SinkStates.png

2. The reason for source (Hub) not providing the VBUS voltage (vSafe5V) could be because AttachWait.SRC  (source) did not detect the pull down (by Sink) on CC for tCCDebounce.

Please share your analyses. Looking forward for your reply.

Thanks & Regards

Jai Shankar

0 Likes

Hi Rajath,

Waiting to hear from you, could you please expedite your reply.

Please let me know if you require any other data from me to analyze/understand the issue.

Thanks & Regards,

Jai Shankar

0 Likes

Hi Shankar,

It seems like the source did not detect any valid termination and hence did not proceed with default 5V and further PD negotiation.

I am unsure why certain tablets are behaving this way. Ideally they should be exposing RD_DB. Since we do not know the PD implementation details on Samsung tabs, it is difficult to guess what is happening here.

Regards,

Rajath

0 Likes