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.

BQ76952: I2C and SPI troubles, slow BQ response

Part Number: BQ76952

Dear,

Some month ago I was fighting for work with the BQ76952 using I2C at full speed. I post a thread for that and unfortunatly I keep at 300kHz because it was impossible to work at full speed dispite playing with pull up resistor for apply some delay.

As the communication was too slow, this week, I try to work with SPI. Starting the BQ with I2C (because the default comm mode), I reach to swap to SPI mode.

I have a question. In case of I have to make any hot reset of my processor, I must reset also the BQ else I will start again with I2C and the BQ is already in SPI.

I try to apply a glitch on the RST_SHUT input but, if BQ make the reset, it still in SPI and seems not start again as after shutdown.

Is the RESET function put the BQ with default registers conditions?

Anyway, SPI is quite faster for communication because I am working at 1Mbit/s but for nothing because the BQ need a lot of wait between reads or command.

At the end, reading all Vcell and others, SPI keep slower than I2C and I am reading not refreshed values. In fact, values read are many times the same than previous.

So, no way, I will come back to I2C as I have no reach to work properly with SPI. At least it was working quite stable with I2C.

Best regards

Thierry

  • Hi Thierry,

    I suggest using I2C because while it is slower, it does offer many advantages like block writes and reads and it is much easier to work with. 

    As far as your I2C only working up to 300kHz, this is not normal. Does your microcontroller support clock stretching? The BQ76952 will use clock stretching sometimes on direct commands if it needs some extra time to process a request. For the subcommands, some wait time is needed (many users report 2ms works well between writing the command to 0x3E and reading the result from 0x40), or you can periodically read from 0x3E after sending the command to poll when the command is complete as described in the TRM. You just don't want to poll too aggressively - I think this may slow things down.

    The RESET command 0x0012 will reset all of the device registers to default, or to the OTP values if OTP has been programmed. The RST_SHUT pin performs a partial reset which does not reset the device registers.

    Regards,

    Matt

  • Hi Matt,

    Thanks for answer.

    Regard I2C speed, I have not test again at 400kHz. My microcontrolor is not using clock stretching. Also, the communication problem was during the stream. It is not any data error due to delay but transmission error during the I2C stream.

    Regard the RESET function,it is a shame that reset input doen't do the same as reset command. I will try to find any solution for this topic.

    At the end, I reach to work with the SPI reducing the data read. It was the reason why values was not refreshed. the BQ processor was too busy.

    In this way, I am agree with you in the meaning that seems I2C take less work to BQ processor.

    Best regards

    Thierry