USB Charging / Device Powering

Hi Pev,

Please try the following,

For enabling the charging the user will need to set the BCIAUTOUSB bit to ‘1’. Also the OTG_EN bit needs to be set to ‘1’ 50msec prior to setting BCIMFSTS4[USBFASTMCHG] bit to  ‘1’. The charging current by default is set for 600mA

Regards,

Gandhar.

Hi Gandhar,

  I'm not sure I understand your reply - I'm already setting the BCIAUTOUSB bit as you can see in the debug I posted above. I was under the impression from the TRM that this puts the chargers state machine into automatic/hardware mode? Do I need to set OTG_EN / USBFASTMCHG as well to initiate charging? 

Cheers,

~Pev

Hi Gandhar,

I know it's bad for to reply to myself, but...! :-) I just re-read the new errata (SWCZ001B / October 2009) and I see that there is in fact a note that I don't think I've seen before about BCI charging and USB that looks similar but in greater detail, note 7 "BCI: USB charge stopped by BCI watchdog" Is this what you're referring to? If so I think we might have a problem in our design.

We wished to be able to charge the battery when the device is not powered on. I was under the impression from section 7.4.1.1.1 of the TRM that putting >140K on the BCIAUTO line would allow us to do this. Given that the workaround is in software does this mean that this will not be possible with the current silicon revision?

On the topic of revisions, how should we work out TPS65950 silicon revisions? The TRM mentions ES1.0 and the errata gives no specifics relating issues to revisions so I assume that all issues relate to the current revision... However ISTR that I've seen references to ES1.1 revision as well. Do we have any timescales as to when issues are likely to be addressed? I also notice the PWRON issue (22) has no workaround so would require a silicon fix.

Cheers,

~Pev

Hi Gandhar,

  I've tried this setup and it still doesn't work. On boot my (pseudo)code does the following :

    data = READ_TPS(BCIMFEN4)
    data &= ~(WATCHDOGEN)
    WRITE_TPS(BCIMFEN4, data)

    data = OTG_EN;
    WRITE_TPS(POWER_CTRL_SET, data)
    // Wait  50ms

    data = READ_TPS(BCIMFSTS4)
    data |= USBFASTMCHG
    WRITE_TPS(BCIMFSTS4, data)

    data = READ_TPS(BOOT_BCI)
    data &= ~BCIAUTOAC
    data |= BCIAUTOWEN | CONFIG_DONE | BCIAUTOUSB
    WRITE_TPS(BOOT_BCI, data)

At this point I've changed my code to poll the BCIMSTATEC register and the dump interesting registers if the state changes. If I start with the USB connected to a charger, the following debug is observed :

 BOOT_BCI currently 0x35

 Clearing BCIMFEN4:WATCHDOGEN

 Setting POWER_CTRL_SET:OTG_EN

 Setting BCIMFSTS4:USBFASTMCHG

 Setting CONFIG_DONE, BCIAUTOAC and BCIAUTOUSB in BOOT_BCI

 Dump of interesting BCI regs :
 *** BCI State change to 0x12 (prev 0x00)
 BOOT_BCI ............ 0x36

 BCIMDEN ............. 0x11
 POWER_CTRL .......... 0x00
 STS_HW_CONDITIONS ... 0xc0

 BCIMSTATEC .......... 0x12
 BCIMSTATEP .......... 0x02
 BCIVBAT ............. 0x0001
 BCITBAT ............. 0x0000
 BCIICHG ............. 0x0000
 BCIVAC .............. 0x0000
 BCIVBUS ............. 0x0000
 BCIMFSTS2 ........... 0x80
 BCIMFSTS3 ........... 0x40
 BCIMFSTS4 ........... 0xf0
 BCICTL1 ............. 0x00
 BCICTL2 ............. 0x00
 *** BCI State change to 0x00 (prev 0x12)
 BOOT_BCI ............ 0x36

 BCIMDEN ............. 0x00
 POWER_CTRL .......... 0x00
 STS_HW_CONDITIONS ... 0xc0

 BCIMSTATEC .......... 0x00
 BCIMSTATEP .......... 0x00
 BCIVBAT ............. 0x0001
 BCITBAT ............. 0x0000
 BCIICHG ............. 0x0000
 BCIVAC .............. 0x0000
 BCIVBUS ............. 0x0000
 BCIMFSTS2 ........... 0x80
 BCIMFSTS3 ........... 0x40
 BCIMFSTS4 ........... 0xf0
 BCICTL1 ............. 0x00
 BCICTL2 ............. 0x00

Note that the state change happens very quickly - milliseconds I guess. So it starts off in charge mode then stops very fast, and disables BCIMDEN:USBPATHEN.

I also note that BCIVBAT and BCITBAT are reported as zero. Should this be the case? I would have thought that these would have been measured OK to have made it to USB Quick Charge 1 in the first place?

Thanks,

~Pev

I've just discovered what's probably going on ; I've added BCIMFEN4 to my regs that I dump. If I dump it before and after clearing the WDEN bit, the watchdog bit stays enabled. This is obviously the cause of the problem. Is there a way I can actually turn the watchdog off? I'd guess there may be a protection key somewhere but I can't find any documentation for it.

~Pev

You can turn the watchdog OFF by writing 0x33 and then 0xF3 to the BCIWDKEY. However, what you explain may happen when you are using USB manual charging mode. From your explanation it looks like you are using USB automatic mode.

For USB automatic mode the OTG_EN and USBFASTMCHG bit setting should be sufficient. Please have a look at this post and use the settings mentioned here - http://e2e.ti.com/forums/p/3265/12036.aspx#12036

Let me know if this helps.

Regards,

Gandhar.

Hi Gandhar,

   I wasn't intending to use software charging, just automatic charging. I've tried the above change to use the two WDKEY values in sequence but still after writing I read back WDEN=1.

  I looked at the other link you sent and modified my code to dump GPBR1 as well. This was definately being cleared. After re-setting to 0x90 it appears that the MADC is automatically reading values for BCIVBAT, BCITBAT, BCIICHG, BCIVAC and BCIVBUS.

So, my pseudocode now looks like :

CLEAR BOOT_BCI:BCIAUTOAC
SET BOOT_BCI:BCIAUTOWEN, BOOT_BCI:CONFIG_DONE, BOOT_BCI:BCIAUTOUSB
SET GPBR1 = 0x90
// DUMP INTERESTING REGISTERS
SET POWER_CTRL_SET  = OTG_EN
SET BCIMFKEY = 0x6D
CLEAR BCIMFTH3:ITBCIGROUP
SET BCIMFTH3:ACCHGOVTH = 0x01
SET BCIMFSTS4:USBFASTMCHG
SET BCIWDKEY = BCIWDKEY6
SET BCIWDKEY = BCIWDKEY5
SET BCIMFEN4 = 0x60
// DUMP INTERESTING REGISTERS
// CHECK FOR CHANGES IN STATEC AND DUMP REGS ON CHANGE

If I run this on our device with USB charger plugged in with a battery it reports :

 BOOT_BCI currently 0x35
 Setting CONFIG_DONE and BCIAUTOUSB in BOOT_BCI
 Re-Setting GPBR1

 Dumping interesting BCI regs :
 BCI (and related) registers at this point :
    GPBR1 ............... 0x90
    BOOT_BCI ............ 0x36
    BCIMDEN ............. 0x00
    POWER_CTRL .......... 0x00
    STS_HW_CONDITIONS ... 0xc0
    BCIMSTATEC .......... 0x00
    BCIMSTATEP .......... 0x00
    BCIVBAT ............. 0x0001
    BCITBAT ............. 0x0000
    BCIICHG ............. 0x0000
    BCIVAC .............. 0x0000
    BCIVBUS ............. 0x0000
    BCIMFSTS2 ........... 0x80
    BCIMFSTS3 ........... 0x40
    BCIMFSTS4 ........... 0xf0
    BCIMFEN1 ............ 0x00
    BCIMFEN2 ............ 0x00
    BCIMFEN3 ............ 0x00
    BCIMFEN4 ............ 0x68
    BCIWD .,,............ 0x02
    BCICTL1 ............. 0x00
    BCICTL2 ............. 0x00

 Doing TPS BCI Errata workaround...
 Setting POWER_CTRL_SET:OTG_EN
 Setting BCIMFTH3
 Setting BCIMFSTS4:USBFASTMCHG
    BCIMFEN4 ............ 0x6f
 Clearing BCIMFEN4:WATCHDOGEN
    BCIMFEN4 ............ 0x6f
 Dump of interesting BCI regs (after BCI errrata bodge):
 BCI (and related) registers at this point :
    GPBR1 ............... 0x90
    BOOT_BCI ............ 0x36
    BCIMDEN ............. 0x11
    POWER_CTRL .......... 0x00
    STS_HW_CONDITIONS ... 0xc0
    BCIMSTATEC .......... 0x12
    BCIMSTATEP .......... 0x02
    BCIVBAT ............. 0x020c
    BCITBAT ............. 0x0053
    BCIICHG ............. 0x0209
    BCIVAC .............. 0x0000
    BCIVBUS ............. 0x00e9
    BCIMFSTS2 ........... 0x80
    BCIMFSTS3 ........... 0x40
    BCIMFSTS4 ........... 0xf0
    BCIMFEN1 ............ 0x00
    BCIMFEN2 ............ 0x00
    BCIMFEN3 ............ 0x00
    BCIMFEN4 ............ 0x68
    BCIWD .,,............ 0x02
    BCICTL1 ............. 0x00
    BCICTL2 ............. 0x00

 Polling for status changes...

 ***** BCI State change to 0x00 (prev 0x12) *****
 BCI (and related) registers at this point :
    GPBR1 ............... 0x90
    BOOT_BCI ............ 0x36
    BCIMDEN ............. 0x00
    POWER_CTRL .......... 0x00
    STS_HW_CONDITIONS ... 0xc0
    BCIMSTATEC .......... 0x00
    BCIMSTATEP .......... 0x12
    BCIVBAT ............. 0x020f
    BCITBAT ............. 0x004e
    BCIICHG ............. 0x0243
    BCIVAC .............. 0x0000
    BCIVBUS ............. 0x00e9
    BCIMFSTS2 ........... 0x80
    BCIMFSTS3 ........... 0x40
    BCIMFSTS4 ........... 0xf0
    BCIMFEN1 ............ 0x00
    BCIMFEN2 ............ 0x00
    BCIMFEN3 ............ 0x00
    BCIMFEN4 ............ 0x68
    BCIWD .,,............ 0x02
    BCICTL1 ............. 0x00
    BCICTL2 ............. 0x00

So its a little progress but lots of questions :

1. It still drops straight out of "USB Quick Charge 1"
2. The WDEN bit refuses to clear after I've used both the keys and manually cleared the bit.
3. Even though we're not in a charge state MADC reports BCIICHG=0x0243 which seems implausible.
4. Could the indicated value in BCITBAT cause charging to stop?
5. VBAT=3.06v, VBUS=5.03v, BAT Temp is around room temperature (22 degrees ish). I'm not sure how the conversion from MADC readings to voltage works but the reading for VBUS shouldn't be that much smaller than VBAT should it?
6. From STATEC and STATEP, the state transition was from 0x12 to 0x00. Looking at the state machine (fig 7.5), I can't see what condition would cause this as it only shows transitions from 0x12 to "Quick Charge X", "Charge Complete X" and "Charge Stop X" states. What condition would have caused this?

Cheers,

~Pev

Also, a little background information. I've attached some probes to ICTLUSB1 and ICTLUSB2. If I start with the board fully disconnected and then plug in USB (ie setting VBUS to 5v) I observe :

ICTLUSB1=5v, ICTLUSB2=200mV

If I then plug in a battery (with no software on the board so should stay close to reset state) I see :

ICTLUSB1=5v, ICTLUSB2=470mV

If I then execute the code above I see both lines drop briefly (approx 43ms). The levels they drop to before returning high are :

ICTLUSB1=80mV, ICTLUSB2=4.0v

So this is strange. Firstly when ICTLUSB1 goes low, I think this is not low enough to activate the FET. Secondly, ICTLUSB2 seems very low...

Hi Pev,

Just wanted to check what was the resolution for your charging issue you were facing above. It would be nice if you can share.

Thank you,

Gandhar.

Hi Pev,

I think I figured it out, may be it was GPBR1 setting to 0x91.Please confirm.

Regards,

Gandhar.