My name is Dominik. I'm an application engineer located here in Dallas.

And so I
support single cell gauges. So what I would like to talk about today is gauge
configuration, mostly.

So how do you configure a gauge to work in a particular system? So we'll talk about
the workflow for different gauges as well as the tools that TI provides to support
this configuration. I will also explain some of the file formats that all tools
use, talk about the communications interface, and will show what example code we
have to program gauges.

So if you have ever looked at a technical resource manual for one of our gauges,
you will know that there is an enormous amount of parameters that we expose, and it
can be a bit intimidating and overwhelming to see all the parameters that we have.
And I would like to talk about what do we really have to configure for a gauge to
make it work? So a lot of these parameters are there for tuning. So it's not
necessary to configure every single parameter that we expose. And for basic
gauging, there is only a limited amount of parameters that you will have to modify.

So these parameters that you will have to configure are basically design capacity,
the design capacity of the batteries. You can get this information from the data
sheet from the cell that you're using. Then the terminate voltage, which is the
minimum voltage where your system shuts off.

Then the gate should be synchronized with the charger so there is some parameters
for charge termination. For gauges that support it, and you can also configure the
chemistry, which will adapt the gauge for a specific cell. And then the rest of the
parameters are basically for tuning for best performance.

The tools that TI supplies for this are bqStudio, which is our current tool for
gauges. So all our new gauges are supported by this tool. We have another tool,
EVSW, which is an older product. Now this software is used for some of our legacy
parts. All the concepts that I'm going to talk about doing this presentation apply
to both bqStudio as well as EVSW.

I have several different types of gauges, two main categories. One category is
flash and OTP gauges. And the other kind of category is ROM gauges. The workflow is
different between those two gauges.

Flash and OTP gauges, as the name suggests, they have memory that is persistent and
that can be programmed by the end user. So for flash gauges, the data memory which
holds all the configuration for a gauge is implemented as flash memory and can be
updated many times. So the configuration, everything that's necessary to configure
a gauge can be programmed for flash gauge during production, which makes it fairly
easy to use because you don't really have to have a complex driver to write all the
data memory and configuration to the gauge. But instead you program the
configuration during production with a production tool that TI supplies.

Flash gauges support a Chemistry download for impedance tracking gauges. So what
that means is, when you select to gauge and you provide your cell to TI or you can
also run this directly at your place, you will identify a ChemID. So a ChemID is
basically a number which refers to a set of data that TI has in our database. This
data consists of tables which describe the cell. So the ChemID tables consist of
open circuit voltage, which describes the open circuit voltage behavior of your
cell.

This is a function of depth of discharge. It also has impedance tables and

temperature compensation tables. So in order for the gauge to adequately keep
gauging for different [? temperatures, ?] that ChemID, so the set of data contains
temperature compensation, impedance tables, and open circuit voltage tables.
So this is quite a bit of data. It's not just the number, but it's a fairly large
set. And TI provides that for flash gauges, and you can program a flash guage for a
specific cell. And I'm going to talk about how that works in detail later on.

So while the flash gauge can be programmed multiple times, an OTP gauge, which is a
little bit less expensive, can only be programmed one time. But you can still
program the configuration as well as the chemistry information during production.
So they still are fairly easy to use from a travel point of view, because there is
no need for a driver to program the gauge.

For an OTP gauge, the data memory is equivalent as RAM, and it's initialized during
device spool-up so when you boot up the gauge or when you do a power on reset for
the gauge, the gauge will fetch the data from the OTP memory and program its data
memory during bootup.

The least expensive gauges are ROM gauges. And the catch there is that the data
memory is implemented as RAM. So anytime the gauge is power cycled or reset, the
gauge will initialize the data memory of defaults that are stored in read-only
memory that essentially will be completely reset at that point. And it will will
lose any information that was programmed into the gauge at that point.

This means the configuration, it must be programmed every time after gauge boots
up. Which makes it a bit more difficult from an implementation point of view,
because you cannot use TI programming tools to do that practically. You will have
to write a driver for your whole system that accomplishes that, so the driver would
have to recognize that a gauge was power cycled and then would have to download all
the configuration into the data memory, and will have to do this every time you
power cycle the gauge. So ROM gauges do not officially support Chemistry download.

There are some tweaks possible if it's absolutely necessary. Basically what we do
is we sell ROM gauges with pre-programmed chemistry profiles for different
batteries. So if you look at the TI website for ROM gauges, they typically have a
different suffix like [? G1A, ?] B, or [? G1C ?] or D.

And all these suffixes, they denote the certain chemistry that this gauge was
programmed for. Because it loses data. When you power cycle, you will require a
driver that can process configuration files or a driver that can write custom
configuration to the device using a host controller.

This slide shows our main tool to configure a gauge. It's bqStudio. And I would
like to show you this tool also on this computer in the next few slides.

What you do with bqStudio is, it has a Data Memory view that gives you access to
all the configuration parameters for the gauge. So the data memory's part of the
gauge. Depending on the gauge type it's in Flash and RAM. And the data memory is
organized in different categories. So there's different categories of, we call them
subclasses that accrue functionality together.

So there's for example, one for safety, one for charge termination, one is called
data or state. So each subclass contains a block of data with several parameters.
And each parameter has a data type, a unit, a default value, a [? range. ?] Each
parameter is stored at a specific offset.

Later on in the presentation, I'm going to show how this is implemented in the
gauge. So this representation is very close to how it is organized inside the
gauge. So inside the gauge, you cannot directly write to any of these parameters,
but the gauge employs an indirect addressing method and this indirect addressing
method is also organized in subclasses and then parameters within a subclass with
offset data type and length.

How do you get from a blank gauge to a function gauge for your system? I would like
to talk about the workflow. How do you go from using a gauge the first time to
gauge that works in your system?

So the first thing that you do is your configuration, and you use the TI gauge EVM
with basically And apologies for the setup here. It's not the most professional I
guess, but I have a typical setup that I use in my office to configure a gauge and
to [? correct ?] [INAUDIBLE] batteries.

So here I have a typical gauge EVM. It's bq27531. Then it's connected to a typical
single cell. And then this is connected to this bigger board here, which is a gauge
development kit through a four wire connector.

So we use a standard connector extended cable that connects our control interface,
communication interface to a USB to I2C or HDQ interface. either the GDK, which is
this board here. Or, we have EV2300. It's a small plastic box. And it accomplishes
the thing basically.

It's a subset. So this can do a little bit more. I'm going to talk about this
during the workflow. So the point for this is I want to be able to connect the
gauge to a PC, and then use bqStudio to update the configuration of the gauge. And
this is going to be the interface between the PC and the gauge. So it has USB
connection on one side and I2C connection on the other side here.

This board can also apply load current, or it can charge a battery. So that's what
most of the circuitry on this board here is for. And so it's connected to that EVM
also as a load or a charger. OK. So the first step is to obtain a TI EVM with the
gauge that you want to use, and then connect it to the PC with either this
interface or a EV2300 or EV2400, and then on launch bqStudio.

So the next step is if you use an IT gauge, [INAUDIBLE] gauge, you have to obtain a
ChemID. So you can either submit a custom ChemID request for best performance. If
you do this, then you submit the battery to TI. And TI will then hook it up to a
Arbin battery tester.

And over the time frame of several weeks, it will
consisting of the open circuit voltage table, the
temperature compensation information. And this is
particular cell. This gives the best performance,
time.
extract a ChemID, basically,
impedance table, and the
really done specifically for this
but it also takes the longest

Alternatively, what you can do is you can run a very fast characterization using,
for example, this GDK here. So you don't need a battery tester. But you can use
this GDK. Or, I think we also in the future are going to have a slightly modified
version of this. battery management development kit.

So what that does is it allows you to run a characterization sequence, which

produces a log file that you then use to obtain a matching ChemID where a TI is
going to look into the database and perform a match with the data that you obtain
from your cell using this kit here. So this is the basic step with an impedance
tracking gauge. If you use a CEDV gauge, we also have a similar tool. It's a little
bit more involved to obtain the log files, because it needs log files with
different temperatures and different load currents.

The basic procedure is similar. So you run a characterization for a battery, obtain
a bunch of log files from your characterization set up, and then send this
information to TI. And TI is going to return coefficients for CDV gauge.
These two steps are critical for good performance. Some gauges, like ROM gauges,
you may be able to [? simply ?] use the default configuration. And it may not be
necessary to obtain this chemistry match. So if the performance turns out to be
good enough without this, then this step may be skipped.

The next step is to configure basic gauging parameters. And these are different for
each gauge. In the data memory if you're with bqStudio, I'm going to show you how
that works with this here. This is bqStudio. What that shows you is buttons that
give you access to different views.

For configuration, we will have to use the data memory view, because conflagration
is stored in data memory. I can see on the side what is connected to the PC. The PC
detected a GDK, which is this big board here. It detects that the GDK is connected
to a bq27531G1 EVM.

So the PC detects that it's connected to a bq27531G1 EVM. If I want to a

configuration, then I have to go to data memory and configure the following
parameters. That's the minimal configuration.

As you can see here, there's a very long list of parameters. And it can be really
intimidating if you first see this, because it would take a long time to configure
everything perfectly. But basically, the gauge is already preconfigured with values
that work for most applications, except for the basic parameters that I showed in
my presentation.

And for this particular one, I would change the design capacity data subclass. So
we can see that the design capacity here is located in the data subclass. The
default value is [? 2520 ?] for this here. The unit is a [? million ?] [? p ?]
hours. And the subclass number is [INAUDIBLE] [? 30. ?]

The length is 2 bytes. The block offset within the data class is 0. And the offset
within that subclass is 8. If I want to change this in a driver, I would have to
use this information, the offset within the data class, the length, the subclass
ID, and then that value to program the gauge for the 27531. Because it's a flash
gauge.

It's very easy. You just type it in here, change it to whatever value your cell
uses. And that's it. Then the next step is in IT configuration.

You would have to change the terminal voltage, which is the voltage where the gauge
is going to report 0% SOC. Then you would have to change the charge termination.
That's to synchronize with [? a ?] charger. You would put the charging voltage, the
taper occurrence, and the taper rate.

OK. So once this is all configured, you would click on the Golden Image, that would
export a configuration file that you can use during production with programming
tools. One step that I actually forgot to mention here now-- I have that in my
presentation-- is you also have to run what we call a learning cycle, will update
the impedance tables to match the cell that you're using if you use a matched
[INAUDIBLE] not a custom [? or a ?] ChemID.

So this slide shows the parameters that I just changed in bqStudio. So its the
charging voltage, the taper voltage, the design capacity, and the terminate
voltage. And for this particular gauge, these are the minimum parameters that you
will have to change together with the ChemID to make it work for your system.

Then if you use a matched ChemID, you would also run a learning cycle. And what the
learning cycle does is it will apply a defined charge and discharge sequence, so a
defined charge current, charging voltage, and discharge current. And the gauge is
going to update its chemical capacity, Qmax, as well as the impedance table during
this learning cycle.

That will adjust a matched ChemID to work really well with your cell. Once this
learning cycle has finished, then you can export the configuration with bqStudio.
and use that with programming tools to program the gauge [INAUDIBLE] production.
Once step that you should also do is you should verify performance.

What that means is you would charge up the cell to 100%. And then you'd discharge a
cell with a constant current, log the data in bqStudio, and verify the state of
charge versus pass charge and the capacity of the cell. So you can see here this
plot here shows the battery voltage.

So this point, it's relaxed. Then it start discharging with a constant current.
Over time, the battery voltage is going to drop until it hits the terminate
voltage. Then I stop discharging.

It's going to start relaxing. During that time, with bqStudio I can log the state
of charge. And I will get something very similar to this. It should be a linear
drop in [? capacity-- ?] state of charge all the way to 0%. And if I plot the
difference between the ideal state of charge and the measured state of charge, I
have an idea how well the configuration [INAUDIBLE] matches my cell.

So in this example, it's pretty good. You can see that the arrow goes up to about
1.4%. I'd say that's a decent match. So that configuration that is used to generate
these plots is a pretty good match for the cell that I used with this gauge.

So once you are happy with performance after the learning cycle, you would then
export the golden image data from bqStudio. When you do this, bqStudio creates
several files. All these files are text files that you can read with a text editor.
And they have different meanings.

The first file that we have here is a .ot.fs. So this is for gauges with OTP
memory. It's an OTP flash stream file. And that contains instructions to program
OTP. Then the data gets copied into data memory when you put the gauge.

Then the next file format is .bq.fs, which is for flash gauges. So it's a Firmware
Flash Stream file. This contains all the instructions to update the Firmware of the
gauge. So flash gauges, they also have the ability to update the Firmware, the
program that's running all the processes inside the gauge. And if TI supplies a
.bq.fs file that contains an update to the Flash Firmware.

The file is a .df.fs file, also for flash gauges. This one is the Data Flash Flash
Stream file. So this contains instructions to write to the Data Flash memory. OK.
So this is what contains all the configuration for the gauge.

For legacy purposes, we also have a .srec also for flash gauges. So that was one of
the file formats that we used in our older software, EVSW. And this is a basic
Motorola X file. This contains X records with firmware and corrugation for gauge
flash data memory.

The disadvantage with this file is that it's very difficult to really understand
what's going on. In that file, it's just basically hexidecimal data for all Flash.
And it's not very transparent versus these Flash stream files. They contain the
actual register write. So together with the [? TRM, ?] you can actually decode what
these files contain, what these writes mean.

So in bqStudio, the golden image export is basically this view here. Very simple,
just type in a file name, and then create image files. And then it will create the
image files that are appropriate for the specific gauge. So for example, for the
531, this one only requires three different files.

Well, actually the first one is optional. It has the .srec file, the .bs.fs file
with the Firmware, and then the configuration file for the data memory. So next
step is you need to program the gauge. And this is during production for our flash
gauges.

We have TI programming tools, either Smart Flash or bqStudio. And you use that with
EV2x00, so EV2300 or EV2400. USB interface hooks into the I2C bus on your system.
And then you use our software in a PC to program these Flash Stream files to the
device.

So there's really no need to write any code on them, very minimal code on a host
controller. Is to read the state of charge. But there's no need to write any code
to update the data memory, because the TI programming tools do that during
production.

With OTP, you have to use Smart Flash. So Smart Flash, also TI tool, supports
.ot.fs files. So you export this from bqStudio, load it into Smart Flash program,
and then follow the instructions on screen.

And once the sequences finished, then the OTP memory is programmed. Because this
OTP can only do this once. So you would have to really be sure that you exported
the correct golden image.

So for ROM gauges, the first [? law or ?] step is basically the same. So you do a
configuration. You have an EVM connected to the interface here. Open bqStudio.
Modify data in Data Memory View.

Some of the parameters that you need to change for ROM gauges are different. It
really depends on the gauge. So if you look into the TRM, it typically has a
section what the minimal parameters are that you have to modify. And then you
modify these parameters in bqStudio.

My example here was bq427421. And
voltage, the design capacity, the
voltage, and the taper rate. Just
bqStudio first. Simply change the
Data Memory view.
for this, we'll have to configure the design
design energy, the terminate voltage, the taper
like with flash gauges again, try this with
values directly in the subclass view within the

Also, run a learning cycle. If it's a impedance tracking device. So this will
update the internal impedance chemical capacity to match the cell, verify
performance. And then you will also export the golden image. But this time, the
golden image, it's only one.

It's called the gm.fs for ROM gauges. It's, again, a Flash Stream file. And this
contains all the instructions that need to be executed on the control interface to
program the gauge with the configuration that you put in to the Data Memory view in
bqStudio.

The tricky thing here is that, because it's a ROM gauge, the ROM gauge is going to
lose all its configuration on a reset, a power cycle. So now you would have to
program this gm.fs file after every gauge reset. You can either write device
driver, which can parse this file and execute each instructions from this file. Or,
if you have a limited system where you don't really want to do this or you can't do
this or it would be disadvantage-- for example, if it's a barebones system where
you don't have a file system-- you then would have to write some code that follows
the sequence required by the gauge to update the data memory after every reset.

So that's one of the disadvantages of ROM gauges that you will have to develop a
device driver for the gauge that is more than just read the state of charge. The
last part of the presentation actually shows how that is done on a MSP430, a system
that doesn't have a file system. So we can't just use the gm.fs file, but where you
have to write code to accomplish that task.

Back to some of the steps during configuration, so how do you obtain the ChemID or
the coefficients for a CDV gauge? TI has an online tool called GAUGEPARCAL, or GCP.
It's a gauge parameter calculator.

So what it does is takes data that you logged with your battery and something like
this GDK, runs it through its own matching algorithm, and then it returns a ChemID
for IT gauges or CDV coefficients for CDV gauges. And the tool is accessible
through this link here.

So the input is a log file that consists of time. So this example shows that every
10 seconds, i take a measurement of current. This one is in milliamps, voltage, or
millivolt, and temperature in degrees Celsius. So then I do this for the whole
discharge curve that is required by this tool.

And this is all explained in the user's guide for that tool. And then I take the
file, send it to that TI online tool. And the TI online tool is going to return
either the ChemID or the CDV parameters, coefficients.

So that's how that looks on the TI side. You upload a zip file with the battery
characterization data to the GPC. It will email you back the results to the email
that you registered on myti.com. So there's no need to install any software. It
just uploads the zip file through a browser.

So the input, this is an example for an IT gauge. The input here, we call it RDR,
Relax-Discharge-Relax log. So the important thing here is I have a relaxation
period where the battery is fully charged. . Then I discharge it with a constant
current until it hits a termination voltage.

Then I have to let it relax again. I log that data every 10 seconds. And I save
this together with the configuration text file in an archive. And I send that to
this GPC tool. And the output is going to be, for IT gauges, best ChemID match. Or,
for CDV gauges where you actually have to send a set of these log files to the
tool, then it will return coefficients.

So this is an example output from the GCP tool. That's what's being sent back to
you through email. And so this is an example of an impedance tracking gauge. So
this one says, OK, my best ChemID would be 3131.

So you can see that the maximum deviation is only 0.6. If you want to use a flash
gauge or OTP gauge, then there are two options. One is you send the cell to TI. And
TI does the full characterization. So that's the best method, because you get the
best possible result.

And TI creates a brand new ChemID for your specific cell. And then you don't have
to do that. So the disadvantage with this is that it's going to take several weeks
until this is completed. So even if you do this, you may want to start out
development already with a ChemID that is close enough. And then you can do this.

It may sound a little bit complicated, but it really isn't. If you have something
like this GDK here-- and unfortunately, I can't really show this during the
presentation. Because it takes up about 12 hours or so, yeah. So it's a very slow
process. But it's much faster than three weeks, yeah.

And it's very simple. You just have this GDK connected to an EVM. And bqStudio has
an automatic cycling feature that run this profile, and then log the data. If you
have a matched cell-- sorry, if you have a custom ChemID, then you don't
necessarily have to do this. But then you would have to wait until TI has finished
this.

From my own experience but maybe a little bit involved is to make performance work
really well at different temperatures, it becomes a bit tricky. So it's really
ideal if you have a custom ChemID generated by TI. Because then we do this, we
characterize the cell at different temperatures, which makes it more accurate. This
GPC, you can also run a low temperature [INAUDIBLE], where you submit another set
of log files for low temperature, like minus 20 Celsius.

And then it does an update to this ChemID, to the matched ChemID that we have in
the database. In most cases, you can just do a ChemID match. And it should be
really good. But if you need the very best performance, just submit the cell to TI,
and we do a custom ChemID.

If you go to that GPC website, that TI link that I supplied here, there is a PDF
for that. It explains exactly how to apply, what [? C ?] [? rate ?] you have to
apply, how to assemble these log files, and how to submit them. For the ChemID
match, you only use one cell.

OK. So that's the output from that ChemID match from GPC. So this example shows
that the best ChemID was 3131. It just gives you a list of ChemIDs that are a match
with the order of maximum DOD error.

So the further down you go in this list-- and that's a long list, so I cut it off
here-- that DOD error is going to go up. And then it also gives you information
about how well a cell matches with our ROM gauges. For example, for the 27421-G1D,
which has a generic ChemID built in of 3142, which you cannot change, because it's
the ROM gauge, I see, OK, this is 2.01%. Not great, OK

So maybe if I want to use a ROM gauge, I could use this gauge here, the G1C 27411.
Because it's got a decent DOD error of 1.63%. Don't use this one, because that's
completely not working with that gauge.

So that's the [INAUDIBLE] basically. Because you would get a ChemID. And if you
want to program this to the device, then you just go to bqStudio. So there is a
button chemistry. And then that chemistry shows a list of chemictrieis that it
knows.

So if I sort this by ChemID here and go down to 3131, which would be this here,
just select that, and then click Programs [? Selected ?] Chemistry. When I click
this, bqStudio is going to program the flash gauge with that chemistry. So that's
how you program a flash gauge for a specific cell.

You correct [INAUDIBLE] [? cell ?] with sequence that is described in the document
for GPC, submit that log data. Keep GPC is going to return to ChemID. And then you
go into the Chemistry tab in bqStudio and select the ChemID, and hit Program [?
Selected ?] Chemistry that's programmed into that gauge.

Together with the basic configuration and a learning cycle, this is enough to
produce the golden image. So if I click Create Image Files, then the output's going
to be this .srec, the bq.fs, the df.fs. And that contains all the information
necessary to program the gauge.
This only shows the maximum DOD error. So sometimes if the maximum DOD error is too
big and you really, really want to use that gauge, what would make sense is to run
performance analysis where you charge up your battery, then you discharge a
constant current, log the SOC, and then plot the difference between the ideal SOC
drop and the actual SOC drop, which gives you this error information. And then if
that is below the limit that you can accept, then you can still use the gauge.

The reason I say that is because it really depends on where that max DOD error is.
So it can be anywhere in this discharge curve here. It may also be outside of that.
Because if you have a different terminate voltage, you will cut it off anyway. So
what if the DOD error is outside of your interesting voltage range, then you may
accept that.

So that's something where this is very difficult to give a hard number in my

opinion. The error that we have here is actually an max DOD error. So that's the
discharge error that you can expect with that ChemID that was matched with GPC and
your actual cell.

But what I want to say is that this max DOD error, it doesn't mean that at any
point of DOD you're going to have this error. So it could be that your SOC that
your interested in-- so the range of 0% to 100% SOC is not necessarily the same as
full [INAUDIBLE] of discharge 0 to 100. Because you narrow that down with your
terminate voltage.

And if your system has a fairly high terminate voltage, the maximum DOD error maybe
outside of the [INAUDIBLE] of discharge that you will ever reach with your cell.
And so then it may still be possible to use a gauge. And that GPC shows a fairly
high error.

But the point is if it's close to what you can accept, it makes sense to run a
performance analysis from 0% to 100% SOC with your terminate voltage parameter. If
the error is still high and there's no ROM gauge, that has a lower error than what
you can accept, then a ROM gauge is really not a good choice. You should then use
either an OTP gauge or a flash gauge. Because these you can then program any ChemID
that we have in our database.

Or, you can also program a ChemID that is custom made. So if GPC does not detect
any ChemID that is good enough for your requirements, then really the only other
option is to do a custom ChemID. But that takes a while.

You can do this by part number. Also, the data sheet [INAUDIBLE]. If it's 275xx,
it's flash. If it's 274, it's ROM and/or OTP.

I mentioned the ChemIDs for IT gauges or other class of gauges, CDV gauges, they
don't use a ChemID. But they use CDV coefficients. These require a much larger set
of log files to obtain.

And because this is a bit more complicated bqStudio has a GPC package or feature.
So if you hook up a CDV gauge to an interface and launch bqStudio, after
configuration you can also go to the the GPC package, which is available through a
button. in bqStudio. And then this is going to create the zip file that you will
have to upload to GPC to obtain CDV coefficients.

OK. So here, production line programming tools, we have bqStudio. So you can use
this to [INAUDIBLE] gauges with srec, bq.fs, and df.fs files connected to PC
through an interface. .srec and bq.fs contain complete images, flash and data
memory. df.fs contains just the data memory.

If you want to use OTP gauges, you will have to use SmartFlash, which is a
standalone tool. Here's a screen shot of this tool. It's very straightforward to
use.

You just open that bq.fs, df.fs, or ot.fs file, connect the EVM, this interface
here. I click on Program, and this will program the gauge with the content from
this Flash Stream file. This is something that we use in production for flash and
OTP gauges.

So Flash Stream files, anything that ends with .fs is called Flash Stream. It
replaces all the file formats. The main rationale behind this is that if you want
to have the ability to understand what is in the file by just reading the file,
that's possible with Fresh Stream. Because they contain [INAUDIBLE] write
instructions basically.

It's much more difficult to do this with all the older file formats, like .srec, or
.senc, or .dfi files. Because these don't have any. So these just write to
[INAUDIBLE] in flash. So it loses that information for the end user, also for us
apps engineers at TI. So that's one of the reasons why we do the Flash Stream
files, because they're easy to use.

So they're text files. And they contain write and compare instructions. And they're
executed when you program the gauge using bqStudio or SmartFlash.

So this is the basic format. We have for a letter first. The letter denotes the
command. W stands for Write command. Then you have a colon. Then in [INAUDIBLE]
number device address, which would be AA for our gauges, register address, which is
the I2C register that you want to write to, and then data.

So this supports multiple bytes. And it's all line based. And one line has the
write command, device address, register address, and then data. One example would
be this here, AA 00 01 00.

As you can see, very easy to interpret. It writes to the device, the I2C device
address AA. Register is 0. Data, 01. Register, 01. Data 00, which means I'm writing
to the gauge and in firmware mode. Register 0 and 01 is the control command. Data
is 0001, which is the subcommand 0001. And that means device type.

So what this does is it asks the gauge to supply its device type. The next command
is Compare. It starts with a C. And the format is the same, device address,
register address, data.

And what that asks the parser to do is please read from device address AA, starting
at register 0, 2 bytes, and compare them with 21 and 06. So this one here would be
asking the gauge to supply its device type. For the 27621, the return value would
be 0621, which means I want to compare now, OK, is it really returning this?

That's like I send a check for the Flash Stream file to make sure that it actually
programs the correct gauge. And so the Flash Stream file then would ask the Flash
Stream parser to read 2 bytes from AA, register at 00, and then compare it with
0621. Then it either throws an error if it's not the same. Or, it continues,
because it passed that test.

So this is an example. The first one is one that i just showed. It asks my gauge to
issue the device type, compares it to 0621. The next command, it issues a firmware
version subcommand that asks my gauge to return its firmware version. And it
compares it with 0105.

These lines here, they don't really program anything in the gauge. But they ask the
firmware parser to verify the existing firmware version and the device type. So if
the Flash Stream parser, [? x ?] [? equals these ?] lines, it basically verifies
that the gauge that's connected to the host controller is the one that this Flash
Stream file was written for.

There is one more Command It's called x, which is the delay command. And the
parameter is milliseconds. So some of the commands require a delay before they are
completely executed by the gauge.

And for this, the Flash Stream file contains this x command. So when the host or
micro controller parses that file, and it encounters that line, then it would have
to stop execution for x milliseconds before continuing with the next command. The
example would be x10 would be a delay for 10 milliseconds.

If you use a ROM gauge, you would have to program the data memory. And for this,
you would use the control interface. We use basically two different interfaces. One
is I2C/SMBus, 2 wire, or HDQ.

Flash Stream files, they don't really care which one is used. Except if you used
HDQ, then they don't use the device address. But they're compatible with both. For
I2C, it's basically really standard. This is an example of a write/read.

So here, I'll first apply the device address AA, then register that I want to read
from, switch to a read again. So this would be AB, because the read bit is set. And
then the gauge is going to return the data that was requested.

The one thing that is important and that's maybe a little bit confusing in our data
sheet is if you [INAUDIBLE] that having requirements to that bare minimum, what
really would have to do is you have to insert a 66 microsecond delay between every
stop and start condition. So this is one of the hard requirements for the gauge.
You will have to insert a 66 microsecond delay.

Otherwise, the gauge may not be able to handle the next command on the I2C. If you
want to do incremental write, so if you want to write more than one byte without a
stop start condition between bytes, you can only do this if you use an SCL
frequency of less than 100 kilohertz. If you go above 100 kilohertz, then you can
only do single byte writes.

If you look into our data sheet, we say no more than two standard commands per
second. So that's in all of our data sheets. It's a very conservative rule. And the
Flash Stream files break this rule basically all the time, which really isn't that
great. Because our data sheet is, in a way, contradicting our Flash Stream file.

But the Flash Stream file has this x command, which adds the delays that the gauge
really needs. So the data sheet is really going for the safest possible
requirement. If you would not follow these delay commands or if you would issue
more than two set of comments per second, and you do this very fast, then there's
the possibility that the gauge internally has a [? watchdog ?] time that it expires
and it resets.

So this rule was added, because hammering the gauge with commands because
[INAUDIBLE] [? watch ?] [INAUDIBLE] time it expire resetting the gauge. So I put
this here, because when I first read the time information for the data sheet, that
really tripped me up. Because it seems so conservative that you can only do 2
static commands per second.

I want to make the point that this is a very conservative rule and our Flash Stream
files take care of that. So you can write to a gauge much faster than what this
rule suggests. A Flash Stream file contains a complete configuration.
So everything required to write to a gauge is in the Flash Stream file. So if you
execute a Flash Stream file line by line, all the compare commands succeed, then
you can be ensured that the gauge is programmed with exact configuration that you
put into bqStudio for the gauge. So if did all the configuration in bqStudio, the
verification, learning cycle, then you export it, and your host controller can
execute or parse that file, then the gauge is going to be programmed correctly in
your system.

The host [INAUDIBLE] just has to execute each command. The driver does not really
know how to program the data memory. Because it's a fairly complicated sequence. It
can be slow, but it's simple.

We have example code for this. So we have code that's written in standard C,
[INAUDIBLE] [? C, ?] so it doesn't use any fancy libraries, very simple to port. It
has a Flash Stream parser, which performs execution basically of this Flash Stream
file. And it also contains APIs to update the data memory without having to parse
that whole file. So if you just want to update some parameters, you can just use
this example, code the APIs to do that.

Data Memory Access, you cannot directly access it. It's indirect addressing. If you
look at this the first time, it seems really complicated. That's why we have
example code. Or that's why if you use flash or OTP gauges, you can just use
programming tools to do this.

But if you use a ROM gauge, you will have to go through a fairly complex sequence.
For example, for a ROM gauge, you would have to first set it in a specific mode,
CONFIG_UPDATE mode. Then you have to write a subclass number, a block number, Then
you have to write BlockData. And then you have to calculate a CheckSum.

And only then, once you went through all the sequence, only then is the data memory
going to be updated with the new configuration. So it's fairly complicated. And
obviously, it makes a lot more sense if we give you code that does all that. And we
have the code. And it's very easy to use.

So it's always independent. It consists of a Flash Stream parser and a gauge

command, subcommand, and data memory APIs. It can easily port it to a high level
OS.

We do not really officially maintain high level OS code. So there is some code out
there for Linux. We regularly get requests for code and questions about that code.
But it's really not maintained by TI. It's a more open source community effort. But
if you're interested in that, it's available in the official Linux [INAUDIBLE] [?
tree. ?] And here's a link to that.

So this has a code that open source community wrote for gauges. It's not based on
our example code. But you can use this as a starting point if your operating system
is Linux. But if you use a system without a high level operating system, it may
make more sense to just use our example code.

So the example code uses two function data has to be implemented for a specific
system. There are very straight format. One is gauge_read. One is gauge_write. So
these functions, APIs, specify a register, and then a block of data, and a length
of data, either read or write.

We have example implementation for Linux and also example implementation for
MSP430, which I'm going to show at the very end of this presentation. So this would
be one implementation for Linux. It's very simple.

So in Linux, we basically just open up a file handle to a Linux I2C [? def ?] API,
and just the Linux write and read commands and at my 66 microsecond sleep. So this
accomplishes what I need to do in Linux. Write is very similar.

Then we have this Flash Stream parser. It's very simple if you use our example APIs
and code. You just [INAUDIBLE] a pointer to a memory that contains this Flash
Stream fine as text and call this function. And this is going to take care of
everything else.

Then we have gauge commands. We can read from the gauge, write to the gauge. We can
control-- we have a command for subcommands. which are called gauge_control [? with
?] [INAUDIBLE] submit the subcommand.

You can read from the gauge data memory with read_data_class and write_data_class.
We also have example APIs here. And there's one more example that I wanted to show
on my computer here, which is the MSP430 implementation. which really I think makes
the point how easy it is to use.

So this would be an example how to use this on an MSP430 or stand in for any
microcontroller basically. So you import our gauge API. Then you have for your own
gauge I2C, which implements those two functions that I was talking about. And this
example is for ROM gauge, where I don't have a file system where I cannot store the
Flash Stream file. But instead, I just want to set the basic gauging parameters,
which are the design capacity.

So this battery has a design capacity that's [? 3,210 ?] [INAUDIBLE] hours. The
number of voltage is [? 306 ?] volt. I calculate the design energy, which is just
the voltage multiplied by the capacity. I specify my terminate voltage, my taper
currant, and taper rate.

The use is very simple. I open up my I2C connection, then I read the data class. So
I want to read the data state, which is the one that holds all these parameters. I
write the design capacity to its respective offset.

So design capacity would be at offset 10. Design [? energy ?] would be at offset

12. Terminate voltage would be offset 16. Tape rate at offset 27.

Once I have wrote this to my class here, set the gauge into a [INAUDIBLE] update
mode, which allows it to update its data memory, I'm going to write that whole data
class here. And then I tell the gauge to use that data with the soft reset
commands. And from this point on, the gauge is configured. And then I can read the
temperature, the voltage, or the state of charge.

So this is an example of how you would use the gauge with a microcontroller that
does not have a file system. Thank you so much for listening to my presentation.
And I hope that you can configure and program gauges with this information.