BQ78350-R1: Corrupted Registers

Hi Larry,

This is a strange issue you are seeing. The Serial Number is from data flash, so it looks like the data flash value may have been overwritten or erased in that pack. Are you putting the gauge in SEALED mode when it is sent to the field? This should prevent accidental writing to data flash. Are you using PEC (packet error checking) on the SMBus?

Regards,

Matt

Hello Matt,

These packs are were unsealed (production packs will be sealed). PEC is not enabled.

I have no visibility to the system side, but all commands on address 16 are supposed to be reads.

Would it be possible for the system to write FFFF to RSOC? I am thinking it is read only.

Thanks,

Larry

Hi Larry,

RSOC cannot be written and it is not in data flash. However, if another parameter is corrupted, it may be possible to affect RSOC. 

RSOC and ASOC are both one byte parameters, so the max possible value should be 255 I think. Are you sure this is the parameter that read 65535?

Matt

Matt - I am sorry, it was ASOC.

See attached screen shot from our customer...Screen.pdf

Thanks for sending the screen shot. Can you ask them to also save the data flash state (click on Export on the Data Memory screen of BQStudio to save a .gg.csv file)? If they compare this to the settings that were originally loaded, this will show if anything has been corrupted in the data flash.

Matt

Unfortunately, he has already re-flashed the pack. If he can replicate the situation, I will get him to grab the .gg and the.srec files.

Obviously, something is corrupted in the flash in order for bqStudio to see FFFF in these registers.

In the meantime, is there anything in the physical memory structure that could allow the internal processes of the chip to write incorrect data to these fields?

Thanks,

Larry

There are several data flash parameters that are updated internally. There is no reason these should be written with incorrect data. Maybe it is possible that VCC is unstable or disrupted during a flash update?

Matt

There is no VCC instability, and the corruptions occurred during normal operation.

As I mentioned before, the pack is 15S LiFePO4 (54.75V at peak charge) and the current is up to 25A.

The voltage is scaled. The voltage MAX is 65535 (TRM Page 96) but the TRM pages 11-12 state that it is necessary to scale if the voltage is above 32767.

Current MAX 32767 is mA, and page 113 indicates this range is good "For applications using higher than 32767 mA, update to the bq78350-R2 firmware" so that current scaling can be applied. 

Although the chip can report this current reading, my concern is the possibility that sustained current close to the limit of the range could cause some internal data collection process to inadvertently overflow data into these memory locations.

Is this possible?

Hi Larry,

I do not think that operating beyond the range can cause overflow that would affect these memory locations. Especially the serial number - this should never be updated during normal operation. It would be very good to get a .gg file from a failed pack because this will not only show if there is flash corruption, it will also show Lifetime data that will help determine if there is anything unusual that happened with the pack (max voltages and currents, faults, etc.)

Matt

Hi Larry,

Do you have any update? 

Thanks,

Matt

Hello Matt,

We had a pack to get corrupted at the test house during UN Transport. It gave a CUV flag that would not clear, even though all the cells were in the middle of the range (~3.25V).

The pack was sealed, so we could not do a reset, but it would not accept the unseal commands. We finally had to send a shutdown command and re-start in order to get it operational.

Thanks,

Larry

Hi Larry,

Is it possible to read the .gg file for that pack so we can take a look at the data flash settings? There is a bit in data flash called CUV_RECOV_CHG. If this bit is set high, it requires a charge current to be detected to allow recovery from CUV. The gg file will also show what is set for the CUV threshold and recovery time.

Regards,

Matt

Hello Matt,

CUV_RECOV_CHG is set high.

However, this is not the challenge. The pack was sealed and would not accept the unseal keys, so we were unable to send the reset command.

Thanks,

Larry

Hi Larry,

I wonder if there could be an issue in the production flash programming. It seems like different settings are corrupt on different packs without a real pattern. When flash programming is done in production, is there a read of all the data flash to see if anything was not successfully written? If so, do you see any yield fallout in production?

Matt

Matt,

These corruptions are occurring as a course of operation. Board level Programming, Calibration and Verification with checksum, etc. is automated, with an automated end-of-line test at pack level.

It is not possible for a pack to leave the building with FFFF in the serial or FFFF in the SOC.

Hi Larry,

I understand. Hopefully the gg file will provide more insight if you are able to read it from a failed pack.

Thanks,

Matt

Hi Larry,

Have you been able to get a gg file from a failed pack?

If not, I will close the thread for now. It will automatically reopen if you respond with new information.

Best regards,

Matt