• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 77 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.

BQ25120F3A: VIN presence detection when /PG is used as /MR shifted (MRS)

Michal Šebesta
Prodigy 20 points
Part Number: BQ25120F3A
Other Parts Discussed in Thread: BQ25155,

 Hi!

We are integrating BQ25120F3A and we got a little bit confused and couldn't find answer neither in integration manuals or FAQ. Previously we were using BQ25155 IC so we are adapting our existing code to the BQ25120F3A battery management.

The question is: Is there any way for the BQ25120F3A to detect that VIN is present so it can be read by MCU? Since /CD has dual role based on VIN presence, it's important for us to have this information so the MCU can manipulate /CD signal accordingly. Example problem we have is when user disconnects VIN during charging, the /CD stays low (since the charging was enabled) which puts the BQ25120F3A into High-Z mode so the MCU can't communicate with it via I2C. Unfortunately we can't use the /PG pin since we are using it as /MR shifted output.

Is it possible to provide us with some ideas how to reach solution or workaround? Any help would be much appreciated. Thank you very much and have a great day!

Best regards,
Michal

  • 0
    TI__Genius 11885 points

    Hi Michal,

    The typical way for detecting a valid VIN presence previously has been to use the /PG pin as it qualifies the VIN versus both VSLP and UVLO.

    I can think of a couple possible solutions.

    One possible solution can be external circuitry comparing the input voltage to some reference voltage that is above 3.8V (the maximum UVLO voltage). This could indicate whether the charger would be in "Ready" state or HiZ based on a low /CD.

    One other possible solution would be a periodic check of registers. Within this periodic check the MCU could pull /CD up, thus pausing charging or exiting the HiZ state, and reading the status register values. REG 0x01 BIT 6 and 7 would let you know if VIN is below UVLO is above VIN_OV.

    Would either of these be viable workarounds for your application?

    Best Regards,

    Juan Ospina

  • 0 in reply to Juan Ospina
    Prodigy 20 points

    Hi Juan,

    thank you for your reply. For now for our prototype we applied similar workaround as you suggested using periodic setting of /CD pin to check whether the charging starts or the chip enters High-Z state. It works well but we encountered another issue which might be connected. While the battery management is in High-Z mode, it seems to be corrupting communication on I2C bus on our device which is annoying. In general, we don't want to be using HiZ mode at all, since we need /MR functionality at all times. But since the chip enters HiZ as result of the periodic check, it's annoying our I2C doesn't work properly. Do you have any experience with this? Is it possible the limited I2C bus functionality is correlated to HiZ mode?

    Best regards,

    Michal

  • 0 in reply to Michal Šebesta
    TI__Genius 11885 points

    Hi Michal,

    To clarify, the HiZ mode is affecting the I2C communication with other devices on the same bus?

    While our device is in HiZ mode, its I2C communications are disabled so it should not respond to attempts at communication. It shouldn't interfere with other devices on the I2C line. Additionally, for the periodic register checks I would recommend raising /CD first, and waiting about 1.2 mS before communicating via I2C in order to ensure the device has had sufficient time to transition to Active Bat mode.

    Best Regards,

    Juan Ospina

  • 0 in reply to Juan Ospina
    Prodigy 20 points

    Hi Juan,

    yes, it seems to be affecting I2C communication with devices on the same bus. But I can't tell for sure the cause is the battery management. It might as well be some bug in our code or hardware issue or something, we still have to investigate. Anyway, thank you very much for your support. The original question was answered so I think it's possible to close this ticket.

    Thank you very much and have a great day.

    Best regards,

    Michal