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.

BQ40Z50-R2: Loss of SMBus communication.

Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQ40Z50, BQSTUDIO, BQ24765

The technical reference has the following description, but sometimes there is no SMBus communication.

There is no access for only one cycle, and it will be restored from the next cycle.

Are these symptoms confirmed?

Description of technical reference:

ChargingVoltage() and ChargingCurrent() broadcasts are sent to the smart-charger device address (0x12) every 10 s to 60 s.

Thank you for your reply.

  • The gauge can Nack or clock stretch when busy. the host must retry in such cases.

  • Thank you Shirishu-san.

    No errors(NACK or clock strech) occurred in communication.
    The master of this communication will be gauge.
    The communication from the gauge to the charger suddenly breaks.

    Paste the waveform when the phenomenon occurs.
    Communication is missing at the red frame(50 seconds after the last communication).

    Thank you for your reply.

  • Hello Tetsuya-san,

    Upto 60 seconds gap would be normal operation. The number of seconds is approximate. So it could take a little more.

    The capture seems to show >60s gap. Let me know if/what kind of issue this is creating.

  • Thank you Shirishu-san.

    I'm sorry for the lack of explanation.
    One scale of pasted image is 40 seconds.

    Normally there is access every 50 seconds.It works as described in the datasheet(every 10 s to 60 s).
    However, when a problem occurs, there is no access for 90 seconds.
    The operation is not described in the datasheet.
    We are asking about this.

    Is this 90 seconds also a gap of 60 seconds?
    If so, I have the following question.
    1.What is the maximum time including gaps?
    2.Why is the time including the gap not listed in the data sheet?
     We only know the time(10 to 60s) stated in the datasheet.

    Our system accesses the SMBus after confirming gauge access.
    In the pasted image, the first access is the gauge and the second access is our system.

    I am in trouble because I expect the gauge to be accessed within 60 seconds according to the data sheet and standards(Smart Battery Data Specification
    ).
    This is because it is determined as an error if there is no gauge access within 60 seconds.However, we actually judge in 70 seconds with margin.


    Thank you for your reply.

  • It will be additional information.
    In today's confirmation, we were able to confirm times other than 90 seconds, so the blank period is not a fixed time.

  • Hello Tetsuya-san, 

    Thank you for the information. I will assign this thread to an expert.

  • Hello Tetsuya-san, 

    What other commands are being sent on the bus besides the broadcasts for the gauge? Is the gauge switching power modes (going to sleep) it may cause the times to change. Can you also share your .gg file so we can take a look at the firmware version and settings.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.
    thank you for your reply.

    This phenomenon occurs between the battery equipped with BQ40Z50.
    I contacted the battery manufacturer but did not receive a response, so I asked this question on this forum.

    This phenomenon occurs suddenly while using our device.
    More simply, it occurs during discharge of the battery that houses the gauge.
    The SMBus controller for the battery only has a gauge.
    Therefore, it becomes the operation of the gauge.
    The battery is discharging and has not switched power modes.
    There is only write access to the charge from the gauge and read access to the battery (gauge) from our system.
    Please refer to the image attached before.
    Read access from our system only obtains information such as temperature and state of charge.
    There is no writing to the gauge at all.

    I can't provide a gg file as the gauge is in the battery.Because we can't get it.

  • Hello Wyatt Keller-san.

    Please tell me.

    What kind of file is the .gg file?
    How can I get the .gg file from the gauge?
    If you have a document that describes .gg files, please let me know the document name and location.

  • Hello Tetsuya-san,

    Can you explain further what the discharge load conditions are for this test? I want to make sure there are no possible power glitches from the discharge that would interfere with the gauge communication.

    In broadcast mode the gauge will not perform and arbitration on the communication bus, so if your host starts a communication around the broadcast interval it may cause communication issues.

    The .gg file is an exported file from BQStudio, if you select the data memory page then click export you can attached the file to the forum by dragging and dropping it.  

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.
    thank you for your reply.

    We have confirmed that no communication error occurred when the problem occurred.
    There is no communication on our system before or after the host's broadcast interval.
    We are communicating 5 seconds after the two hosts have finished communicating(charge voltage & charge current).
    Confirming that host communication is complete.

    In the previous attached image you can see the system communicating after the host communication.
    However, when a problem occurs, it will be idle for 90 seconds even though there is no communication at all.

    Thank you for the information about .gg files.
    Connecting BQStudio to our system is difficult.
    However, we are trying to save the registers before and after the problem occurred on our system.
    We assume that this information tells us the state of the gauge.
    I will contact you when I can get the data.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Wyatt Keller-san.

    Send the value of the register when the problem occurred.
    The line 1991 where the problem occurred is highlighted in orange.
    The battery mode() register has not changed.
    No other registers were changed when the failure occurred.

    Sincerely,

    Tetsuya IshikawaBQ40Z50_Register dump.xlsx

  • Hello Tetsuya-san,

    Thank you for clarifying, let me check with our firmware team on the possibilities which this could occur. I will give an update by the end of the week.

    Sincerely,

    Wyatt Keller

  • Hello Tetsuya-san,

    Response from the firmware team:

    One possibility is if host is writing Charger broadcast bit (0x4000) in Battery mode (0x03) register, it will hold off the charge broadcast for 50s that can reset the time. Another possibility is if gauge is in sleep mode that would delay master mode broadcasting, or bus is detected low at the time of attempting to broadcast messages. The delay suggests it's skipping one message in periodic broadcasting. Gauge counts the charger broadcast timer and once timer (50s) is expired, kick the smbus process to start broadcasting message as soon as bus is free and alive (not low), no other condition to skip periodic broadcast unless gauge is in sleep mode, if bus is alive (high) and free, it would continue to broadcast unless host using battery mode command overrides it as mentioned above.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.
    thank you for your reply.

    In summary, do you agree with the following understandings?
    There are only three possible causes for this phenomenon.
    1.Stop broadcasting with the battery mode () register.
     ⇒Battery mode() register has not change. It is also clear from the pasted register list.
    2.Gauge is in sleep mode.
     ⇒ManufacturerAccess() has not changed.
    3.Bus is detected low at the time of attempting to broadcast messages. 
     ⇒The bus is not low when the gauge broadcasts.It is also clear from the pasted waveform.

    None of them apply. Does the gauge go into sleep mode only if I set [SLEEPM] = 1 at 0x0011 to ManufacturerAccess()?  Or are there other conditions for sleep mode? None of this applies if you only set [SLEEPM] = 1.
    Has this kind of phenomenon been reported before?

    Sincerely,

    Tetsuya Ishikawa

     

  • Hello Tetsuya-san,

    I'm checking if there are any other possibilities since it seems you are not meeting any of them.

    Can you confirm it is not in sleep mode? SLEEMPM is set when a sleep command is received, the SLEEP bit is set if the conditions for SLEEP are met so it may be a better bit to review.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.
    thank you for your reply.

    Please continue to investigate whether there are other causes.When this phenomenon occurs, check whether it is in sleep mode.I will let you know the confirmation result, so please give me a little time.

    Sleep mode confirms command 0x0011(Sleep Mode) of Manufacturer Access(), so is it correct?

    Sincerely,

    Tetsuya Ishikawa

  • Hello Wyatt Keller-san.

    The previous question was wrong.Is confirmation of sleep mode correct with ManufacturerAccess() 0x0054 OperationStatus bit 23(SLEEPM)?

    Sincerely,

    Tetsuya Ishikawa

  • Hello Tetsuya-san,

    SLEEPM bit indicates if the command was received to enter sleep. Checking current consumption is probably the best way to verify the different power modes.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    When I checked Current(), there was no change in the current value before and after this phenomenon occurred.It's clear from the register dump file I sent you the other day.
    I'm having trouble reading the SLEEPM values.Is it meaningful to read SLEEPM when the current value does not change?I would like to stop reading SLEEPM if it doesn't make sense.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Tetsuya-san,

    You cannot check the gauge Current() register to see power consumption of the gauge, you must use an external equipment to measure current going directly to the gauge.

    SLEEPM should not be used unless you are sending a command to go to sleep and want to verify the gauge is waiting to go to sleep. It will not tell you if normal sleep initiated by the gauge is present.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    Thank you for your reply.Read the value of SLEEPM when this phenomenon occurs.I will contact you with the results.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Wyatt Keller-san.

    It will be additional information.SLLEPM confirmed no change with 0(=inactive)
    .

  • Hello Tetsuya-san,

    SLEEPM will not be valid to read to verify if the gauge is in sleep mode. It can only be used if you sent the sleep command.

    Please measure the current going directly to the gauge with external equipment to verify if the gauge is in sleep mode. You can also try to increase the Bus Timeout so that it is longer than the communication period (50s) or just disable the sleep and test again if it occurs.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    Please let me confirm.Is SLEEPM unreadable?It is described as read in the Access type of the Technical Reference manual.


    The gauge IC is built into the battery we use, so it cannot measure the current value.We have confirmed that there was no communication on the SMBus before and after this phenomenon occurred.I have already sent you the waveform.
    Can the sleep mode change without bus communication?This means that the device enters or exits sleep mode without bus communication.If so, I think it means that it will be the operation of the gauge IC.

    Sincerely,

    Tetsuya Ishikawa

  • I'm sorry again.

    Please tell me how to check if the device is in sleep mode (other than measuring the current value of the device). I will read and confirm the register that you tell me.

  • Hello Tetsuya-san,

    SLEEPM will only set if you send the sleep mode command. It will not set based on normal sleep mode entry conditions. You must measure the gauge current consumption in order to determine it's operational mode. You cannot read a register because the gauge will wake from sleep.

    If you are able to reproduce please disable sleep and test again while measuring the communication, you should not see any missed packets.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    As mentioned before, the gauge IC is built into the purchased battery(hard pack), so current measurement is not possible.

    We have confirmed that there is no SMBus communication when this phenomenon occurs.If there is a state change in sleep mode, I think the cause is not external access.
    Does the gauge IC automatically enter sleep mode and exit sleep mode automatically without external access?If it's temporarily going into sleep mode, this can only be the cause.

    Since our equipment is powered on, does it automatically enter sleep mode when the gauge IC is active and communicating with the charging IC?Communication with the charging IC refers to smart battery communication(10s - 60s).

    The waveform pasted above shows what I'm talking about.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Tetsuya-san,

    Wyatt is out of office and will be back on Monday.

  • Hello Tetsuya-san,

    If you are not able to read the current to confirm sleep mod you can also disable sleep mode in the gauge settings to verify that the behavior stops with sleep mode off.

    If there is charge current flowing the gauge will not be in sleep mode. How much current was flowing during the screenshots you have shared?

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    It's not in sleep mode.What we want to make sure is not that communication stops when in sleep mode.I know that putting it in sleep mode will stop the communication.

    Sleep mode is not set when this phenomenon occurs.
    The battery is not charged, only discharged.AC adapter is not connected.It works only with battery.The discharge current value is approximately 1A.Communication may suddenly stop during discharge.The previously pasted waveform is for 90s of free communication while discharging at 1A.

    What we want to know is why there is no communication during discharge.Before and after this communication is lost, nothing is accessed to the gauge.It's not charging, it's just discharging.

    After restarting communication after 90 seconds, communication will be performed normally at intervals of 50 seconds.or some reason this only happens once.I would like to know the cause of this.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Battery expert and software guru-san

    For some reason I cannot see your post.As I posted earlier, the current of the battery pack is 1A for discharge only.A problem occurs while discharging 1A all the time.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Tetsuya-san,

    I am verifying other possibilities with out firmware team. If you are discharging and not charging (broadcast mode is meant only to send to charger) how is this impacting your system? Is the charger always attached?

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    I know the broadcast sends to the charger.
    Our equipment uses the BQ24765 charger device.When the problem occurs, it is when the AC adapter is not connected and it is running on battery.So it's not charging, only discharging.If there is no problem, there will be a broadcast within 60 seconds regardless of charging or discharging.

    Our equipment monitors broadcasts from gauges to chargers.Broadcast expects communication within 60 seconds as specified in smart battery standards and gauge datasheets.If there is no communication within 60 seconds, we assume that there is a problem with the battery and turn off the equipment.This operation is for the purpose of ensuring safety.As a major premise, we have not changed the mode of the gauge(Battery).

    The problem is that the broadcast behaves unexpectedly, causing the device to shut down unexpectedly.We have received complaints that the equipment suddenly shuts down even though there is still battery remaining.

    The problem is that the broadcast from the gauge to the charger does not work according to the standard and datasheet.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Tetsuya-san,

    Thanks for the clarification. I am still waiting for firmware team feedback.

    What is the failure rate for this issue? Does it happen to all packs randomly or is there a small percentage where this is reproduceable?

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    Thank you for your response.The failure rate is about 15%.It happens with all battery packs that we have confirmed.
    We checked the battery pack from 100% to 0%.In this confirmation, this phenomenon (communication time becomes 60 seconds or more) occurred only once, and all others were within 60 seconds.It is about 15% that the communication time is 60 seconds or more only this one time.The remaining 85% all use up the battery in communication within 60 seconds.

    This is a problem because the power is turned off even if it occurs only once.We have received complaints from customers who purchased our equipment.

    Sincerely,

    Tetsuya Ishikawa

  • Hello Tetsuya-san,

    Thank you for the additional details. I'm still waiting for firmware team feedback on this.

    Sincerely,

    Wyatt Keller

  • Hello Tetsuya-san,

    I got more information from the firmware team, it looks like we cannot pinpoint the root cause but we suspect it is something related to what I had mentioned previously (sleep mode, battery mode modification, bus low, etc) The method you are using the broadcast feature is not the intended use case, broadcast should generally only be used in a system with only a gauge and charger since it has no arbitration, while in a discharge mode if the broadcast misses one packet this should have no impact on the system with only a guage+charger configuration.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt Keller-san.

    It is difficult to identify the cause.
    However, it is wrong to say that broadcast is used only for gauge ICs and charge ICs.It is described in the Smart Battery Data Specification.If there are only gauge ICs and charge ICs, then the standard is wrong.
    The figure below is an excerpt from the standard.System Host will be the microcomputer of our equipment.Smart Charger is BQ25765.


    Sincerely,

    Tetsuya Ishikawa

  • I missed one explanation.Smart Battery is BQ40Z50.

  • Hello Tetsuya-san,

    I just verified in the SBS specification that the Smart Battery needs to report the ChargingVoltage() and ChargingCurrent() to maintain charging. From your tests it shows the pack is in a discharge state.

    The specification does not clarify how to handle arbitration if one of the packets being sent is disrupted.

    Sincerely,

    Wyatt Keller