BQ40Z50-R2: DFW Failures

Hello Tyler,

It looks like these packs were in the field for some time by looking at the cycle counts, does the host perform any data flash writes during normal operation of the gauge?

Can you share the SREC files from the DFW failed devices? We track the number of flash writes and when the DFW failure occurred but the information is not in the .gg file you have shared on the other thread, only in the SREC.

Sincerely,

Wyatt Keller

As you have mentioned,  DFW indicated that the number of flash writes was corrupted. The battery being subjected to EMI is unlikely. Being subjected to ESD is not impossible, but no other components give indication that an ESD event has occurred. 

Hello Tyler,

We would need to know how many times the host writes to the gauge as well, if it is DFW failure this is a critical piece of information. If the 20,000 flash writes are exceeded this can cause flash wear out and failure. It is common for this issue to be related to the host writing something to the manufacturer info block section too often.

Sincerely,

Wyatt Keller

Wyatt,

The batteries with this issue are typically a swappable battery and a flash write occurs when the battery is placed on system or charger. Based on the number of cycles, it seems unlikely that the battery would be docked 20,000 times.

Hello Tyler,

On each battery insert the entire flash is re-programmed? The 20,000 limit is not based on per register - it is any flash write. While programming the gauge it requires multiple flash writes, if you are performing 200 flash write operations per programming you could hit this limit much faster than expected Also extreme conditions could cause increased depredation as well. From reviewing the data it appears it is corrupted somehow which I have not seen before.

Sincerely,

Wyatt Keller

Wyatt,

After further internal discussion, there was some confusion initially. It has been confirmed that we do not write anything to the data flash memory address 0x4000-0x5FFF.

Wyatt,

I have received another failure of this type with a different battery type that uses this same BQ chip. This latest battery does is set in a case and does not interface with the user. The battery being subjected to ESD or EMI is unlikely.

Hello Tyler,

Can you share the SREC file from this battery pack via PM? I will take a look at the DFW failure information. What is the PPM of the failure?

Under normal conditions we have tested the dataflash to well over the 20k limit, the only other methods are external stresses that can cause DFW to occur. The only cases I have seen multiple DFW failures are because of unintended writing to dataflash which causes wear out.

Sincerely,

Wyatt Keller

Wyatt,

What commands increment the Data flash write counter?

Hello Tyler,

I won't be able to give a complete list of the commands that would modify the data flash since some of them would depend on the state of the gauge like the lifetime updates and this is not something we track as part of the specification.

Every reset will increment the counter, most commands like the read word for RSOC, SOH, etc will not increment the data flash since they are stored in RAM and pulled from RAM when the command is executed.

If you can give a list of the commands used I can verify with our firmware team which ones would cause a flash write.

Sincerely,

Wyatt Keller

Wyatt,

I have DM'd you the files 

Hello Tyler,

I don't believe any of the commands you are using are causing constant flash writes, all the SBS commands should just be pulling RAM, from what I saw from the log of commands most of they are just pulling DA status information, a large majority of them would not cause anything to occur. Is it possible for an edge case in the host MCU to loop and cause large amounts of writes incorrectly? The cases I have worked with DFW it was the result of the host.

Sincerely,

Wyatt Keller