• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 66 subscribers
  • Views 2211 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.

bq28z610: Sleep / Wake functionality with SLEEPCHG=0 and IN_SYSTEM_SLEEP=1, SLEEP=1

Jason Mann53
Prodigy 165 points
Part Number: BQ28Z610
Other Parts Discussed in Thread: BQSTUDIO, EV2400

I have a design with the bq28z610 part configured for 1s operation where the CHG FET turns off when the device enters SLEEP mode. 

The pack is configured to wake on successful I2C comms and then return to sleep after 30s of no comms.  This seems to work fine.  Although, sometimes the first transaction on wake is hit or miss if it is a command write.

The pack is also configured to wake on current comparator around 200mA.  I'd set it lower if I could, but this is at the lowest setting for the sense resistor used.

When I attempt to "wake" the pack via discharge (because the CHG FET is off), at a low current, the CHG FET turns on (after ~2s) and the voltage increases which I assume is the CHG FET diode protection feature.

When discharge is removed, the CHG FET turns off in ~2s.  I assume the internal state is still "SLEEP".  This seems like the expected behavior.  IFF I switch to charge fast enough, I can charge the pack.

When I attempt to "wake" the pack via discharge above the wake comparator threshold, the CHG FET turns on (almost instantly) and the voltage increases which I assume is "wake via current".

When discharge is removed, the CHG FET turns off in ~2s. I assume the internal state is "ACTIVE".

Is this the correct operation?  My question is related to the last state above: Can I increase the time in "ACTIVE" to match the communications timeout?  2s is too short for our ATE to switch from DSG to CHG reliably and it does not have communications capabilities.  I cannot find any settings to set this time.  I was hopeful that it was based of off average current or that it would use the comm timeout, but that does not appear to be the case.  Please advise.

  • 0
    TI__Mastermind 25955 points
    Hi Jason,

    Thank you for your question. We will have a response prepared before the close of business on Wednesday.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 165 points

    Thanks Bryan.  I also have another question related to the I2C and wake function.  They may be interrelated.

  • 0 in reply to Jason Mann53
    TI__Mastermind 42535 points

    Hi Jason,

    Yes, that is the intended operation. You correctly understood that it's the chg fet turning on for protecting itself from overheating by body diode conduction. Unfortunately, this time can't be changed as it is fw controlled internally.

  • 0 in reply to Batt
    Prodigy 165 points
    Hi Batt,
    This would indicate that both the wake comparator and the body diode protection features are on hard coded time values; while the wake feature from comms has a DF configurable value and that there is no hidden value for the wake on current feature. Is that correct?
  • 0 in reply to Jason Mann53
    Prodigy 165 points

    As a corollary,  when wake is attempted via comms; the bq28z610 oftens refuses to acknowledge it's I2C address.  Using bqStudio and the Adv Comms Tab, a word read is rejected multiple times over a variable time period of up to 10-15s as shown in the attached.  Since the address is not accepted or acknowledged, the part does not wake and the CHG FET stays off.  Is this the intended behavior?

  • 0 in reply to Jason Mann53
    TI__Mastermind 42535 points

    Jason,

    What I meant was the timing is not adjustable. You can adjust the threshold for the wake comparator. My answer states that it's the time which is hardcoded when below threshold.

    Wake on I2C command is only possible when the gas gauge is put to sleep using the AltManufacturerAccess() SLEEP mode
    command or [IN_SYSTEM_SLEEP] is enabled with Bus Timeout = 0. Otherwise, the gas gauge wakes on an I2C connection
    (clock or data high).
    The wake comparator threshold is set through Power.WakeComparator[WK1,WK0]

    That last screenshot is not an expected way of operation. If you have gone into sleep via command with in system sleep, it will wake up on active comms.

  • 0 in reply to Batt
    Prodigy 165 points

    For the I2C condition with [IN_SYSTEM_SLEEP} enabled, setting the Bus Timeout = 0 appears to prevent the CHG FET from turning on entirely; even when correctly addressed and a response is given...

  • 0 in reply to Jason Mann53
    TI__Mastermind 42535 points
    alright, we'll have a test engr look at it. this might take until Tuesday to check out
  • 0 in reply to Batt
    Prodigy 165 points

    That's fair.  Do you think I could have an update before 3pm EST (UTC-05:00), Thursday (20-FEB-18)?

    Thanks,

    -Jason

  • 0
    TI__Intellectual 1365 points

    Hi Jason,

    I assume that Sleep : BUS timeout = 30secs, IN_SYSTEM_SLEEP = 1, DA Configuration[SLEEPCHG] = 0. Is it correct ?

    It looks CHG FET turns off due to another reason because it requires 30 seconds to enter the sleep mode again if BUS tmeout = 30 secs. CHG FET was on due to body diode protection function.

    Please, check 1.operationstatus[XCHG] in normal mode

    2. Disable all Enabled protections and see the behavior to find out the root cause. 

  • 0 in reply to Jasper Yi
    Prodigy 165 points

    Hi Jasper,

    Yes.  That is correct.  The system requirements necessitate the lower quiescent current sleep with the CHGFET off.  And as configured like this, when the bq28z610 acknowledges its address, it wakes, CHGFET turns on and stays on for 30s.  

    However, the previous response indicated that BUS timeout must be set to 0 in order for IN_SYSTEM_SLEEP=1 to function correctly (the RefMan language implies this).  When I configure the bq28z610, with BUS timeout=0, the CHGFET never turned on with valid comms.  I assume this means the z610 did not wakeup.

    Additionally, in both modes, there are many circumstances where the z610 simply does not acknowledge its address.  Repeatedly.

    My questions are:

    1) Is BUS timeout=0 the only way for IN_SYSTEM_SLEEP=1 to function correctly? 

    This seems to not be the case, but this is what I was told above and this is what the RefMan seems to indicate.

    2) Is there a known issue with the I2C communications module on this platform where in the above configuration operation becomes sporadic?

    3) Is there a known issue with the EV-2400 I2C signalling / timing deviating from the I2C specification?

  • 0 in reply to Jason Mann53
    TI__Intellectual 1365 points
    1. IN_SYSTEM_SLEEP = 1 will modify the sleep exit condition.It enters the sleep mode if sleep condition is met when SMBUS line is high and BUS timeout is not zero.
    If BUS timeout =0, it enters sleep mode right away when sleep condition is met and you can see the SLEEPAD bit is set and clear when you scan the Registers. CHGFET is never turned on with valid communication since it enters sleep mode again.
    2. I have not heard about the issue but a proper waiting time is required or clock stretch could be happened during fuel gauge operation
    3. When I analyzed EV2400 I2C signal, I did not find the violation. If you capture the scope shot , it would be helpful to debug the issue.
  • 0 in reply to Jasper Yi
    Prodigy 165 points

    Here is what I see on our platform, which is fundamentally not different than the reference design for the part in the datasheet.

    Valid read transaction with bqStudio and EV-2400 (part was already awake):

     

    Unacknowledged read attempt after 30s and part sleeps (CHGFET off):

  • 0 in reply to Jason Mann53
    TI__Intellectual 1365 points

     The waveform from EV2400 looks OK. Please, re-send I2C command within 400ms since the gauge would not be waken-up at first I2C command.

  • 0 in reply to Jasper Yi
    Prodigy 165 points

    I can manually resend the read request (via bqStudio) within <200ms and it does not respond.

    If I do it repeatedly, it will eventually respond.  It looks like it can take between 760ms - 560ms or <200ms comms attempts (4-5 tries) until a response occurs. Although sometimes an error occurs immediately after a good response.  But at this point it is out of sleep; so that isn't a concern.

    The scope shots aren't really helpful to illustrate, but the adv command log shows:

  • 0 in reply to Jason Mann53
    TI__Intellectual 1365 points

     Hi Jason,

    I tried to reproduce the issue on my bench but failed. Can I get your .srec file to test it ? Is there any other slave devices which shares the same bus ?

    Here is my email address : jasper.yi@ti.com

    Are you using EV2400 ? Would you test it with Aardvark if possbile ? 

    I tested EV2400 and Aardvark both but couldn't see any problem.  I configured BUS time = 0, Voltage time =5 sec or 20 sec, DA configurtion = 19.