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.

BQ40Z60: Sleep Mode condition not respected

Part Number: BQ40Z60
Other Parts Discussed in Thread: BQSTUDIO

Hi,

I am working on an autonomous configuration of the bq40z60 for a device which the only purpose is to deliver power and to be able to charged.

My problem is: when I stop communication on SMBus, the device stop to charge after about 5 seconds.

I think the problem is that the b40z60 is going to sleep mode after the bus timeout, which I didn't expect because I have set DA Configuration[SLEEP] to 0. Also, the Sleep Current is set to 10mA and we are charging at about 400mA, therefore I didn't expect it to be able to go to sleep mode while charging.

As soon as I engage communication on SMBus, it starts to charge again.

How can I disable Sleep mode?

You'll find attached my configuration.

Best regards,

Yann

7587.config.zip

  • Hi Yann,

    Please try setting SLEEP = 1 and IN_SYSTEM_SLEEP = 1

    Sincerely,
    Bryan Kahler
  • Hi Bryan,

    I began to try that with the exact same result.

    I was expected that if I put these values to 0, it would enforce not going to sleep mode ever, according to page 71 of SLUUA04D.

    Also, in our tests, the bq40z60 is never going out of sleep mode when we connect the ac adapter. Is this expected behavior?

  • Hi Yann,

    Did any change in behavior occur? For the following tests, please return SLEEP = 0 and IN_SYSTEM_SLEEP = 0.

    The device should not being going into sleep mode. As an additional test to determine if the device is in sleep mode or not, please scope the TS pins.

    If the thermistor is being pulsed once a second, the device is in normal mode and not sleep mode.

    The problem is likely due to a protection or FET configuration.

    In your configuration file, FET Options is set to 0x20 (default). The FET will be disabled if the TC flag is asserted.

    As a test, please set FET Options to 0x00 and test the device. It should be able to charge at this point.

    Please log the device and determine at which point the TC flag is asserted. This will help narrow down what condition is causing the TC flag to assert. More information on the states of the TC flag may be found in section 4.7 of the TRM: www.ti.com/.../sluubk0a.pdf

    \Sincerely,
    Bryan Kahler
  • Hi Bryan,

    So there is no change of behavior.

    I have set SLEEP to 0 and IN_SYSTEM_SLEEP to 0 and scope TS pins. The TS pins are pulsed every second when I communicate with bq40z60 and charge is enable AND when I don't communicate and charge is disabled. Meaning, as you say, that it actually doesn't go to sleep mode.

    But I am positive that there is no protection triggered and the TC flag is definitely not set. I tried putting FET option to 0x00, it didn't change the behavior.

    Find attach the config and a short log (where we can't see the problem as it actually enable the charge when logging, but as soon as the logging is disabled, it disable the charge)

    Best regards,

    YanntestSleep.zip

  • Hi Yann,

    Thanks for the log. Could you send another with a bit more resolution? Perhaps 4s intervals instead of 30s. Please also provide a schematic and details on the PRES pin operation.

    Something to look closer at: On the 5th sample, in Operation Status A the SS flag asserts and charging is disabled.

    Sincerely,
    Bryan Kahler
  • I have found my problem. As mentioned in this thread: 

    My problem was the HWDF flag in Safety Status C+D was set and disabled charging.

    This was quite hard to detect because HWDF is "Flag SBS Host Watchdog Timeout", which get set (apparently, couldn't find anything in documentation) after 5 seconds without SBS communication. And it resets when a communication occur. Therefore, when getting the data from the bq40z60 using bqStudio, this flag is reset before the value is sent. BUT not every time, certainly because of race condition between updating of the flags value and sending it. So after several retry, I manage to capture this flags value at 1:

    Setting the bit HDF to 0 in Enabled Protections C fixed my issue.