Tool/software:
Hello,
We've been using a BQ76942 for quite a while in a battery management system setup. At this point, it looks like nearly everything is working as it should, in that all communications, monitoring, control seems to be configured and working properly. A host STM32 device is interacting via I2C and GPIO pins with the BQ76942.
I do have the CFETOFF and DFETOFF lines configured to be used as those functions, as I wanted to have the ability to do immediate protection functions if needed.
The code to turn on the FETS is this:
// reset GPIOs first
HAL_GPIO_WritePin(DFET_OFF_GPIO_Port, DFET_OFF_Pin, GPIO_PIN_RESET);
HAL_GPIO_WritePin(CFET_OFF_GPIO_Port, CFET_OFF_Pin, GPIO_PIN_RESET);
// write ALL FETS ON
uint16_t command;
uint8_t TX_Reg[2] = {0x00, 0x00};
command = ALL_FETS_ON;
//TX_Reg in little endian format
TX_Reg[0] = command & 0xff;
TX_Reg[1] = (command >> 8) & 0xff;
I2C_WriteReg(0x3E,TX_Reg,2);
What I'm seeing is that with the battery pack on the bench and calling this function, the output turns on fairly fast (40 ms) - although this is still puzzling why it takes that long.
When the battery pack is attached to a bus with another voltage source (e.g. putting a battery in parallel with another), and commanded to turn on, it seems to take up to 1.8 seconds to come on. And this is coupled with the fact that the other battery is told to shut off, so the bus voltage drops first, before the new battery turns on. It's almost as if the voltage on the Pack/LD pins is preventing it from turning on somehow.
Is there something fundamental that I'm missing about the turn-on time and being able to turn on while already connected to a voltage source?
The attached image shows the FET circuitry. There is no precharge or predischarge path or functionality configured either. 