BQ40Z50-R2: IC crashed after WatchDog communication event

Hi Ran,

Can you please tell us how the gauge is being communicated to whether it be EV2400 or a custom MCU? If a custom MCU is being used, can you please confirm whether the MCU supports clock stretching?

Regards,

Anthony Baldino

Dear Anthony,

thanks for replying.
we use an FPGA EP4CE15F17I7N by Altera (Intel).

we can see that CLK stretching occur throughout the part when there is normal communication exchange (first 3 sec).

there is no issue when using EV2400 and a PC.
we tried to give external power while reading, and the communication signal is not interrupted at all.

we think there is maybe an external interruption, like noise or a spike, but it is clear that the communication is interrupted, and the watchdog is reacting, but why does the BQ40z50 close the DSG FET? or maybe it goes into RESET? while an old BQ20z655 does not?

tell me if you need to see schematics or gg.csv.

Ran

Hi Ran,

Understood, thank you for clarifying.

Ran Aloni said:

there is no issue when using EV2400 and a PC.
we tried to give external power while reading, and the communication signal is not interrupted at all.

Knowing this, are there any differences seen in the structure between the I2C commands sent by EV2400 and the FPGA?

Ran Aloni said:

we think there is maybe an external interruption, like noise or a spike, but it is clear that the communication is interrupted, and the watchdog is reacting, but why does the BQ40z50 close the DSG FET? or maybe it goes into RESET? while an old BQ20z655 does not?

If the discharge FET is being closed, there could also potentially be a protection being triggered. I understand that it is impossible to get a log file when the communication is not working, however if you could pull a .gg file after this happens using the EV2400 with the device still powered so it does not reset that could help. If this isn't possible, we can still take a look at the .gg file and schematic to see if there is something occurring there.

Regards,

Anthony Baldino

Hi Anthony,

thanks for helping us.

the reading is perfect for the first 3s.
the FPGA is asking for 18 commands, while the EV2400 reads many commands.
FPGA reading is fast with 600us between package of commands.
~40uS between command to command depends of availability.

we translate the read out, and the current is -283mA and "battery status" register is normal (00C0) just before.
so not likely a protection event.
Opgal_BMS A2.pdfTN3S2P-GA-01 A2.gg.csv

sch and GG.CSV attached.

thanks

Ran

Hi Ran,

Thank you for sending the schematic and .gg file, we will take a look into them.

Regarding the packet structure, has the rate that the commands being sent at been attempted to be slowed down to see if there was any difference in the result?

Also, after the three seconds of the good readings, are there any breaks in the structure of the commands seen below?

Regards,

Anthony Baldino

Dear Anthony,

Currently, it is not easy for us to change the timing from the FPGA side,
but if we can rule out all other issues, we will go for that.

the communication protocol looks exactly like in the diagram you sent, after 3s,
it changes and the communication gets scrambled.
when we use an external source to supply the voltage to the system, the communication line recovers and start a clean communication for exactly 3s, you see an interruption but it recovers.

if you can rule out anything that comes from the firmware setup (GG.CSV),
we will concentrate on exploring the timing issue.

Ran

Hi Ran,

Is there a possibility that the gauge could potentially be entering shutdown at this time? Can you please tell me if the voltage being seen across the attached cell is low enough to break this threshold?

Regards,

Anthony Baldino

Hi Anthony,

do you mean if the cell voltage is lower than than the minimal voltage ?
no the battery is relatively charged cells are at ~4.0V per cell, also, we didn't notice any different behavior in different SoC.

like we mentioned, we see the voltage drop entirely during the error.

do you think that any of the parameters in the GG.CSV can explain such behavior?

Ran

Hi Ran,

Ran Aloni said:

do you mean if the cell voltage is lower than than the minimal voltage ?
no the battery is relatively charged cells are at ~4.0V per cell, also, we didn't notice any different behavior in different SoC.

Correct, I was referring to the Shutdown voltage parameter. However, it seems like this is not occurring if the cells are charged.

Ran Aloni said:

like we mentioned, we see the voltage drop entirely during the error.

I see above that it is stated that the DSG FET closes at this time, however where is this voltage drop being measured? Or is this based on the reading from the gauge at this time?

Regards,

Anthony Baldinoo

Dear Anthony,

we measure the voltage drop on the battery output via scope.



you can see the 780ms drop.
seems a bit fast for protection and too long for hardware short circuit / AOLD.
this is why we suspect the chip is crashing at rebooting.

Ran

Hi Ran,

Just to confirm, when you say the voltage drop is measured from the battery output, is this from the PACK+ connection of the gauge?

To confirm the internal process of the chip, can you please use a scope to see what is occurring within the TS1 pin of the device during this time? In normal mode, there should be pulsing of around 1s. This will give us a better idea of what is happening within the gauge.

Regards,

Anthony Baldino

Dear Anthony,

thanks for helping.



this is a snap shot of the communication lines and TS1.
you can see the pulsing every 1s and some sort of spike around the communication failure,
then it return to normal.

Ran

Hi Ran,

Thank you for sharing, based on the image above it does seem like there is a reset occurring. As you said before, the current PCB you have communicates fine with EV2400 and bqStudio, are there any differences to the communication line or PCB when tried with the FPGA?

Also, you said that the error always occurs 3 seconds into the reads. Each time this is tested, is the same order of commands being sent and is it failing upon the same command each time?

Regards,

Anthony Baldino