BQ40Z50-R2: Questions about BQ40Z50-R2 Learning Cycle

Dear Team ,

This is Arrow Troyson. Could you help to check this issue and we have worked with customer but still pending.

Hope we could get your advice! 

Hello,

Can you please provide a bqStudio log file of the attempted learning cycle and the .gg file of the gauge settings so we can look further into what is causing this?

Regards,

Anthony

82183171data.gg.csv你好，我已经上传了 gg 文件，请帮我看看是什么问题？

0027.82183171data.gg.csv

Hello Anthony ,

Please check this .gg file. Thanks!

HI Anthony,
I uploaded the log file again, please check what's wrong with it.Thanks!reg.log

Dear Anthony ,

Thanks for your further checking

Hi Troyson, Pingyu,

Sorry for the confusion, regarding the log file please provide the entire learning cycle. Since the Update Status moving from 0x04 to 0x05 is dictated by a Qmax update occurring, we will need to see the entire learning cycle to pin point where this issue is occurring. We will look through the .gg file in the mean time to see if anything is off.

Regards,

Anthony

Hi,Anthony.
I tried another charge rest discharge rest cycle but it failed.
The process is as follows:
1. At the end of charging, [FC] is already set, and several key flag bits: QEN=1, VOK=0, RDIS=0, REST=1, ITEN=1, updateStatus=0x04.
The main problem is that UpdateStatus=0x04 is not updated to 0x05.
2. I uploaded the log file and the gg file:
2.1 The gg file before fully discharging and charging is: 202410162data.gg.csv;.
2.2 The gg file after charging is: 202410163data.gg.csv.
2.3 The log file during charging is: reg.log;
Please help to analyze what is the problem?
Thanks! 
Andy202410162data.gg.csv202410163data.gg.csv3365.reg.log

Hi Pingyu,

Thank you for sending the files. In the data sent, the movement of the REST and VOK bits are very abnormal, since these bits do not toggle at the rate being seen below. Is this test being conducted on the bq40z50EVM or a custom PCB? Also, has the firmware been reflashed to the device and tried again?

Regards,

Anthony

Hi,Anthony.
Thank you very much for the guide, we used our own product system board to do the test, I will try again as you suggested.

Regards,

Pingyu

Hi,Anthony.
I'm doing a charging cycle and I'm having a very confusing problem that it keeps not charging when I send the [GAUGE_ EN] command, I don't know what causes this?
The specific details are as follows:
1. Preparation before charging cycle, empty the battery (about 3V or less), at this time the key flag bits: QEN=0, VOK=0, RDIS=1, REST=0, ITEN=0, updateStatus=0x00;
2. After the battery is emptied and rests for 5 hours, [REST] is set, at this time the key flag bits: QEN=0, VOK=0, RDIS=0, REST=1, ITEN=0, updateStatus=0x00;
3. start charging cycle learning, send [GAUGE_ EN] command, at this time the key flag bit: QEN=1, VOK=1, RDIS=0, REST=0, ITEN=1, updateStatus=0x04;
My problem is that when I execute step 3, the power meter does not turn on charging, what is the reason for this?
If I reset it, will it cause the Qmax update to fail and thus the cycle to fail?
I've uploaded the log file when the charging cycle is turned on as well as a screenshot of the register status in the attachment.
Looking forward to your quick reply, thanks!

Regards,

Pingyureg2.log

Hi, Anthony, Another detail is that when BQSTUDIO is running in the learning cycle, an error message "no acknowledgement from device" will be displayed in the lower left corner. What is the reason for this? Will it affect the learning cycle? I uploaded a screenshot showing the specific situation.
Regards,
Pingyu

Hi Pingyu,

PINGYU XU said:

1. Preparation before charging cycle, empty the battery (about 3V or less), at this time the key flag bits: QEN=0, VOK=0, RDIS=1, REST=0, ITEN=0, updateStatus=0x00;

I believe the GAUGE_EN command should be sent at this time before the discharge:

PINGYU XU said:

My problem is that when I execute step 3, the power meter does not turn on charging, what is the reason for this?
If I reset it, will it cause the Qmax update to fail and thus the cycle to fail?

What is the Charge Current Threshold set to and how much current is being applied for the charge? For the gauge to enter charging, more current than the Charge Current Threshold needs to be applied.

PINGYU XU said:

Hi, Anthony, Another detail is that when BQSTUDIO is running in the learning cycle, an error message "no acknowledgement from device" will be displayed in the lower left corner. What is the reason for this? Will it affect the learning cycle? I uploaded a screenshot showing the specific

Are you able to read/write to the device during this time? Is the DA Configuration of the gauge set correctly?

Regards,

Anthony

Hi,Anthony.
Thank you very much for your patient reply.In the Discharge→Rest→Charge→Rest cycle of learning, Updatestatus=0x04 has been successfully updated to Updatestatus=0x05.
But in the next discharge rest session, after 2 hours of rest, Updatestatus=0x05 has not been successfully updated to Updatestatus=0x06. May I ask if it is necessary to let [GAUGE_EN] set before discharge rest every time for Updatestatus to be successfully updated.
I have uploaded the gg file and log file, can you please analyze what is the reason?
Regards.
Andy20241021data.gg.csvreg1.log

Hello,

PINGYU XU said:

But in the next discharge rest session, after 2 hours of rest, Updatestatus=0x05 has not been successfully updated to Updatestatus=0x06. May I ask if it is necessary to let [GAUGE_EN] set before discharge rest every time for Updatestatus to be successfully updated.

No, this is not necessary. GAUGE_EN should only be set on the first discharge.

Regarding the learning cycle, the movement of the VOK and REST bit seems abnormal, however there are sections of the data that do not seem to be read correctly. Can you please confirm the communication connection to the device?

The REST bit does not seem to become set until the end of the 2 hour period as well. is there any standby current being passed during this time?

Can you also tell us how the ChemID was chosen for this cell? Was the GPCCHEM tool used?

Regards,

Anthony

Hi, Anthony.
The ChemID we can get directly from the bqstudio tool, the ID is 7166.
I'm going to reprogram the firmware once and restart the learning cycle and see what happens?
Regards
Andy

Hi Andy,

Please use the GPCCHEM tool below to confirm that this is the best possible match for the cell in use:

https://www.ti.com/tool/GPCCHEM

Regards,

Anthony

Hi, Anthony.
I've got the CHEM ID, the biggest problem is that, after completing Discharge→relax(5hours), when executing Charge→relax, it can't be charged, I don't know what causes this?
I've uploaded the specific log file and screenshots of the configuration parameters, please help me analyze the specific reasons, Thanks.
Regards.
Andy

2308.reg1.log

Hi Pingyu,

Understood, it does not seem like the charge FET is being disabled in the log file, so the gauge should be able to charge at this time. Can you please tell us how much charging current is being used during this time? Is it the same as the previous charge in the log file?

Regards,

Anthony

reg3.logHi, Anthony，
Thank you very much for your kind help, I've found the reason why it's not charging, and it's due to a firmware anomaly in the device.
Learning cycle steps：
S1(DSG)→S2(Relax)→S3(CHG)→S4(Relax)→S5(DSG)→S6(Relax)
I now have a new question, that is, when I proceed to the S5 step, at the same time Updatestatus status is Updatestatus=0x05 during the discharge [RDIS] [RSET] is set to 1, I think that during the discharge [RDIS] and [RSET] shouldn't be set, so will it lead to Updatestatus=0x05 can't be updated to 0x06?
Regards
Andy

Hello,

RDIS becoming set again in during discharge means that resistance updates have been disabled due to an improper resistance calculation. The most common reason for this to occur is that the chemID is not a sufficient match for the cell in use. Please use the GPCCHEM tool below for us to confirm that the chemID in use is a proper match for the cell.

https://www.ti.com/tool/GPCCHEM 

Regards,

Anthony

Hi Anthony.
1. Thank you very much for your help, we have now successfully completed the Learning Cycle and got the SREC file.
However, we have encountered another problem, that is, when we import the new SREC file to the new device, we found that bqStudio can not connect to the device, and the device can not charge/discharge properly, the MOSFETs should not be turned on normally?
2.I was going to upload the SREC file after completing the Learning Cycle to you in the attachment, but the upload format is not supported, so I only uploaded the gg file to you, are you able to see any problem in this firmware?
Looking forward to your reply, thank you very much!
PING YU4cell_1.gg.csv

Hi Ping Yu,

Can you please confirm that there were no interruptions when the new .srec was programmed to the device? Is the same test setup being used from the learning cycle so we can confirm that the device is properly being set up?

Also, when the new .srec is programmed, can you please scope the TS1 pin to see if the gauge is sampling, and if so how long between the pulses?

Regards,

Anthony

Hi Anthony,

Anthony: Can you please confirm that there were no interruptions when the new .srec was programmed to the device? Is the same test setup being used from the learning cycle so we can confirm that the device is properly being set up?

Ping Yu: First of all, I make sure that the programming has not interrupted the device. This time, I deliberately tried to program new.srec into a new device again, but the result was the same as before. After programming, the new device could not connect to bqStudio and could not charge or discharge. However, I noticed a detail that the progress bar was maintained for a few seconds before it was completed. Does this mean that it was not fully imported? If so, why did this happen? In addition, after programming with new.srec, I found through analysis of the hardware circuit that the potential of I2C1_SCL was pulled down to 0.03V. Before programming, the potential of I2C1_SCL was normal at 3.3V. The direct reason for the inability to connect to bqStudio was the pulled down potential of I2C1_SCL. However, the reason for the pulled down potential of I2C1_SCL was due to programming with new.srec. I don't know what exactly caused this?

Anthony: Also, when the new .srec is programmed, can you please scope the TS1 pin to see if the gauge is sampling, and if so how long between the pulses?

Ping Yu: I haven't had time to measure yet, but the new. rec has already been programmed. Looking at the progress bar, it was completed in about 10 seconds. Does this mean it's abnormal.

Also, let me explain to you the process by which I obtained the new.srec:
1.Before the learning cycle, I export the original SREC file of the device for backup;
2.After completing the learning cycle, export the GG file;
3. Burn the original SREC into the device, and then import the gg file after the learning cycle is completed into it;
4. Edited Update Status=02, Cycle Count=0, reset LIFE_TIME, and finally generated new. rec;

Overall, can you identify where the problem lies? Looking forward to your reply, TKS!

Regards,
Ping YU

Hi Pingyu,

PINGYU XU said:

First of all, I make sure that the programming has not interrupted the device. This time, I deliberately tried to program new.srec into a new device again, but the result was the same as before. After programming, the new device could not connect to bqStudio and could not charge or discharge. However, I noticed a detail that the progress bar was maintained for a few seconds before it was completed. Does this mean that it was not fully imported? If so, why did this happen?

As long as bqStudio shows a programming completed successfully message, I believe the .srec was not interrupted. 

PINGYU XU said:

In addition, after programming with new.srec, I found through analysis of the hardware circuit that the potential of I2C1_SCL was pulled down to 0.03V. Before programming, the potential of I2C1_SCL was normal at 3.3V. The direct reason for the inability to connect to bqStudio was the pulled down potential of I2C1_SCL.

Does this still occur if a power on reset is done for the device? All of the information from the programmed .srec should still be on the device if power is removed, so please confirm if this line is still pulled down.

PINGYU XU said:

I haven't had time to measure yet, but the new. rec has already been programmed. Looking at the progress bar, it was completed in about 10 seconds. Does this mean it's abnormal.

Please let us know this information when available. This will allow us to see what mode the gauge is in at this time.

Regards,

Anthony

Hi Anthony,
I know the real reason now, it's because BQ40Z50 entered shutdown mode, but I couldn't find out which protection triggered the shutdown mode. I tried charging to release the shutdown mode, but it still didn't work. I tried other methods, but they didn't work either. Finally, I can only replace the BQ40Z50 chip. Apart from replacing the chip, can you provide a method to release the shutdown mode?
Also, I would like to ask if BQ40Z50-R2 can monitor the device's battery life. If so, where can I find it? thank you.
Regards
PingYu

Hi Ping Yu,

The device should exit shutdown mode if the voltage at the PACK pin is greater than the Vstartup value. 

Bq40z50-R2 can monitor battery life through the State-Of-Health value. More information on this can be found in Section 6.7 of the bq40z50-R2 TRM.

https://www.ti.com/lit/ug/sluubk0b/sluubk0b.pdf?ts=1732292918733&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ40Z50-R2 

Regards,

Anthony

Hi Anthony,
1. Continuing with the issue discussed last time: BQ40Z50 cannot be restored after entering shutdown mode.
I have identified the cause of BQ40Z50 entering shutdown mode: when programming new firmware, the device did not have a battery installed, causing BQ40Z50 to not detect the battery and enter shutdown mode, which resulted in BQ40Z50 and bqStudio being unable to communicate.
However, following your instructions of 'Voltage at PACK pin>Vstartup' and applying an 8.4V voltage to the PACK, the BQ40Z50 still cannot return to normal mode. Currently, the only way I have tried to restore it to normal mode is to replace it with a new BQ40Z50 chip. Could you please help analyze and confirm if the method in the bq40z50-R2 Technical Reference is the solution to the situation mentioned above?
  
3581.reg.log3652.4cell_1.gg.csv

2. Another issue is that when I programmed the firmware for completing the Learning Cycle to a new device, I found that the charging efficiency was very slow. When I plugged in the power, the battery meter displayed that the device was charging at a rate of 130mA all the time, which is obviously abnormal. How do I set the charging rate? Is this BQ40Z50 automatic adjustment control?
I have uploaded the log file and GG file during charging to the attachment. Could you please analyze if there is any configuration issue?

Regards
Andy

Hi Andy,

PINGYU XU said:

However, following your instructions of 'Voltage at PACK pin>Vstartup' and applying an 8.4V voltage to the PACK, the BQ40Z50 still cannot return to normal mode. Currently, the only way I have tried to restore it to normal mode is to replace it with a new BQ40Z50 chip. Could you please help analyze and confirm if the method in the bq40z50-R2 Technical Reference is the solution to the situation mentioned above?

Just to confirm, at this time where a voltage greater than Vstartup is applied, are the cells or power source connected to the device? Is proper power reaching the BAT pin?

PINGYU XU said:

Another issue is that when I programmed the firmware for completing the Learning Cycle to a new device, I found that the charging efficiency was very slow. When I plugged in the power, the battery meter displayed that the device was charging at a rate of 130mA all the time, which is obviously abnormal. How do I set the charging rate? Is this BQ40Z50 automatic adjustment control?

How is the charging being attempted here? Is a charger IC being attached to the PACK connection?

Regards,

Anthony

Hi Andy,

PINGYU XU said:

At this time, the device is connected to both the battery and an external power supply, and the measured BAT PIN voltage of the battery is 7.8V.

Understood, is this being checked with bqStudio? If power is removed from the device and re-applied, is there any difference?

PINGYU XU said:

I am using an adapter power supply to charge the device and have confirmed that the charger IC and PACK are connected.

The bq40z50 should not change the current that is being applied at the PACK connection. I believe this has to do with the charger.

Regards,

Anthony

Hi，Anthony
  Anthony said:
Understood, is this being checked with bqStudio? If power is removed from the device and re-applied, is there any difference?

1.If power is removed from the device and re applied, there is still no communication between BQ40Z50 and bqStdudio. The exception encountered now is: "When programming new firmware for BQ40Z50, as long as the device is not equipped with a battery, it will enter shutdown mode and cannot be restored. The only way I am currently trying to restore normalcy is to replace the BQ40Z50 chip with a new one. Have you not encountered such a case?

2.Now we have encountered a new anomaly. Our device is designed with 2 batteries. When the battery is around 2600mV, as shown in the attached screenshot, the XCHG flag is set and the CHG flag is set to zero. Does this mean that charging is disabled, causing the inability to charge? When I plug in the adapter power source to charge, the register remains unchanged and cannot be charged. I think when the battery enters a low voltage state, the device should automatically enter a charging state when connected to the power supply, but it never enters a charging state and cannot be restored. I don't know why this is?I confirm that the charger power supply is normal.

Regards
Andy

Also, I have attached the relevant protection settings. Did the low voltage of the battery trigger the protection mechanism, causing the inability to charge？

Could you please help analyze if the settings are correct?

Hi Andy,

PINGYU XU said:

1.If power is removed from the device and re applied, there is still no communication between BQ40Z50 and bqStdudio. The exception encountered now is: "When programming new firmware for BQ40Z50, as long as the device is not equipped with a battery, it will enter shutdown mode and cannot be restored. The only way I am currently trying to restore normalcy is to replace the BQ40Z50 chip with a new one. Have you not encountered such a case?

Does this occur when any .srec is programmed to the device or just when the pulled golden .srec is programmed? Can you share the exported .srec so we can check from our side?

PINGYU XU said:

2.Now we have encountered a new anomaly. Our device is designed with 2 batteries. When the battery is around 2600mV, as shown in the attached screenshot, the XCHG flag is set and the CHG flag is set to zero. Does this mean that charging is disabled, causing the inability to charge? When I plug in the adapter power source to charge, the register remains unchanged and cannot be charged. I think when the battery enters a low voltage state, the device should automatically enter a charging state when connected to the power supply, but it never enters a charging state and cannot be restored. I don't know why this is?I confirm that the charger power supply is normal.

In the images, would it be possible to show the SafetyStatus() and PFStatus registers lower on the screen or take a log at the time of occurrence? This would give us a better idea of what is disabling the charge FET.

Regards,

Anthony

Hi Anthony,

Anthony said:

Does this occur when any .srec is programmed to the device or just when the pulled golden .srec is programmed? Can you share the exported .srec so we can check from our side?

Not only golden. rec, but also other. rec files can experience this situation. Because the golden. rec file format does not support uploading, I have converted it to TXT format and sent it to you. Could you please check where the problem lies?

SREC_20241105_4cell.txt

Anthony said:

In the images, would it be possible to show the SafetyStatus() and PFStatus registers lower on the screen or take a log at the time of occurrence? This would give us a better idea of what is disabling the charge FET.

Regarding the log of abnormal charging, there was an exception today and the log was lost. I will send it to you again next time. In addition, regarding the status of SafetyStatus () and PFStatus registers, I have recorded a video and a screenshot. The IN flag marked on the screenshot was set, and then the charging stopped. Please analyze where the problem lies?

Regards,

Andy

Hi Andy,

PINGYU XU said:

Not only golden. rec, but also other. rec files can experience this situation. Because the golden. rec file format does not support uploading, I have converted it to TXT format and sent it to you. Could you please check where the problem lies?

Thanks for sending this, I was able to successfully program it to one of our devices, removed power to enter shutdown, and exit with no issue. Based on this, I do not believe it is an issue with the .srec file. 

PINGYU XU said:

"When programming new firmware for BQ40Z50, as long as the device is not equipped with a battery, it will enter shutdown mode and cannot be restored.

I am still slightly unclear about this statement. If the device does not have a battery attached, it will always enter shutdown and not exit because of the BAT Voltage.

Regarding the charge being stopped, it seems like the PCHGC protection is being triggered, in turn disabling the charge since [XCHG] = 1 in the trip actions below:

Regards,

Anthony

Hi Anthony,
1."When programming new firmware for BQ40Z50, as long as the device is not equipped with a battery, it will enter shutdown mode and cannot be restored."

This means that when programming new firmware for BQ40Z50, if the device is not connected to the battery, i.e. BQ40Z50 is not connected to the battery, during the programming process, BQ40Z50 will enter shutdown mode and cannot be restored.

Anthony said:

Regarding the charge being stopped, it seems like the PCHGC protection is being triggered, in turn disabling the charge since [XCHG] = 1 in the trip actions below

In this case, after charging at a rate of approximately 130mA for a period of time, PCHGC protection will exit until the battery is charged to around 3000mV, at which point the device will no longer charge. I'm puzzled why the charging stops. Normally, it should continue charging until fully charged. I have sent you the log of the charging process, please check the specific reason through the log.

1050.reg.log

• I have another question about BQ25710, which is that when I supply power through the USB_C interface, I need to reset the device once before it can start. Normally, the device should start when I connect the VBUS power supply. Is this related to the configuration of BQ25710? I will provide you with the design diagram of the power supply part of the device for your reference, including whether the overall circuit design of BQ40Z50 is reasonable?
• 300VT_MAINPOWER_sch.pdf

Regards,
Andy

Hi Andy,

PINGYU XU said:

This means that when programming new firmware for BQ40Z50, if the device is not connected to the battery, i.e. BQ40Z50 is not connected to the battery, during the programming process, BQ40Z50 will enter shutdown mode and cannot be restored.

Understood, the gauge must be powered on when programming. I do not believe we evaluate the device for when programming is done with no power applied.

PINGYU XU said:

In this case, after charging at a rate of approximately 130mA for a period of time, PCHGC protection will exit until the battery is charged to around 3000mV, at which point the device will no longer charge. I'm puzzled why the charging stops. Normally, it should continue charging until fully charged. I have sent you the log of the charging process, please check the specific reason through the log.

Thank you for sharing the log. While looking through this, I do not see the PCHGC protection trigger based on the SafetyStatus register values. Do you have a log of the point where this triggers so we can see why the charge FET is being disabled?

PINGYU XU said:

I have another question about BQ25710, which is that when I supply power through the USB_C interface, I need to reset the device once before it can start. Normally, the device should start when I connect the VBUS power supply. Is this related to the configuration of BQ25710? I will provide you with the design diagram of the power supply part of the device for your reference, including whether the overall circuit design of BQ40Z50 is reasonable?

Please post a new thread with the BQ25710 to allow one of our charger team members to offer their insight. I will look into the bq40z50 section of the schematic at this time.

Regards,

Anthony