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.

BQ4050: SMBUS Communication Issues

Part Number: BQ4050

Tool/software:

I am working on a developing an in production programming device to dump setting onto a custom PCB with the BQ4050.

I am having a lot issues with getting the BQ4050 to respond as I expect, and have currently gotten to a point with my two prototypes. Where the boards are now not responding to even the address call.

A couple of things I currently have the test packs and the host module scoped up and I am watching the communication lines on my oscilloscope. All the hardware and signaling seems to be intact from a signal integrity stand point. I currently have the clock running at 10Khz and the data looks clean and it is making it to the chip.

I feel fairly confident that my problems are coming from either not sending packets in the right order or missing some sort of end packet. or some how sending a byte that locks the device. So basically something in my host firmware that is not interfacing with the bq4050 correctly.

For this application, I think the solution should go down the path of automatically setting the chip to the correct mode by default in my procedure so that setting can always be dumped. This way it simplifies the manufacturing process where my lower level guys do not have to try and worry about the status of chip before they try program the production settings.

Do you have a procedure for which registers in which order to write to make sure that the chip is accessible. Are there certain commands that need a check sum? or and exit command?

  • Hi Alfred,

    I currently have the clock running at 10Khz and the data looks clean and it is making it to the chip.

    10kHz seems like the minimum speed for the communication structure of this device. Would it be possible to increase this to see if it is able to improve the results?

    If possible, can you please go more into the current process that is being attempted (i.e. which registers are being attempted to be read/written to, any waveforms images?)

    Regards,

    Anthony

  • Currently I am trying to just get a simple read out of the device. Specifically DAStatus1. I will try increasing the clock and see if that has any effect. However my question would remain the same.

    Is there a specific sequence of registers that ought to be configured or have their settings confirmed so that I have access to the chip right now I cant even get it to respond to an address call.

  • Hi Alfred,

    The only states that would disallow for the gauge to be read from is either it being in a Shutdown state or Sealed state. If the gauge has not been sent the Seal command or if the .srec programmed to it was pulled from an unsealed device, then the gauge should not be in a sealed state.

    Is this being done with a fresh device? If so, how many cells are being attached to it at this time?

    Regards,

    Anthony

  • I have attempted with an increase in clock frequency I am concerned that I have sent this gauge into a sealed state. Messing around with attempting to unseal it. I will work on double checking my unsealing procedure. However from some spots in the literature there were some sealed states that could not be unsealed. Is there a proper way to fully reset the chip.

  • Hi Alfred,

    Are their any other registers attempting to be read from? If OperationStatus is read out, this can tell you whether the gauge is in a sealed state or not:

    If the gauge is in a sealed state, the only way to reset it would be to complete a power on reset. If it is unsealed, then the Reset Command can be used below:

    Regards,

    Anthony