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.

BQ78350-R1: When I begin charging, I lose communication to bqstudio

Part Number: BQ78350-R1
Other Parts Discussed in Thread: BQSTUDIO

The problem where I lose communication with bqstudio has started again.. While I'm charging, this sometimes causes the charge to terminate prematurely. I have attached a short log and a few screen shots of the dip in and out with bqstudio. I cannot upload the .srec file or the .err file. I'm getting an error in the forum that says I cannot upload those file types.

/cfs-file/__key/communityserver-discussions-components-files/196/5611.Log-of-charging.log

Screenshots of charging issues.docx

  • Hi JP,
    It could be one of several things. The elapsed time in the log indicates you are scanning at about 1 sec. This may use up most of the timeline for something in the system, probably the SMBus, thus the nacks.
    You might try:
    Look at the SMBus with a scope to be sure there is lots of time
    Look at the I2C to be sure the timeline has lots of space, if this gets busy the gauge won't be able to talk.
    Check that there are not other things running on the PC
    Reduce the scan rate.
    Reduce the number of registers scanned/logged. (Go to Window/Preferences/All Global Settings/Show Advanced Views, you can check which are scanned and which are logged).
    Be sure the SMBus and I2C cables are securely attached and not damaged.
    Disable the dashboard (it has separate SMBus traffic)
  • Thanks WM5295, I'll have to check these things when/if it happens again. Let's keep this open for now and I can test these things periodically. Thank you again, I will keep you updated. BTW, this happens ONLY when I begin charging. Other than that, everything is fine.

    JP

  • Can you explain further how the scan rate can affect the SMBus and the I2C?
  • Hi JP,
    The gauge has only so much time line to accomplish its tasks.
    It must perform its calculations to have data to present on SMBus.
    To perform the calculations it must get data from the monitor over I2C.
    If it is busy with I2C it can't perform its critical operations and can't talk on SMBus.
    I don't know how much of the timeline is used by gauge processing, it likely varies with the system mode as well as the firmware version. The remainder of the time is available for SMBus transactions.
    If you put a scope on the SMBC line you will see the standard polling occurs approximately once every 4 seconds and takes about 1.5 seconds. there is 1 second of dense traffic. If you poll more frequently one poll will be trying to overlap the one already in progress. Data will get lost. Cut down the amount of data or the polling rate.