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.

BQ25713: Loss of I2C response above a voltage that is below ACOV and SYSOVP.

Part Number: BQ25713
Other Parts Discussed in Thread: BQSTUDIO, EV2400

Our Bq25713 design looses I2C communication above a certain voltage. Typically around 12V.  Input voltage from VINDPM is 8V. What register value would be responsible for setting this threshold?

Prior to raising the voltage HiZ is disabled as is the WDT.  No battery is connected for this test.  Battery charge current is set to 0mA.  3s config with 3.3V on CEL_BATPRSZ (6V VDDA).

  • Hello Charles,

    Just to confirm, my understanding is that you are not able to communicate with the device if your Input voltage is above 12V, correct? You can change the InputVoltage register to change VINDPM after power-up if you want to do that.

    Here are the things I would recommend to check first:

    - Input current clamp is sufficient and the input is not getting clamped (500mA should be enough)
    - CHRG_OK goes high if your input is below the 12V threshhold
    - No faults in ChargerStatus() register
    - No shorts on any of the FETs or inductor
    - Monitor REGN to see if it stays at 6V when you lose communication

    It's possible that the reason you are seeing that specific input threshhold is that the converter is switching from Boost mode to Buck mode at that threshhold. You can also try to configure the charger for 2S or 4S to see if the threshhold moves.

    Thanks,

    Khalid

  • We have noticed that the VIDPM scan at power up sets the Input voltage register for a voltage that if VBUS is lower will shut down the system. In this example we start at VBUS of 10V so the Input Voltage Register is set 1.4V below that and then we increase the voltage from there.  At 11.9V VBUS the BQStudio sends the address write to the 713 but nothing comes back.  Below this very exact threshold ACK is OK and we get a read of all of the resisters.  BUS scan shows correct data on the write and on the successful read of the registers.

    Setting Vsysmin to the default 9.2 or setting Vsysmin higher (11.008V) does not change this threshold so the buck/boost theory does not hold up. Loading the output at 1A does not change the threshold.

    Attached is a printout of the registers.  At 11.9V VBUS we can do successive manual reads and some work, some fail so this must be right on the edge.  I see no variable that relates to this threshold.  We don't use OTG or the PSYS/Comparator.

    The 25798 is our first choice but due to availability we have been pushed to a controller.

    I will attach a battery and see if it behaves the same.  We are using 4.7K bus pull ups on the I2C along with the Bqstudio.  Should these change?

    I am unable to attach the pdf so will send separately.

  • BQstudio screen shots attached.

  • It is acting like the VIDPM sets a low limit and a high limit but I don't find that in the documentation.

  • If this were the case starting from a higher VIN like 18V would set the high and low DPM around that power on voltage but that is not the case.  Starting with a VIN of 18V still has no I2C com with the BQStudio/EV2400. Our implementation is very close to the EVM with the following exceptions:

    CELL_BATPRESZ=3.3V w 6.03V VDDA.
    CMPOUT nc
    PROCHOT nc
    EN_OTG at ground
    VBUS filter 1Ω/470n
    IADPT nc ... Should this be terminated?

  • Hello Charles,

    What voltage are the I2C pins pulled up to? We recommend using 10K pullups.

    For IADPT, Inductance detection is done through this pin so you need to put the appropriate resistor to ground on this pin. 

    The other pins should be OK. VINDPM should only be a lower limit and increasing the voltage should not cause this issue.

    Based on your description "At 11.9V VBUS we can do successive manual reads and some work, some fail so this must be right on the edge.  I see no variable that relates to this threshold.  We don't use OTG or the PSYS/Comparator." it sounds to me like there is an I2C setup issue.

    Thanks,

    Khalid

  • I2C is pulled up to a separate LDO regulated 5V that is clean. Other I2C devices on the bus have been removed and no change.  I have ramped up the input voltage while watching the 5V and there is no change around the 11.9V threshold.

    I will add 169K to the iADPT pin.

  • Hello Charles,

    Can you also change the pullups on the I2C pins to 10K? Are you using EV2400 for communication?

    Khalid

  • I am doing that now. Going to check the EVM for similar performance.  Most of our design for the controller is based on the EVM. I did find one difference where we had a 38.2K  for the Ilim_HIZ top divider resistor (220K low) rather than the EVM 382K.  And the lack of IADPT termination.  Here is the check list:

    I2C pullups local with 10K. Remove the 4.7K on the other side of the PCB.
    Change 38.2K to 382K
    Add termination 169K to pin8.

  • Charles,

    Could you also collect I2C scope plots when it is working and not working?

    Khalid

  • Well ...  I replaced the 38.2K on Ilim first with 382K and it now works at 18V VIN.  Explain that one please. Might want the PL to try that to explain why I2C  fails comm. I didn't think it shutdown because it still is switching and VDDA stays at 6V.   I did not change to 10K I2C pull ups yet or terminate IADPT.