BQ40Z50-R2: i2C communication issue

Hello Juan,

What is the state of the gauge when this happens? 

Make sure the HWDF bit is not set in the Enabled Protections C register.. 

The SMBus reader needs to be able to support clock stretching. This is a requirement. Also, how fast are you reading? There's no need to read faster than 1s.

Please share your settings and log file to further analyze this behavior.

Regards,
Jose Couso

Hi Jose, 

First, thank you for your time and for your quick answer

I checked the batteries and the HWDF bit is low. Regarding the data acquisition time, the fastest we're reading is every 1 second (at least in the log file that I'm sending you in the next URL, which corresponds to the graphs I showed in my previous message). In other cases we're also reading every 10ms approx and we don't see the clock stretching issue systematically, that's why we cannot properly determine the source of the issue. 

/cfs-file/__key/communityserver-discussions-components-files/196/GEB461_5F00_Com_5F00_Issue_5F00_Leica_5F00_20230711.txt

In the log file you will be able to check everything, but if you need more information just let me know!

Best regards,

Juan

Hello Juan,

Juan Serrano said:

In other cases we're also reading every 10ms approx and we don't see the clock stretching issue systematically, that's why we cannot properly determine the source of the issue.

Reading at this rate can cause the gauge to do a full reset. Can you please enable (if not already) the LF_EN bit from ManufacturingStatus()?. I want to check if the gauge is being reset. For this, we monitor the Power Events by exporting the configuration file before and after the test. 



Regards,
Jose Couso

Hi Jose,

Sorry for my late reply, but I was on holidays and then it took us a little bit of time to perform some more tests. 

I did what you suggested, but since we're reading every 1s (we only tried reading every 10ms for a while) we didn't have any Full Reset in the fuel gauge. I would say we focus on the 1s reading case, because it would be our use case. 

I made some more tests and I'm still having random issues appearing during the operation of the batteries. Were you able to determine anything from the files I sent you in the previous message? If not, I could send you many more log files from our tests in which the reading of the parameters is not consistant throughout the whole operation of the batteries. 

Thank you again for your time!

Best regards,

Juan

Hello Juan,

Please do send the log files you have.

Jose Couso said:

The SMBus reader needs to be able to support clock stretching. This is a requirement.

As I mentioned before, clock stretching must be supported by the MCU. The gauge will occasionally hold the bus low to process data. Does this happen more often when bigger loads are present?

Is the FLASH_BUSY_WAIT bit set? If not, the device will NACK instead of clock stretching. 


Please see below some good threads on Clock stretching. SMBus Made Simple

Thread-1
Thread-2
Thread-3

Regards,
Jose Couso

Hi again Jose,

I'll send you a couple of log files in which you can see some parameters doing weird things for a long period of time (I mainly check temperature and SoC normally, but we sometimes also have problems with the charging voltage/current). I'm always acquiring data every second, so the SMBus "load" is always the same. The tests shared below are just the last tests completed this week, all under the same conditions (inside a climatic chamber) and at the same time. The parameters named starting by "dll_" are read from the batteries. 

/cfs-file/__key/communityserver-discussions-components-files/196/GEB461_5F00_40W_5F00_Const_5F00_CH03_5F00_v3.txt

/cfs-file/__key/communityserver-discussions-components-files/196/GEB461_5F00_40W_5F00_Const_5F00_CH02_5F00_v3.txt

/cfs-file/__key/communityserver-discussions-components-files/196/GEB364_5F00_40W_5F00_Const_5F00_CH00_5F00_v3.txt

Regarding the FLASH_BUSY_WAIT situation, I'll let you know next week because the batteries are inside the climatic chamber performing some more tests at the moment. 

Thank you again for your time!

Best regards,

Juan

Hello Juan,

Why does the data look with many discontinuity? You mentioned logging data every second, but the data log does not look continuous. It is hard to debug with this data. 

Why does temperature looks like this? Make sure temperature is stable during your tests. The only explanation is if communication is cutting too often.



Do you have a TI evaluation board to run some tests with the same settings? Also, can you send me a private message with your schematic.

Regards,
Jose Couso

Hi Jose,

That's precisely what we would like to know. We don't understand why sometimes (not always) the data have so many discontinuities. It happens quite randomly, because all these tests were performed at the same time and in some cases these issues appear and sometimes not. That's exactly what we could like to clarify: where the problem comes from: is it our SMBus reading system or is it the fuel gauge IC under certain conditions?

Regarding the logging sampling time, it's only 1s during the discharge processes. During the charging processes or during the waiting times that takes the climatic chamber to reach the required temperature (and the internal cells to also reach the temperature), the logging time is much longer. 

The main problem is that we have inhouse built battery adapters inside our climatic chamber connected to the SMBus reading system, so we cannot implement the reading with the TI eval board relatively quickly. If you say it's the only solution, or if you cannot determine what could be causing these communication issues, we will just review our SMBus system. I've been told that this system has been working reliably for years and that they didn't find these issues before, but maybe it's time to check it in depth. Unfortunately, I have no access to the schematics and the engineer responsible is on holidays at the moment during the next couple of weeks, so I'm afraid the log files I sent you are the only data you can work with in the meantime. 

Thank you again for your time!

Best regards,

Juan

Hi Juan,

Juan Serrano said:

where the problem comes from: is it our SMBus reading system or is it the fuel gauge IC under certain conditions?

We have not seen such behavior with our gauges. However, it has been reported by customers that the when the MCU does not support clock stretching, there's communication problems. Our gauges will hold the bus lines low when it is processing data.

I cannot do much with the log data. But, if you provide a schematic, I can help reviewing the communication lines. The schematic can be sent privately if this is a concern.

Regards,
Jose Couso

Hi Jose,

Perfect, thanks a lot for the information. Let me check what you mentioned about the FLASH_BUSY_WAIT bit, and I'll give you more feedback about both the clock stretching and our schematic in a couple of weeks when the owner of the system comes back from holidays. Unfortunately, I have no datailed information about the schematic, so I'm afraid we'll need to wait. 

Best regards,

Juan

Hi Juan,

No problem. Let me know.

Regards,
Jose Couso