This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ40Z80: Issues with corrupt memory using Battery Management Studio

Part Number: BQ40Z80
Other Parts Discussed in Thread: EV2400, BQSTUDIO

I have run into a problem where sometimes the memory will become corrupt when doing a Write All command from Battery Management Studio.

Here is the setup:

- Our own design with the bq40z80 BMS

- bsStudio v1.3.86

- Communication over the SMBus using an EV2400

- FW Version  4 Build 5

We have come up with our initial configuration and am doing a Write All to new boards.  What has been happening is some that we write to we can no longer read/write to certain areas of the memory.  An example would be in the SBS configuration the Serial Number will always read ffff.  I can also no longer write/read Manufacturer Name, Device Name, and Device Chemistry.  I can no longer write these value or read them.  I have verified that the BMS is not sealed and I have full access.  I can however talk to it over the SMBus, it recognizes is is the bq40z80 and I can read temperature.  

All I have to do to get it in this state is to write the default, write our values.  Sometimes I have to do it a couple of times but it does get it in this state.  Most will work when we write the values but we keep having boards that will have corrupt memory.  The ONLY way I can recover from this is to replace the BMS IC.  When I do that everything works again.  I can however get it back in this state if I write our values, then the default and go back and forth until it fails.  I have tried just writing one value at a time and that seems to be OK and seems more related to the Write_All feature.

I have scoured many threads where other have been able to corrupt the memory when updating from a CPU where they were writing out of the bounds of address spaces or out of sequence but I would think that this would not be the case using bqStudio.  Do you have any insight as to what may be the case here?

  • Hello Shawn,

    Can you send over an example log file and pull an srec out and compare it to the original default srec?

    Also please provide a failure rate, is it easy to get any unit of yours to fail?

    It could also be the EV2400, update the EV2400 FW to the latest v0.28 on ti.com and try again.

  • I updated my EV2400 to FW v0.28, it was previously on v0.27.  I fixed one of the boards by replacing the BMS IC.  I should preface that we currently do not have a golden image created yet.  Just working out values in the configuration currently.

    In this case I got the default gg.csv file and .srec from the new BMS IC.  I then loaded it with our A006 configuration (our current working image) using the Write All command in the Data Memory page.  It successfully wrote all the values and I could read them back.  I then wrote back in all the defaults and could read them OK.  I then went again an loaded our A006 image again.  This time it did the memory corruption previously mentioned.

    As far as failure goes it seems any board I can write default -> A006 -> default.... until it fails.

    I have enclosed the .srec and .gg.csv files for each case.

    As mentioned previously the only want to get it out of this failure case is to replace the BMS IC.  Would there be any other way to recover it than that?srec_gg.csv_files.zip

  • I should mention that tonight I determined that I can get it out of this corrupted memory state by loading a .srec file into it rather than trying to do a Write_All.  However still need to know why it get's into this state.  

  • Hello Shawn,

    Please compare the corrupt srec with the working srec. It seems that the original srec is corrupted. You may need to trace history on your end.