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

BQ40Z50: External balancing limitation with N-Mosfet (move cells up a slot is a solution?)

Thomas Magdahl
Prodigy 20 points
Part Number: BQ40Z50
Other Parts Discussed in Thread: BQ76905, BQ76200, EV2500, BQ25792, BQSTUDIO

Tool/software:

Hi,

 

Sorry for the repost, but the title (web-form glitch or error of mine) got pretty useless (BQ40Z50: BQ40Z50) for any help hope.

Tried to edit it, but could not figure out how, so if an administrator can delete it, please do it (my apologies).

 

I used BQ76905 for my gage-balancing design and planned to include BQ76200 to move the charge and discharge mosfets out from VSS (high side protection).

Therefore, I already ordered the external balancing mosfets (Rohm RU1J002YN) that where OK for the BQ76905 (that has VC0), so I have to stick to them, not to lose them.

 

Recently I discovered BQ40z50, that allows me to merge both BQ76905 and BQ76200, so I want to use it for a two cell LiFePo4 battery (10A charge). And it requires a very low current sensing resistor which I like too.

 

Do I have to connect the cells, filling up the VC1-VC4 slots from ground up (fill the slots sequentially) and short the remaining upper ones and stick to P-Mosfets (forget about the N-Mosfets I already bought), or can I put the cells at any other higher "slot", making the correct configurations internally by means of I2C?

Will that allow me to overcome the restriction of the lowest cell not having the lower return path (VC0), where to put the resistor that “builds” up the voltage for the external N-Mosfet gate, with the internal mosfet closing?

I do not want to put one cell between VSS and VC1, because I have no way to excite the gate of the external N-mosfet that I already ordered. I hope I am not wrong in my diagnostics. PCB still in the works.

 

Two more questions:

  1. I downloaded Battery Management Studio, thinking it would generate code to ease the I2C configuration, but it seems it must connect to the chip (cable, interface or DEV-KIT?).

Where can I find out how to include that capability into my design?

 

  1. What are the R1 and R2 (are there more Rx?) postfix in the part?

 

Regards,

 

Thomas Magdahl

  • 0
    TI__Mastermind 28450 points

    Hi Thomas,

    Thomas Magdahl said:
    Do I have to connect the cells, filling up the VC1-VC4 slots from ground up (fill the slots sequentially) and short the remaining upper ones and stick to P-Mosfets (forget about the N-Mosfets I already bought), or can I put the cells at any other higher "slot", making the correct configurations internally by means of I2C?

    Yes, the spots will need to be filled sequentially. The firmware does not have the ability to discern the different placements, so it is based on the amount of cells in series from VC0 onwards. If a VCX input is not in use, it can be shorted up to VC4.

    Thomas Magdahl said:
    1. I downloaded Battery Management Studio, thinking it would generate code to ease the I2C configuration, but it seems it must connect to the chip (cable, interface or DEV-KIT?).

    Where can I find out how to include that capability into my design?

    Battery Management Studio requires the usage of an EV2500 Interface adapter to communicate to the part. This is required since the device will need to be loaded with a chemID, which can only be done with Battery Management Studio.

    https://www.ti.com/tool/EV2500 

    Thomas Magdahl said:
    What are the R1 and R2 (are there more Rx?) postfix in the part?

    These are version updates. I would recommend using the R2 part and programming it with the R5 firmware, which is our most up to date FW.

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 20 points

    Hi Anthony!

    Thanks for all the input. Clarified all those doubts.

     

    In the mean time I was searching for another chip that would have:

    1) High side protection

    2) That VC0 was still available and that it could manage 2 cells

    3) Accept very low Rs values (current sense) so PACK GND will be not very different from BAT GND

    4) Be able to manage it on I2C

    5) Small chip/footprint (Avoiding TSSOP)

     

    I could not find one. Maybe you can confirm my conclusion or point one out?

     

    I have new questions. Not sure if they can be part of this thread or if I have to post them separately? Please tell and I will do!

     

    1. If I do not use the EV2500, can I still do all the programming with I2C or will it be a nightmare and it is almost mandatory/wise? My naive idea was to change a couple of registers using the I2C bus and leave almost all others in the default value Blush
    2. I will use the BQ25792 charger. Will be on the same I2C bus. I imagine EV2500 can distinguish them apart and manage both?
    3. If there are other I2C peripherals on the bus, I assume they will not conflict as they will have different ID’s?
    4. If BQ40z50 detects that the cells are candidate for PRE-CHARGE current (Only opens the P-Mosfet at PCHG and maybe N-Mosfet at CHG), the BQ25792 charger will “find out” that it can not push the current it expects to use. Might it rise the voltage to reach the current it was programmed to deliver or will it stick to the Narrow voltage DC (NVDC) power path management? I am asking this, to make the correct decision on the Pre-Charge series resistor, so I use a safe precharge current.

     

    Thanks

     

    Thomas

    p.s. I will be back on Monday so this is not urgent.

  • +1 in reply to Thomas Magdahl
    TI__Mastermind 28450 points

    Hi Thomas,

    Thomas Magdahl said:

    In the mean time I was searching for another chip that would have:

    1) High side protection

    2) That VC0 was still available and that it could manage 2 cells

    3) Accept very low Rs values (current sense) so PACK GND will be not very different from BAT GND

    4) Be able to manage it on I2C

    5) Small chip/footprint (Avoiding TSSOP)

     

    I could not find one. Maybe you can confirm my conclusion or point one out?

    All of our multi-cell devices require the VC0 to be connected to the cell, so I believe this may confirm your conclusion.

    Thomas Magdahl said:
    If I do not use the EV2500, can I still do all the programming with I2C or will it be a nightmare and it is almost mandatory/wise? My naive idea was to change a couple of registers using the I2C bus and leave almost all others in the default value

    For the initial configuration, it is mandatory since the chemID needs to be programmed, which can only be done on bqStudio. For production and application, the programming can be done via a host using the I2C bus.

    Thomas Magdahl said:
    I will use the BQ25792 charger. Will be on the same I2C bus. I imagine EV2500 can distinguish them apart and manage both?

    You would need two different EV2500s if you are trying to run them simultaneously, however if you are using them 1 by 1 the EV2500 can differentiate.

    Thomas Magdahl said:
    If BQ40z50 detects that the cells are candidate for PRE-CHARGE current (Only opens the P-Mosfet at PCHG and maybe N-Mosfet at CHG), the BQ25792 charger will “find out” that it can not push the current it expects to use. Might it rise the voltage to reach the current it was programmed to deliver or will it stick to the Narrow voltage DC (NVDC) power path management? I am asking this, to make the correct decision on the Pre-Charge series resistor, so I use a safe precharge current.

    I believe this might have to be posted on the chargers thread for clarification on how the charger will work.

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 20 points

    Thanks Anthony for all the help!

     I concluded that if my PCB has an I2C bus where BQ40z50 and BQ25792 are connected, plus some other non conflicting I2C devices, and that I am able to "tell" the system CPU not to engage into I2C conversations (suspend it as a master for a while), I could connect EV2500 to that bus and either change/configure first one of them and then the other (using only a single EV2500 and selecting the desired BQxxxxx chip from the PC EV2500 interface). At some moment I was thinking of using a multimaster arbiter like NXP’s PCA9641, but I suspect EV2500 might dislike the delays in bus access or its strange behavior during master collisions. Anyway, the EV2500 intervention will be only very few times so an arbiter is overkill.