Introduction
The MAX17205 fuel gauge IC utilizes Maxim’s ModelGaugeTM m5 algorithm to accurately track the state of charge of a multi-series cell battery pack. It combines coulomb counting, voltage monitoring, and temperature compensation to improve accuracy while also offering several useful features such as cell balancing, overcurrent comparators, a configurable alert signal, SHA-256 authentication, smart battery compliant operation, and more. Naturally, this device requires an initial configuration to tailor it the battery’s specifications and enable/disable the desired features. However, it may take several attempts to get every register set correctly to achieve desired device operation and, unfortunately, these nonvolatile registers can only be written 7 times by the user. In order to circumvent this limit for prototyping, the user must be able to load their configuration to the device without storing it in nonvolatile memory.
This article exclusively references the MAX17205 fuel gauge. However, the same principals apply to the MAX17201, MAX17211, and MAX17215 fuel gauges. The only differences between these devices are the cell count and communication interfaces used.
The Memory Space
The memory space on the MAX17205 is organized into several functional blocks. A basic understanding of the two most important of these blocks is necessary to fully grasp the process of testing an application specific configuration on the device. The first of these is the discontinuous block of ModelGauge m5 registers, summarized in Table 1. These registers, which span pages 0x00 – 0x04, 0x0B, and 0x0D, are essentially the inputs and outputs of the ModelGauge m5 algorithm. The inputs contain information about the cell, the fuel gauge application, and real-time system measurements. For example; the DesignCap register (0x018) holds the expected capacity of the cell, VAlrtTh (0x001) sets the upper and lower cell voltage limits for the alert function, and Current (0x00A) stores the latest voltage measurement across the current sense resistor. These registers can be read from/written to directly via the I2C communication interface.
The second major block is the nonvolatile memory, outlined in Table 2. Located in pages 0x18 through 0x1D; this section contains backups of the previously mentioned ModelGauge configuration registers, characterization tables, device information, and general purpose user memory. For example; the value stored in the nDesignCap register (0x1B3) can be configured to restore the DesignCap register (0x018) on power-up or hardware reset, the nXTable registers (0x180 – 0x18B) may contain custom cell characterization information for the ModelGague m5 algorithm, registers 0x1D8 – 0x1DF contain the device serial number and name, and there are several user memory words (label nUser) scattered throughout the nonvolatile block. Unlike the ModelGauge m5 registers, the nonvolatile memory cannot be written to directly via I2C. Rather, the user must read from/write to the shadow RAM located at the same address space and use the COPY NV BLOCK and NV RECALL commands to interface with the nonvolatile memory, as shown in Figure 1. The NV RECALL operation occurs automatically when the IC is powered up and after a hardware reset, but it can also be done manually by writing 0xE001 to register 0x060. To carry out the COPY NV BLOCK operation, the “Nonvolatile Block Programming” section of the datasheet should be consulted as there are many steps involved [1]. The major limitation with this command is that it may only be executed 7 times, leaving very little margin for error when loading a custom configuration on the device.
Finally, a quick note on the I2C slave addresses of the MAX17205. There are two addresses used to communicate with this device, and which one is used depends on the memory range being accessed. Table 27 of the datasheet specifies that the slave address is 0x6C when accessing memory in the range of 0x000 – 0x0FF and the slave address is 0x16 when accessing memory in the range of 0x180 – 0x1FF [1]. However, the datasheet does not mention that these are 8-bit addresses rather than the more common 7-bit address. Essentially what that this means is that they have been “pre-shifted” to the left by one to make room for the read/write bit, as shown in Figure 2. Therefore, the 7-bit addresses are 0x36 and 0x0B respectively.
Getting Around the Nonvolatile Memory Write Limit
When configuring the MAX17205, there are many settings to keep track of. Not only must the user figure out how to properly enable all the device’s features that are required by the application, they must also figure out how to disable those that are not. What’s more, the datasheet itself is rather scattered and, on occasion, self-contradictory (see page 78 [1]). It’s highly unlikely that during initial development, there will be no mistakes made on the first (or even 7th) attempt to properly configure the device. One should also keep in mind that the configuration may have to be modified in the future as the application changes or errors in the previous configuration come to light, making it necessary to keep a reserve of available nonvolatile memory updates. Clearly, what is needed is a way of prototyping a configuration before committing it to nonvolatile memory to avoid unnecessarily wasting one of the updates.
As it happens, this device includes a command that can be used exactly for this purpose. The Fuel Gauge Reset command (not to be confused with the Hardware Reset command) will reset the operation of the fuel gauge without restoring the nonvolatile memory block to shadow RAM. This way, the user can modify the values in shadow RAM as they would normally do to configure the device, but then execute a fuel gauge reset rather than a COPY NV BLOCK command. Since the shadow RAM will not be overwritten with the values stored in nonvolatile memory, the ModelGauge m5 registers will be initialized with the desired configuration values before the algorithm begins execution. The obvious drawback in this scenario is that the MAX17205 requires a time-consuming initialization procedure on startup and can no longer act as a standalone device.
Listing 1 shows the pseudocode for a simple initialization function that modifies several shadow RAM registers and finally resets the fuel gauge by writing 0x0001 to the Config2 register (0x0BB). Note the half second delay at the very end. This is used to accommodate the time required for the reset operation to complete (tPOR) as well as the 480ms required for the ModelGauge m5 output registers to become valid [1].
Listing 1: Example initialization pseudocode for MAX17205
void max17205_init( void )
{
// max17205_write_reg( addr, value )
max17205_write_reg( 0x18E, 0x0E0B ); // nODSCTh
max17205_write_reg( 0x18F, 0x4040 ); // nODSCCfg
max17205_write_reg( 0x19E, 0x9658 ); // nVEmpty
max17205_write_reg( 0x1B0, 0x0215 ); // nConfig
max17205_write_reg( 0x1B3, 0x27D8 ); // nDesignCap
max17205_write_reg( 0x1A5, 0x3454 ); // nFullCapNom
max17205_write_reg( 0x1B5, 0x0C02 ); // nPackCfg
max17205_write_reg( 0x1B8, 0x0930 ); // nNVCfg0
max17205_write_reg( 0x1B9, 0x080E ); // nNVCfg1
max17205_write_reg( 0x1C0, 0xD996 ); // nVAltTh
max17205_write_reg( 0x1C1, 0x2305 ); // nTAlrtTh
max17205_write_reg( 0x1C2, 0x6401 ); // nSAlrtTh
max17205_write_reg( 0x1C3, 0x00BC ); // nIAlrtTh
max17205_write_reg( 0x0BB, 0x0001 ); // fuel gauge reset
wait( 0.5 );
}
Conclusion
Due to its many configuration options, the MAX17205 is a good candidate for a wide array of battery management applications. With all of these settings, however, the user needs to be able to test their configuration so they can be sure they are not wasting one of their limited nonvolatile memory updates. Luckily, the solution to this is very simple and gives the designer every opportunity to verify the correctness of their configuration.
References
[1] Maxim Integrated, “Stand-Alone ModelGauge m5 Fuel Gauge with SHA-256 Authentication,” MAX17201/MAX17205/MAX17211/MAX17215 datasheet , February 2016 [Revised August 2016].
