BQ40Z80: Discharge issue.

Hi Reed,

Was there a reset or a hardware protection that went off at that time? Was the pack physically removed from the device?

If possible, please share the log file along with the .gg file of the gauge settings.

Regards,

Anthony Baldino

Hi,Anthony Baldino，

The problem occurred during the discharge test, the pack was not removed throughout the test, and the BQ40Z80 did not have hardware protection. 

The attachment is the data log read by MCU from BQ40Z80, and the gg file of BQ40Z80.  Log_117.xlsx5047.BQ40Z80.gg.csv

Hi Jack,

Thank you for sending those files. Is the .gg file sent from the device after this instance occurred? The MCU log read did not capture many of the registers that would give us an idea of what was occurring within the gauge at this time, so if we can get the log file of the device after the instance we can look into the Lifetime values to try and get a better idea.

Regards,

Anthony Baldino

Hi,Anthony Baldino:

Thank you for your reply. The gg file sent last time is the configuration file after the programming is completed. Because this problem occurred occasionally and only once in more than 100 cycles, the probability of occurrence was not high,so only the log read by the MCU was recorded at that time, and the device data log was not recorded through Battery Management Studio.The gg file uploaded this time is a newly read configuration file, which contains Lifetime data.BQ40Z80-20240805-1013.gg.csv

Hi Jack,

Thank you for sending the other .gg file over. Based on the lifetime parameters, it seems like there are a significant amount of CUV protection events that have been triggered, however I do not believe that this relates to the issue above since the voltage of the cells are not close to the CUV threshold. 

One thing to look out for is that in the current .gg file, the Safety Overcurrent in Discharge protection threshold is set to -10A, when it seems like you are discharging at a greater rate.

It is difficult to determine a root cause for this issue, however it seems like the gauge goes through some sort of partial reset since the only values altered in that moment are the measured values (voltage and temperature), however the calculated values are still fine. Are the cells permanently connected to this board or are they removable?

Regards,

Anthony Baldino

Hi,Anthony Baldino:

The battery is tested in a continuous cycle from full to empty, triggering CUV protection at the end of each discharge.

In order to extend the data range,I configured the relationship between the actual value and the measured value to be 4 times, so the actual current needs to reach -40A to trigger the discharge overcurrent protection.

I also think that BQ40Z80 has a reset, but I cannot find the reset reason, so I ask you for help.

The positive and negative electrodes of the battery pack are welded to the PCB board through the power cord, and the battery cell is connected to the PCB board through the cable and connector, and then the battery is packed through the shell, which is non-removable.

Hi Jack,

Can you please tell us what registers the Protect_Status and the Other_Status register reads correlate to in the log file? Without a bqStudio log file depicting this issue so we can look at all of the actions taken from the device registers, it is difficult to determine what could be causing the reset here.

Regards,

Anthony Baldino

Hi,Anthony:

Protect_Status is 16-bit data (bits 0 to 15). It is displayed in the Log format in Hex format(For example, 140 means 0x140). The value is defined as follows:

Bit 0 of Protect_Status is not related to BQ40Z80.

Bit 1 of Protect_Status corresponds to the CUV of the Safety Status of BQ40Z80.

Bit 2 of Protect_Status corresponds to the Safety Status of the BQ40Z80 (OCD1 | 0CD2 | AOLD).The relationship between the three status bits is or. If any bit is 1, the bit 2 of Protect_Status is 1.

Bit 3 of Protect_Status corresponds to the OTD of the Safety Status of BQ40Z80.

Bit 4 of Protect_Status corresponds to the UTD of the Safety Status of BQ40Z80.

Bit 5 of Protect_Status corresponds to the ASCD of the Safety Status of BQ40Z80.

Bit 6 of Protect_Status corresponds to the OTD of the Safety Status of BQ40Z80.

Bit 8 of Protect_Status corresponds to the COV of the Safety Status of BQ40Z80.

Bit 10 of Protect_Status corresponds to the Safety Status of the BQ40Z80 (OCC1 | OCC2 | ASCC).The relationship between the three status bits is or. If any bit is 1, bit 10 of Protect_Status is 1.

Bit 11 of Protect_Status corresponds to OTC of the Safety Status of BQ40Z80.

The other bits of Protect Status are not related to BQ40Z80.

Other_Status is a 16-bit data (bits 0 to 15), which is displayed in Log format in Hex format(For example, 140 means 0x140). The other_status is defined as follows:

Bits 0 to 2 of the Other Status are not related to BQ40Z80.

Bit 3 of Other_Status corresponds to the DSG of Operation Status of BQ40Z80.

Bit 4 of Other_Status corresponds to the CHG of Operation Status of BQ40Z80.

Bit 6 of Other_Status corresponds to FC of the Battery Status of the BQ40Z80.

Bit 7 of Other_Status corresponds to the PCHG of Operation Status of BQ40Z80.

Next, I will use BQ Studio to collect data, but since this problem happens occasionally, more than 100 cycles only happen once, so I do not know when I can get the data log when the reset happened again.

Hi Jack,

Thank you for giving us the bit definitions, we will use this to look deeper into the previous log file.

Please let us know when the bqStudio log for this occurrence is available.

Regards,

Anthony Baldino

Hi,Anthony:

Thank you for your help. If you find anything new, please let me know.

If I get the reset data log again, I will upload it here.

Hi Jack,

Understood, thank you!

Regards,

Anthony Baldino