• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 63 subscribers
  • Views 111 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ25622E: BQ25622E VSYS Drop Issue

Eric Mo
Intellectual 970 points
Part Number: BQ25622E

Tool/software:

The customer designed the Battery Charger circuit using BQ25622E, . When I2C runs in standard mode (100kHz), there seems to be no problem, But when I2C is running in fast mode (400kHz), the device is not working normally, and they checked that the VSYS output of the BQ25622E dropped to about 1V for about 150us. (See the waveform below). They increased Tbuf to 100us or more as shown in the waveform below, but the symptom continues to occur. Can you please help provide any suggestion that might cause this  issue? Thank you!

  • 0
    TI__Mastermind 31550 points

    Hi Eric, 

    To prevent the VSYS drop behavior described the BQ25622E device does have a timing requirement for I2C communication. This requirement is described in datasheet section 8.5.1. No additional requirement is needed when using standard mode (100kHz) I2C, hence why customer sees no issue. 

    When operating at 400kHz I2C a minimum of 68 us Tbuf is required. While the provided waveform does appear to show sufficient Tbuf delay between two packets of communication I would like to point out that an I2C read transaction includes a 2nd START command within the communication. When performing a read there needs to be sufficient delay between the 1st START command and the 2nd START command of the I2C read. The provided waveform appears to show no such delay in the middle of the read.

    If customer believes they are properly implementing this necessary delay and still seeing a problem can you please have them share a waveform showing SCL, SDA, and VSYS in the same capture. 

    Best Regards,

    Garrett