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.

LM66100: LM66100 circuitry for Battery plus external supply sharing review

Part Number: LM66100

Hi Guys.

Good day. Please help to check the customer's circuitry for Battery plus external supply. 

I have copied and paste the details below for clearer information.

I was supplied with an electronic prototype device from a supplier which uses two LM66100 in order to run of two packs of 2 AA batteries and can alternatively be powered through a usb connection. The devices seem to show intermitted malfunctioning, looking similar to a brownout and we experienced one battery leaking while in use. We are unable to locate the root cause in the software, hence I would like to check whether the power-supply circuitry was designed acceptable design around the LM66100.  I am attaching the schematics of the power-sharing. It looks similar to the application in the data sheet but has a distinctive difference where the usb power cuts off the power supply by the batteries. Could you please doublecheck if that is feasible and give us a feedback? 

Thank you in advance for the support. 

Best regards,

Jonathan

  • Hi Jonathan,

    Is the setup here to share between two different battery packs? LM66100 is not built for any form of load sharing. While you can supply two LM66100's in parallel from a single battery, two source load sharing is not recommended. 

    When working with two sources, the device is built to OR between the two sources and always pass the higher of two sources to the output while blocking any current from the lower source. The LM66100s here seem to be set up in RCB and not for OR-ing. If the system requires OR-ing, please set the device up as described by Figure 15 or Figure 17. Do note that if you require two sources of the same voltage, the OR-ing will not work and you need a PowerMUX device which can help set priority.

    Thanks,

    Shreyas

  • Hi Shreyas,

    Thank you for your response. Here is the follow up question from our customer.

    The system is supposed to be powered by 4xAA batteries, split into 2x 2xAA in parallel. I believe the designer decided to run 2x2 batteries in parallel because 4xAA in series would exceed the maximum input of the TPS63031buck/boost converter that is used after the LM66100s.
    If I understand you correctly the intention in this case should be a power-sharing (OR-ing), which is not recommended with the LM66100. But the schematics are not connected in order to achieve OR-ing, but for the RCB application as of chapter 8.3.2 of the datasheet but with 2 circuits in parallel. Could you please explain to me what effect our current design has, how you would expect it to fail and why it is not recommended?

    Thank you for the support. 

    Best regards,

    Jonathan

  • Hi Jonathan,

    The device works by comparing the voltage between VIN and CE. LM66100does not regulate forward voltage, it turns ON and OFF depending on these voltages. When connected in RCB, the device turns off when CE (vout) rises above VIN. There is no way to modulate resistance of the device to cause a perfect split of current through them. This will result in a situation where one source will feed into the other source through LM66100 as there will always be one dominant source. The RCB will not work until the reverse current is sufficient to cause a voltage difference of 35mV or so. Due to the low ON resistance, constant reverse current will flow through the device which could cause issues to the device and to the source. 

    In OR-ing, one device is ON and the other device is OFF. In no situation are both devices ON at the same time. The reference voltage for OR-ing is not the output voltage but rather the status of the secondary supply.

    Unless I am misunderstanding your setup, the input pins for the LM66100s are supplied by different batteries and hence different nodes and this would effectively put it in a load sharing topology.

    Thanks,

    Shreyas