Hi All,
In our design we intend to charge via USB and we don't have an AC Charger at all. We've based the schematic on sample (C) from the data manual.As we're not using AC charger PCHGAC is grounded and ICTLAC1/2 are floating as reccommended. BCIAUTO is grounded through 196K. I think I'm missing something obvious as I don't see any charging activity.
In the bootloader (with a powered USB cable plugged in) I dump BOOT_BCI and it reads as 0x35. i.e. (BCIAUTOWEN | CONFIG_DONE | Reserved | BCIAUTOAC) Interesting as in section 7.4.1.1.1 of the TRM an Rbciauto of > 140K should set both CVENAC and BCIAUTOAC. Also I'd have expected CVENAC to be set and BCIAUTOWEN not to be set...
After that I attempt to set BCIAUTOUSB to allow USB charging and I then dump pertinent regs :
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
I'm feeling a bit confused here as I'm not sure what direction to head in! Has anyone else had any joy with USB charging? I've seen a few posts where people are doing (D) with both AC and USB but not solely USB charging.
Cheers,
~Pev
Hi Pev,
Please try the following,
Normal 0 false false false MicrosoftInternetExplorer4 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.
Normal 0 false false false MicrosoftInternetExplorer4
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?
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.
You can try this workaround. However, even with this you will have to set the OTG_EN and USBFASTMCHG bits. Please refer to section 7.4.1.2.1 for USB charging setup (page 426) in the TRM (http://focus.ti.com/lit/ug/swcu050d/swcu050d.pdf)
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,
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.
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.
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:BCIAUTOACSET BOOT_BCI:BCIAUTOWEN, BOOT_BCI:CONFIG_DONE, BOOT_BCI:BCIAUTOUSBSET GPBR1 = 0x90// DUMP INTERESTING REGISTERSSET POWER_CTRL_SET = OTG_ENSET BCIMFKEY = 0x6DCLEAR BCIMFTH3:ITBCIGROUPSET BCIMFTH3:ACCHGOVTH = 0x01SET BCIMFSTS4:USBFASTMCHGSET BCIWDKEY = BCIWDKEY6SET BCIWDKEY = BCIWDKEY5SET 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 :
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...
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.