• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 65 subscribers
  • Views 916 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BQ25703A: I2C not responding

user5067805
Prodigy 100 points
Part Number: BQ25703A
Other Parts Discussed in Thread: EV2400, TPS65987D

Hello,

I am writing to ask about communication over I2C. Chip is not responding to it's address (0xD6).

I am adding our schematic file.

In given situation:

5V on PP_HV  makes REGN to go 5V but CHRG_OK pin stays low.

Questions:

Is there any error on the schematic that could affect I2C communication? (Pull-ups of I2C lines are on other part of schematic)

What is minimal operational configuration of BQ25703A chip? What pins do I need to connect to be able to communicate over I2C?

Best regards,

Wojciech Maćkowiak

  • 0
    TI__Expert 5330 points

    Hi Wojciech,

    What are you using to communicate with the device, is it EV2400 or a uC?  If it's a uC, is it on the same board or external?  In addition to SCL and SDA, you need a common ground, so if you are connecting to an external board, then you also need to connect ground between the two boards.

    As long as BQ25703A is powered by either adapter or battery, then you should be able to communicate over I2C.  Do you have an EV2400?  If you are trying to communicate with on-board uC, then also testing with EV2400 as a known-good source will help identify if the problem is at BQ25703A or at the uC, i.e. divide and conquer.   

    Also, if you are using uC, please double-check the address you are using.  I2C uses 7-bit address followed by 1-bit R/W indicator.  0xD6 address includes the R/W bit (set to 0).  Some uC code expects the 7-bit address, which would be 0x6B. 

    CHRG_OK remaining low is definitely a concern and may be an indication of the root cause.  Have you measured to confirm that INT_3V3 rail is coming up and has 3.3V?  Do you know if CHRG_OK is coming up temporarily and then falling again, or is it never coming up at all?  Can you measure the VBUS pin voltage (at either C12 or R3 is probably easiest point to probe) to confirm that it is above 3.5V? 

    Regards,

    Steve

  • 0 in reply to Steve Preissig
    Prodigy 100 points

    Hi Steve,

    Thanks for the reply.

    I have got custom board. Master of the communication process is TPS65987D. Both chips are on same board with common ground.

    Unfortunately i do not have EV2400. Below adding waveform of I2C lines:

    Communication process is started after 1,18s outcome is shown in lower right list. Moreover after about 7s SCL line is pulled low for unknown reason.

    As for the rest of your questions: I checked INT_3V3 signal and voltage is present, CHRG_OK never goes high and VBUS has voltage of 5,3V.

    Best regards,

    Wojciech Maćkowiak

  • 0 in reply to user5067805
    TI__Mastermind 25800 points

    Hey Wojciech,

    When you apply a battery at the VBAT node (no input source at VBUS), does the I2C communication work? 

    Also, on the schematic, I did not see any I2C pull-ups on the SDA/SCL lines of the charger. Are these off-page on the I2C bus?

    As Steve mentioned, it find it very odd that the CHRG_OK pin does not pull HIGH when apply your input source. 

    Regards,

    Joel H

  • 0 in reply to Joel Hernandez II
    Prodigy 100 points

    Hi Joel,

    As mentioned in first post I2C pull-up resistors are on different designsheet.

    I decided to once again check CHRG-OK pin and I found that it was pulled-down by TPS65987D (It was connected based on TIDA-01627 reference design). After disconnecting TPS from line, CHRG-OK signal works fine. Below I am adding waveform with current communication process.

    As you can see I2C communication is still not acknowledged, the problem is that master is sending data too soon.

    TPS65987D is a master on this I2C lines and I programmed it based on this document: www.ti.com/.../slvae18.pdf

    Do you know how to delay start of communication process? Maybbe i should use other triggers than mentioned in slvae18?

    Best regards

    Wojciech Maćkowiak

  • 0 in reply to user5067805
    TI__Mastermind 25800 points

    Hey Wojciech,

    Sorry for my late response on this. One thing I would confirm if there are issues while a battery is present. For the charger, the I2C communication should work if either VBUS or VBAT are present on the charger. Both VBAT and VBUS voltages must be valid voltages above their respective UVLO thresholds for the I2C driver internal to the charger to be active. 

    I agree that your controller should wait until the CHRG_OK signal goes HIGH before it attempts to program the charger, or have it continually attempt communication even after the CHRG_OK goes HIGH. Again, I would argue that if a valid battery is present in your system, I2C communication should be active.

    I cannot comment on the reference design itself. You will need to post a new question about that particular reference design to get assistance. However, I see from the schematic of the reference that the CHRG_OK is passed into a GPIO pin of the PD controller; which can potentially be used as an interrupt to the controller to initiate communication with the charger. 

    Regards,

    Joel H

  • 0 in reply to Joel Hernandez II
    Prodigy 100 points

    Hi Joel,

    Sorry for late response. I have been on holiday. I have checked what happens when battery is present.
    Problem still occurs. I will post parallel thread to ask about TiDA.

    Best regards,

    Wojciech Maćkowiak

  • 0 in reply to user5067805
    TI__Mastermind 25800 points

    Hey Wojciech,

    I would also recommend in parallel, as Steve did previously, to purchase an EV2400 or even separately with your own controller, tap into the SDA and SCL lines and attempt communication with the charger externally.

    At this point, we can't say for certain that this a power up issue, which doesn't seem likely, or that the communication from the host device in the design is incorrectly sent.

    Regards,

    Joel H