BQ40Z50-R2: BQ40Z50-R2 Cycle Count Not Updating in 1S1P Design

Hi Tom,

Would it be possible to receive the NCA103450 re-golden 20250125 log? The received log file in the zip file only has the NCA103450 re-rb 20250125.log where the cycle count is not updating.

Regards,

Anthony

Hi Anthony,

Convert to .csv file

Hi Tom,

Would it be possible to run the two charge/discharge cycles with the device programmed with the .srec post learning cycle with the Qmax Passed Q value logged? This would allow us to see the passed charge that the gauge is observing during the discharge, which is where the gauge will update the cycle count. This was taken on the golden image log as well.

Regards,

Anthony

Hi Anthony,

The attachment contains the charge and discharge log for 2 cycles. All detailed data has been selected and recorded. The Qmax Passed Q value calculation is correct, but the cycle count has still not updated. Please check the attachment.

Thanks!

Hi Tom,

Thank you for sending this log file, based on this file and the golden file, it seems like the passed charge accumulation is not resetting to 0 after each charge/discharge cycle. Would it be possible to run the same test with the Passed Charge logged with there being a relax period between each charge/discharge?

2cycle test:

golden:

Regards,

Anthony

Hi Anthony,

We have started testing with long rest periods after both charging and discharging. However, there is a major concern: under normal circumstances, parameters should not be affected by whether the battery rests. According to the IC datasheet, the cycle count is only influenced by the CCT setting and cycle threshold. However, in our tests, no matter how we modify these settings, the cycle count does not update. Could there be a software bug in the BQ40Z50 when used in a 1-series configuration, preventing the cycle count from updating even after long rest periods?

The current challenge we are facing is that the exported parameters do not reflect cycle count updates, making it impossible to send samples to customers for testing. Additionally, in future mass production and real-world customer usage scenarios, it is impractical to rely on resting periods before use.

Thanks!

Hi Anthony,

Here are the steps for the retest:

1. Write a clean Ver 2.13 version SREC file to the IC.
2. Write GG parameters + Cell ID + Calibration.
3. Perform the golden process: charge the battery, rest for 3 hours, discharge the battery, rest for 5 hours.(At this point, the cycle count updates.
4. Export the SREC file.
5. After exporting, perform two fast charge/discharge cycles, with only 10 minutes of rest in between.(The cycle count no longer updates.)
6. Perform the golden process again: charge, rest for 3 hours, discharge, rest for 5 hours.(The cycle count still does not update.)

Please refer to the attached file: NCA103450 re-test 20250209.zip.

Based on our testing, when using clean parameters and performing charge/discharge via the golden process, the cycle count updates correctly.
However, once the SREC is exported or a mass production SREC is reprogrammed, the cycle count no longer updates.

This issue does not appear in 2S to 4S products.
For actual mass production and customer use, this behavior is problematic.

Could you please confirm if this is due to a firmware bug?
(Is it related to the watchdog or some hidden parameters causing the issue?)

Thanks!

Hi Tom,

Thanks for sharing this information, we will check with the firmware team regarding this. I would also like to confirm some other things:

1) In the new log file, it seems like again that the passed charge does not reset correctly after the step 5. Would it be possible to load the srec, then perform the golden cycle to see if these fast charges are causing some issue?

2) Would it be possible to try this with the most recent version of the firmware found below? If this is an issue with the firmware, then there is a chance it was covered in an update.

https://www.ti.com/tool/download/BQ40Z50-DEVICE-FW/R5-V5.05

Regards,

Anthony

Hi Anthony,

This does seem to be an F/W issue.

After verification testing, with FW version Ver 1.06, performing the following steps:

1. Recreate the golden image
2. Export parameters
3. Reflash SREC
4. Calibration
5. Charge and discharge

The cycle count updates successfully.

However, when using FW versions 2.08, 2.11, or 2.13, the cycle count does not update, regardless of the testing method.

Tested the latest R5 FW, but the cycle count still does not update.

Have you confirmed with the F/W team? Do they have any recommendations or insights regarding this issue?

Thanks!

Hi Tom,

If possible, please share the .log file of this being ran on the V1.06 firmware version so we can confirm whether this is being caused by the firmware.

Regards,

Anthony

Hi Anthony,

Please see the attachement.

Thanks!

Hi Tom,

Thanks for sending these files over, while comparing the two, it seems like there is a differential in the amount of passed charge during discharge between the two, where the old file's passed charge is around ~2100mAh, while this new log file is about ~2500mAh. Is there anything different being done in these test such as different cells, calibration, etc that might cause something like this?

Regards,

Anthony

Hi Anthony,

The actual product specification is 2500mAh, so the last file we provided contains the final parameter settings that the customer intends to use for mass production.

The previous files were based on a 2270mAh cell, which was tested using a different circuit board for various validations. When the issue initially occurred, we was unsure whether it was caused by the circuit board or parameter settings. Therefore, we conducted cross-validation tests using the 2270mAh cell and a different board.

Moving forward, please focus on the 2500mAh configuration for any improvements. If any additional test data is required, please let me know.

Thanks!

Hi Tom,

Sorry for the delay, it seems like from my end E2E will not allow me to access the previously sent files (their links are not seen either), would it be possible to re-share the V1.06 log file + .gg file, and the V2.08 completing an identical charge-relax-discharge cycle with ample relax time for the gauge to reset the passed charge measurements. If we have data with them in identical situations and one updating CC and the other not, I can take it to our firmware team to confirm whether this is an internal issue.

Regards,

Anthony

Hi Anthony,

I will email you the files.

Thanks!