BQ27Z561: After the learning cycle - What needs to be done in my real system?

Ofer,

1) You can use bqStudio to program the image from the 1st battery into the 2nd battery. You can use the "golden image" plug-in to export the information from the first battery

2) No there should be nothing needed to be updated. Ideally each battery is calibrated separately, but often some small margin of error is acceptable to remove this step. You need to make sure the gauge enable bits are one [Gauge_en][FET_en][Lifeteim_en] To make sure the device works properly. People sometime update the system data parameter with a serial nu mber for tracking

3) No calibration is not needed in the field. The gauge will auto learn everything it needs to while in use.

Thanks,

Eric Vos

Eric,

1) I exported the golden file from the training-cycled battery.

My question basically is how do I read the golden file back into BqStudio (I close it since) so I can write to into the other battery?

2) I found the [Gauge_en] and [Lifetime_en] ([LF_EN]) bits, but could not find the [FET_en] in the technical reference document for the BQ27Z561. What is it?

3) Ok.

Thanks,

Ofer

Ofer,

1) You should have a file on your desktop with a .srec or .bq.fs extention. You can select and program it using the bqStudio "programming screen". 

2) Sorry force of habit. The z561 does not control the FETs so there is no FET en

Thanks,

Eric Vos

Eric,

Thanks for all the information so far, it is most helpful.

Just to clarify 2), document slua903 says, in the very last bullet "Before saving the Golden File, set Update Status to 02 to disable IT gauging, ... For a pack side gauge, this ensures that when the pack is assembled and gauging and lifetime is enabled, ...".

I was probably confused between the two gauging mentioned in this paragraph. What is meant by IT gauging in the first sentence and by gauging in the second one, and which one refers to [GAUGE_EN]?

A few additional questions that deal with handling the gauge in my operational systems.

4) So in my production line I will program the gauge with the golden image.

What is the recommended method of verifying that all contents have been written correctly? Simply reading back the entire data structure or is there a simpler/shorter way?

5) Since this gauge is flash-based in theory I will not need to program it again, but let's assume that I would like in the field, for good practice, to periodically verify the data structure in the gauge was not damaged in some way.

Is there an easy/recommended way to do this, without reading the entire data?

Perhaps even reading the entire data will not be helpful as some data may change over time.

6) Once I've programmed the gauge and have an operational unit in the field, how should I handle the gauge and what should I periodically read from /write to it?

The most obvious is to read the RSOC in order to know why remaining percentage and to report it to the user, but are there other parameters it is recommended to read/write periodically for correct and productive usage? For example, cell health/age, etc.

At what rate should I check RSOC, etc.?

Is there a document describing this?

Thanks,

Ofer

Ofer,

4) We have checksum commands you can use to validate the programming was successful. DF/IF/ChemID

5) The same checksum. Certain parameters are expected to change so a straight compare wont work over time. The Checksum's dont calculate using changeable parameters only static ones. 

6) Registers are updated at a 1Sec interval so dont read registers faster than that. As far as what to read i cannot help you. it depends on what your system requires. Obviously the main point of a gauge is SOC. RemCap/FCC are also useful as well as SOH. Your system might have value in voltage/current/temp/Charging current/Charging voltage... really up to you what you use. 

Thanks,

Eric Vos

Eric,

I missed the answer to this one, so I'm re-asking

2) document slua903 says, in the very last bullet "Before saving the Golden File, set Update Status to 02 to disable IT gauging, ... For a pack side gauge, this ensures that when the pack is assembled and gauging and lifetime is enabled, ...".

I was probably confused between the two gauging mentioned in this paragraph. What is meant by IT gauging in the first sentence and by gauging in the second one, and which one refers to [GAUGE_EN]?

7) What determines if I should use the .df.fs or .bq.fs goldem image files?

I saw that the .df.fs checks if the to-be-programmed gauge has the same FW version as the one that generated the golden image, and if not, it will not program the gauge.

What happens if the gauges in the production line have a different FW version than the golden image, will the image work with them?

If I use the .bq.fs file does it mean it will override the FW in the gauge? Should I do it, even if the gauge has a newer FW?

8) What operations it is recommended to carry out in the production line, in addition to programming the golden image? Should I perform any of calibrations, and should it be performed before or after programming the golden image? Anything else?

Thanks,

Ofer

Ofer,

2) Both. Setting Update_status = 02 means learned without IT_Enabled. They say to write it to 02 so when doing production like tests you dont "learn something" incorrect. Sending the IT-Enable command as the last step on production gets everything in sync. 

7) bq.fs includes the instruction flash. df.fs is only the datamemory piece. if upgrading fw version say R1 to R2 or R1 v1.03 to R1 v1.04 you need to use bq.fs. else df.fs is fine. 

8) Calibration should be done on every board, but some customers accept minor error and just use an average calibration value. The rest of things you want to check are up to you and your requirements of your product. 

Thanks,

Eric Vos

Eric,

2) and 8)

Trying to summarize everything you told me and to see if I understood correctly, this should be my sequence:

a) Complete a training sequence and then change Update_status to 02. Write out the golden image.

b) In the production line write that golden image into each gauge.

c) perform calibration on each board

d) set [GAUGE_EN] and [LF_EN] for each gauge (can I use the gauge_en() and lifetime_en() commands as in BqSutdio?

Is this correct or did I misunderstand something?

7) If I understand, using .bq.fs will overwrite the FW in the gauges in the production line. If these gauges have a newer FW what reason could I have to overwrite it?

Thanks,

Ofer

Ofer,

2&8) Yes. 

7) a new FW might have come out because a feature was added you many not want or there was a bug on a feature you did not use. It is best to use the bq.fs to be safe.

Thanks,

Eric Vos

Eric,

9) Is there a document describing how "ROM mode" works? I could not find it in the technical reference sluubo7.

10) I tried comparing the .bq.fs, which I should be using for programming, and .srec, which I saw is what the BqStudio uses for programming. While the "basic" data in the data and instruction memories seem to be the same there are many additional commands in the .bq.fs that I do not understand (in ROM mode).

Also, in the .bq.fs it seems there are re-writes to addresses that were written previously. For example, there are two lines beginning with "16 05 12 00 00..." followed by 16 different bytes of data. Why is that? The first write contains the data that is similar to the .srec file, so where does the data in the second line come from? Strangely, BqStudio also knows to write twice to these addresses, even though it does not seem to exist in the .srec file, but that data is slightly different. Please help me understand this.

Thanks,

Ofer

Ofer,

9) ROM mode documents are not given out. ROM mode is the mode to accept the new FW image. 

10) Srec is a standard form you can google search the format of them. bq.fs is the I2C list of the command to program in the equivalent of the srec. 

bq.fs file get to the same result as programming in the srec into the device. They are not directly equal to each other. 

Thanks,

Eric Vos

Eric,

4) Is there a way to execute the checksum commands you mentioned via the BqStudio so that later I will have reference for this for my own code?

2&8) Rereading previous answers I see it is not clear to me what should be done at each stage.

The way my production line is built is as follows:

station 1 - testing of PCBA. All electronics parts are tested. The PCBA is tested with a known input voltage, without a real battery.

station 2 - battery assembly

station 3 - device assembly

station 4 - Final-testing of finished product

From here on the battery is never detached from the FG and the rest of the system.

My intention is to program the FG with the .bq.fs file right after I test my PCBA, and then perform calibration, both at station 1.

This means that now the FG is programmed but there is no battery attached to it.

Only at station 4, after I have the complete device I intend to enable [GAUGE_EN] and [LF_EN].

Is this the correct way to do it, given my production line setup?

Do I need to perform any other operations at any of the stages for the FG to read the battery status correctly?

11) In my production line, and only there, I would like to read back the entire memories I write (data and instruction) to make sure everything was written correctly, and also as a way of verifying the memories are intact. If I simply change every "W: ..." line in the .bq.fs file to a "C: ..." line, will that work (I assuming I change only the write-data lines and not the short command lines), or do I need to change other commands as well?

Thanks,

Ofer

Ofer,

Yes there are checksum MAC commands to use. They are easy to find in the TRM. *Note if the Checksum is correct comparing the calaculated one vs the one stored in DF, the gauge will clear the MSB. This is a fast way to know if it is correct

Yes these is the correct flow you have outlined with the different stations

There is no reason to do this massive compare. If the IF gets corrupted the device will fail to boot so you will have a communication check. The DF you can readout starting at address 0x4000, but I believe the checksum's should be enough.

I would not modify the bq.fs at all (other than maybe adding time to the X: just to be safe and give the FW more time to process)

Thanks,

Eric Vos

Eric,

12) Until I will have my system assembled I'm trying the suggested flow using the BQ27Z561EVM-011s. I used one EVM with a battery pack to obtain correct chem_id, run the training sequence and obtain a golden image. I then used BqStudio to program the .srec file into another EVM to which I connected the same type of battery (but a different unit), along with my (partial) system.
After programming finished the first thing I noticed was that [CAL_EN] was set. Should this be so?

I then used the BqStudio's commands GAUGE_EN(), LIFETIME_EN().

Then I charged the battery to full. I don't know if I could "trust" the FG to report the RSOC correctly, and this is the recommended operation for devices with a rechargeable battery.

After the battery was fully charged and relaxed I started discharging it with my system, but RSOC remained at 100% all the way until the battery was completely drained. It looks like the problem was that "Full charge Capacity" was 0mAh.

I tried everything again from the programming stage with the only change of using the RESET() command after LIFETIME_EN().

Should I use the RESET() command at all in this sequence?

Anyway, apart from the RESET() command clearing [CAL_EN] the behavior was the same. I got not get RSOC to report correctly, again due to an incorrect "Full charge Capacity".

I now have tried the programming for the 3rd, but did not execute any commands yet as I'm waiting for your response to see what I'm doing wrong.

I now see that "Full charge Capacity" has a very reasonable value, as well as Remaining Capacity and RSOC. Hopefully it continue to be so.

To summarize my questions:

a) Why is [CAL_EN] set after programming?

b) Should I use the RESET() command at all?

c) If everything works correctly, can I count on the FG to give a correct RSOC right from the very first connection to the battery (or, for example, only after an initial charge to full, etc.)?

d) Why did "Full charge Capacity" stay/become 0mAh? What could affect it?

Thanks,

Ofer

Anything for (12)?

Thanks,

Ofer

Hello Ofer,

You can follow SLUA903 for an outline of how to run the learning cycle. The gauge will not report correct SOC or FCC until the battery pack has been learned and the IT algorithm is enabled.

There are

Sincerely,

Wyatt Keller

4) I tried finding the checksum commands. For the IF I found IFChecksum, which seems good to me. For the DF I found a few, StaticDFSignature, StaticChemDFSignature and AllDFSignature. I tried using StaticDFSignature but it does not seem to cover what I need. I read it after programming and got a certain value. I then manually changed a parameter in the DF (Cell Gain) and read StaticDFSignature again but got the same value, which is not what I wanted. I don't know what StaticDFSignature covers but it does not seem to give me what I need, an indication of the DF changed for some reason.

What should I use in order to verify the correctness of the DF?

Thanks,

Ofer

To clarify, I'm looking for a quick check I can make each time my device powers up to verify the DF is ok, as good practice.

I know that while programming the golden image the DF checksum is verified, but this is done only once.

Thanks,

Ofer

Ofer,

The only way we have is the DF Static checksum. This is because there are lots of DF parameters that update during the application so your checksum will change if those params are included. 

Which parameters are you wanting to check in the field? 

Thanks,

Eric Vos

Eric,

What parameters/areas of the DF does the StaticDFSignature cover?

Currently my plan to keep monitoring these paramters in the field:

Voltage()

Current()

AverageCurrent()

RelativeStateOfCharge()

RemainingCapacity()

FullChargeCapacity()

CycleCount()

StateOfHealth()

Temperature()

BatteryStatus()

InternalTemperature()

Thanks,

Ofer