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 in full speed failures

Part Number: BQ76952

Hi Experts,

Good day We would like to clarify about the maximum speed of I2C the battery monitor BQ76952 is capable of.

Client is trying to manage it (in EVM) with external processor, and found some communication failure at 400kHz. Using the on board processor and the GUI, it shows that the "400kHz" setting is in reality around 300kHz.

Can you please clarify the situation? Did the BQ76952 really can't be used at 400kHz?

Thank you for your support.

Regards,
Archie A.

  • Hi Archie,

    Yes, the BQ76952 works at 400kHz. There is sample code available in the product folder for two different microcontrollers that runs at 400kHz. The EVM microcontroller does not run as fast but this is related to the overhead of the GUI, not a limitation of the BQ76952.

    Best regards,

    Matt

  • Hello Matt,

    Thanks for your guidance.

    Client responded that he is using other MCU (PIC18F) and use it at full speed with another devices. Will conduct test deeper to find why his code is not working at 400kHz. Will update you here for the result.

    Thank you.

    Regards,
    Archie A.

  • Sounds good Archie. I recommend referring them to the code examples and this video may also be helpful: https://training.ti.com/microcontroller-programming-bq769x2-battery-monitor-family . The BQ769x2 Software Development app not was also updated recently.

    Best regards,

    Matt

  • Hi Matt,

    Thanks for responding.

    I have  received new information (attached below) from client with the following notes:

    "I have a look deeper on the trouble and it seems come from my processor. In fact, just before stop to received data from the BQ76, my code ask for received next byte but the processor is generating 9 clock instead 8 and the I2C RX interrupt never trig (show screenshot). I add on the code an output drive showing waiting states. So, I must understand why the processor is on RX state but work as TX state (and really not working well because interrupt flag is not working include in TX state). Thanks you for your support. BR Thierry

    At the end, the problem is on the BQ76952. Is not fast enough for work at 400kHz. The processor is finding "P" conditions during transmission. See the last screenshot. The clock rising edge arrived before the slave (BQ) place the SDA. I solve the problem with 1k pull up on SDA and 10k pullup on clock for delayed this last one. Please, report this trouble and tell me any feedback."

    Any thoughts clarifications on these?

    Thank you.

    Regards,
    Archie A.


  • Hi Archie,

    Some users have found 5k pullups work well. I have not heard of anyone needing to use different pullup resistors on SDA and SCL before and there is a very large number of users for this device. This seems a little strange. Perhaps it is unique to this specific board characteristics. Does their MCU support clock stretching?

    Regards,

    Matt

  • Hello Matt,

    Thanks for your support.

    The client responded that may be their trouble come from 2 ways. One is not using crystal clock on this project but the internal clock with pll (higher jitting than cristal clock). Second is that may be PIC18F processor have lower digital threshold and detect clock rising edge earlier than over components.

    The last screenshot attached show clearly that data edge arrive late regard clock edge. For that, they will keep different pullup value resistor on data and clock signals.

    We can now closed this thread, I think.

    Thank you for your guidance.

    Regards,
    Archie A.