BQ40Z80: SMBus communication error with clock streching

Hello.

I add some information.

All data can be read correctly but stop condition never appear until timeout of 25ms.

The behavior w/PEC and w/o PEC seems the same.

Only 0x16 0x44 0x02... command complete quickly.

Why the device stretch the clock although all data was sent correctly?

We would like to know the cause of this phenomenon, and how to return to normal operation.

regards,

Hiro.

Hi 

Additional information.

When I communicated the defective product with the Battery Management Studio and checked the bit registers, I found that EC2, EC1, and EC0 in the battery status were bit high.

From the datasheet this is an unknown error.

I'll attach a photo.

Best Regards,

Masashi.

Hi Masashi, Hiro,

If possible, can you please share the .gg file and a short log file of the defective gauge?

This will allow us to look deeper into what could be causing this error.

Regards,

Anthony Baldino

Hi Anthony,

Thank you for reply.

However, in order to extract flash data, after communicating with Battery Management Studio and sending UNSEAL and UNSEAL_FULL_ACCESS commands, I read srec using Read/Srec/FS form device.

As a result, the symptoms improved.

I can't reproduce it after that.

Can you give me any advice from this information?

Hi Anthony,

No this clock stretching issues are observed after the reset.

Will this kind of clock stretching occur when the EC2, EC1, and EC0 bits are high?

Also, in what cases do the EC2, EC1, and EC0 bits go high?

Then, when I checked the Data Memory /Lifetimes/Power Events/No Of Shutdown in the Battery Management Studio, there was a history of 81 occurrences. This is an unthinkable number of times during normal use.

Does BQ40Z80 reset when it wakes up from the shutdown state?

If it's reset, I feel like the error will be cleared.

We need to know why this issue occurred.

This is an issue that occurred during the customer's normal use, and the customer is strongly requesting that the cause be investigated.

We appreciate your continued cooperation.

Best Regards,

Masashi.

Anthony,

Could you please let us know about the following?

1. What is happening inside the device when "long stretch” occurs? What does “unknown error” mean?

2. I observed waveform of bus line and checked every commands of srec read.

There was no “DeviceReset” command in that. Is that mean entering ROM mode is required to quit from the “unknown error”, or “DeviceReset ” command also effective?

3. I would like to confirm if “DeviceReset ” command solve this issue. For that, I would like to reproduce long stretch. Can you suggest the way how to reproduce the long stretch, please?

I appreciate your help.

Hiro

Hi Musashi, Hiro,

masashi.sano said:

Will this kind of clock stretching occur when the EC2, EC1, and EC0 bits are high?

Also, in what cases do the EC2, EC1, and EC0 bits go high?

Hiro said:

1. What is happening inside the device when "long stretch” occurs? What does “unknown error” mean?

The EC2, EC1, and EC0 bits are to represent the error code of what is occurring within the communication. These bits will represent all high when the error with the SMBus communication is unknown to it's firmware, which could be caused by this long clock stretch. However, these bits should not have a direct effect on the communication and are just used for representation of the error. I believe that this long stretch is being caused by something keeping the host busy for an extended amount of time to the timeout:

If possible, please tell me how this register below is set on the device:

masashi.sano said:

Then, when I checked the Data Memory /Lifetimes/Power Events/No Of Shutdown in the Battery Management Studio, there was a history of 81 occurrences. This is an unthinkable number of times during normal use.

This issue is difficult to determine a root cause since there is no data to analyze. There is a possibility that this could be caused by how the parameters are set that would send the gauge into shutdown, which can be found below:

How these parameters affect the Shutdown mode can be found in Section 6.4 of the bq40z80 TRM.

Hiro said:

There was no “DeviceReset” command in that. Is that mean entering ROM mode is required to quit from the “unknown error”, or “DeviceReset ” command also effective?

3. I would like to confirm if “DeviceReset ” command solve this issue. For that, I would like to reproduce long stretch. Can you suggest the way how to reproduce the long stretch, please?

When the device leaves ROM mode to re-enter firmware mode, a reset automatically occurs for the gauge. The gauge will clear these error codes upon any type of reset, in which the Device Reset command should accomplish this as well.

Regarding the recreation of this issue, are there differences in how you and the customer are communicating with the device that could be causing this issue on their side?

Regards,

Anthony Baldino

Hi Anthony,

Anthony said:

If possible, please tell me how this register below is set on the device:

Our device setting of SBS Configuration is 0x80.

Anthony said:

Regarding the recreation of this issue, are there differences in how you and the customer are communicating with the device that could be causing this issue on their side?

We are trying to recreate it, including the possibility of negative effects of communication from the customer side.

Regards,

Masashi.

Hi Masashi,

Thank you for clarifying. I wanted to confirm that you had clock stretching enabled on your device, which you do.

Regarding how the customer is communicating with the gauge, are they using the EV2400 or a host device? If they are using their own host, are there other devices communicating on the same lines as the gauge?

Regards,

Anthony Baldino

Anthony,

Thank you for your cooperation.
Our customer is using their own host(MCU). And I am not sure, but perhaps only BQ40Z is communicating on the SMBus line. I will confirm.

As a practical solution, we are considering the following.
-how to prevent
If long clock stretch will occur again, we would like to let our customer know how to prevent it.

-how to return
If long clock stretch will occur again, we would like to let our customer know the way return to normal.
e.g., sending DeviceReset command.

Regards,
Hiro

Hi Hiro,

There are a couple issues that could be causing the long clock stretch, can you please confirm if the host MCU being used by the customer supports clock stretching? This is the most typical error when it comes to clock stretching.

More information about clock stretching can be found in the document below:

https://www.ti.com/lit/pdf/slua475 

Regarding how to return it to normal, I believe that the device reset should assist this issue in returning the device to normal.

Regards,

Anthony Baldino

Hi Anthony,

According to our customer, host MCU supports clock stretching, and only MCU and gauge are on the line.

Regarding how to return it to normal, will the SHUTDOWN Mode(MAC 0x0010) also return the device normal?

Regards,

Hiro

Hi Anthony,

Thank you for your reply.

Do you mean SHUTDOWN could also not potentially return it to normal?

What I am concerned is the difference between full reset and partial reset described on the TRM.

Do you think partial reset will return the device to normal?

Regards,

Hiro

Hi Hiro,

Yes, sorry for the confusion.

I believe that if the device goes through a partial reset, the device will not return to normal from this error. This is due to the difference between a partial reset and full reset, where in a partial reset only certain aspects are reinitialized. Since the SBS registers are not reinitialized during a partial reset, I do not believe this would fix the issue.

Regards,

Anthony Baldino