For the foreseeable future, much of modern mobile and embedded consumer electronics will be ruled by the amount of battery power available in wireless untethered designs. Although much work is being done to create a variety of energy harvesting schemes to make such devices truly independent, batteries will always be there in some form to provide a backup and as sources of constant and regular power to drive the electronics.
Billions of lithium-ion batteries are in use; an increasing number are in rechargeable formats. There are many different, mostly proprietary battery interfaces. This lack of a commonly accepted battery interface standard has caused extra work and logistical effort throughout the industry.
The one point of agreement amongst all these different schemes is the importance of using some sort of smart battery technology by which information is exchanged between the mobile terminal host platform and the battery pack. Smart battery technology significantly improves the safety of the end users by providing access to reliable battery authentication, versatile sensing of operating conditions (e.g. multiple temperature sensors, stress sensors, etc.) and comprehensive battery related data sets (e.g. manufacturing parameters, charging recipes). In particular, battery authentication with cryptographically strong algorithms improves end user safety by eliminating the use of potentially dangerous counterfeit batteries not complying with the required safety standards  or incompatible with the charging parameters of the mobile device.
Unfortunately, without common agreement as to what ‘smart’ means in the context of rechargeable batteries, mobile device manufacturers must coordinate, specify, and maintain proprietary solutions from different parties in the ecosystem – themselves, mobile chipset suppliers, battery IC suppliers, and battery pack manufacturers.
Under the umbrella of the MIPI Alliance, the solution to this and other troubling battery problems is working its way through the consumer and mobile industry. Several stakeholders in the mobile device industry started to develop a new industry standard for battery interfaces in the form of MIPI's Battery Interface Specification (BIF) . (For a complete description of the specification and its impact on how mobile device developers can incorporate it into their SoC designs read BIF – Battery Interface Standard for Mobile Devices , a paper presented at the 2013 Custom Integrated Circuits Conference.)
This article will first look at some techniques and rules that have emerged to help both vendors and users in managing the use of rechargeable batteries, then outline the basic parameters of the BIF specification, and conclude with a description of how it deals with what several characters in the 1967 movie Cool Hand Luke would call “a failure to communicate .”
The many rules of battery charging
Battery charging requires particular attention to ensure safe operation for some battery types. This is specifically true for the Lithium-based batteries widely used in portable devices today (see also ). While charging these batteries, appropriate constraints must be followed to control charging current and voltage precisely. The charging segment, defined as the charging voltage and current combination, depends generally on battery temperature and battery voltage. The charging segment is selected by a charging algorithm and applied on a precisely controllable CC/CV (constant current/constant voltage) charger.
For a given battery, a charging profile, composed by a set of charging segments, can be established so that charging is safe over temperature and battery voltage, an example of which is shown in Figure 1 . Disrespecting this charging profile may result in various defects such as accelerated aging of the battery, over-heating, or even battery physical damage that can cause end user injuries.
Limitations of conventional charging. A portable device charging subsystem is usually designed for a specific battery or family of batteries. It usually cannot guarantee safe operation or identical performance when used with batteries other than the design prototype. This inflexibility limits the choice of battery throughout the product life.
This strong link between a portable device and a battery type is a significant limitation, e.g. considering the effect of this product design on the multi-sourcing of batteries. Logically, each source of the battery would provide its essential charging profile to the charging subsystem and the product charging subsystem would adjust appropriately.
But with a fixed charging subsystem, the approach is quite the opposite: the charging subsystem sets the charging profile requirement for the battery sources. This often results in reduced charging performance and batteries from different sources are not utilized optimally. It could also result in higher battery unit cost from a given battery supplier because they may need to modify and customize their battery design to support the established charging profile for the charging subsystem of each portable device.
The strong attachment of a battery type to a portable device charging subsystem may also limit the use of newer or improved battery technology that requires a different charging profile. Once the portable device is widely available in the market to the end users, it usually cannot use the latest most advanced batteries or even adapt an updated charging profile (for example, improved safe charging rates).
In the same way, the end user may not be able to effectively use higher capacity batteries in after-sales markets – probably it would take a longer time to charge than necessary for the new battery or perhaps operate with underutilized capacity. In the desire to implement charging for various batteries and chemistries, classical software state machines have grown more and more complex and have become harder to maintain.
Battery/device communications is the key
Because so much of the confusion in rechargeable battery managing seems to be about how the battery subsystem communicates with the mobile system within which it resides, BIF deliberately deals with and defines the communication interface only, so the actual power delivery interface and the mechanical parameters of the battery are out of its scope. Nevertheless, BIF brings an impressive array of capabilities to the table.
First of all, BIF minimizes the interface cost since it requires only one pin in addition to the power terminal of the battery. The mechanical pins of a typical battery pack have high reliability requirements due to a harsh operating environment, and take valuable space in the mobile device. These pins are a relatively high-cost component in a mobile device.
BIF implements a simple multi-drop interface structure with one master device and one or more slave devices. It allows connecting multiple ICs on the same single wire bus. A smart battery may include multiple slave devices within the battery pack. The mobile device PCB may contain multiple slave devices, in addition to the master device.
The communication speed of the interface is dynamically scalable to match various available clock sources in the mobile device system under different operating conditions or data speed requirements.
A transceiver for a BIF master can be implemented with a serializer/de-serializer in hardware, or with software driving and sensing a general purpose I/O pin directly.
A fast (approx. 1ms) battery-pack presence detection is implemented without additional wires or contacts to inform the system immediately if the battery pack is disconnected. If the mechanical design of the battery pack connector assures that the communication pin is always the first one that disconnects, this can grant some time for system software to still perform critical shutdown actions.
While battery removals or longer contact breaks are detected and reported, short signal glitches due to contact instability, ESD, or supply voltage bounces can be tolerated in communication.
BIF allows for a cost-efficient implementation of data transceivers. A slave device can be built with an inexpensive and inaccurate clock source. The BIF protocol is constructed to cope with these inaccuracies.
With respect to the mobile device chipset BIF is designed for low-voltage operation, supporting I/O voltages from 2.8V down to 1.1V. This enables interface implementation in the latest semiconductor processes.
Apart from physical layer and link layer protocol, BIF also defines higher level data structures. For certain standard functions (e.g. temperature sensor, non-volatile memory) standard register layouts are defined to enable the use of a generic software driver in the systems.
BIF allows manufacturer-specific functions in addition to the basic functions defined by the BIF specification. This enables slave device differentiation in the market and access to new innovative functions through the same unified interface. BIF also takes care of storing non-volatile data at different phases of the battery pack production chain and during normal use of the battery pack.
The BIF architecture
BIF adds only one single wire (the battery communication line, or BCL) to the two power connectors (VBAT, GND) of the battery pack. Communication signals are exchanged via BCL with reference to power ground (GND).
BCL carries all BIF-related signaling including battery presence detection, analog battery identification, and distinction between analog and smart batteries, as well as data communication.
BIF data communication comprises of exchanges of data, address and command words, an in-band interrupt and wakeup from power-save modes.
There are two types of devices on a BIF bus, master and slave. There is only one master per BCL but there may be multiple slaves. Slaves may be located both inside the battery pack and on the mobile device side of the battery connector.
There are two types of slaves, primary slaves and secondary slaves. Primary slaves have a reserved address and may carry information about the other slaves found in a battery pack. Primary slaves need to have non-volatile memory in order to carry this information.
The BIF master device is typically placed in the power management IC (PMIC) as illustrated in Figure 2 . Alternatively it can be placed on the digital baseband (BB) IC.
The BIF protocol
The BIF protocol is designed as a datatransport interface. The actual battery applications, such astemperature measurement and authentication, make use of the protocol butdo not interfere with it. Data transport and battery application usagesare clearly separated.
One of the main objectives in BIFprotocol design was to achieve flexibility while maintaining smallsilicon size. Hardware BIF transceivers can be implemented withapproximately 1k gates in a typical CMOS process.
The BIFcommunication data rate is scalable between 3.27 kbit/s – 250 kbit/s(average). The minimum data rate was extended down to ~3 kbit/s becausein many systems there is a 32.768 kHz clock available due to a real-timeclock requirement. This enables BIF communication even in power savemodes when only this clock is available in the host.
The maximumdata rate was limited to 250 kbit/s to minimize the slave devicereceiver complexity. This was analyzed to be sufficient for the currentuse cases of BIF (e.g. allowing reasonably fast authentication). Howeverhigher speed definitions may be added to the BIF specification in thefuture.
BIF communication is always initiated by the master andis based on a data word. The master defines the communication speed inthe beginning of every word and the addressed slave must use that speedin its response. So in theory, each transaction between the master andthe slave could happen with a different speed.
Time Distance Coding. BIFsignaling is based on the elapsed time between changes of signal level.This will be also referred to in the following as “Time DistanceCoding”. The signal level can be either High (= high voltage) or Low (=low voltage, close to GND). The time between polarity changes isclassified into three duration classes. Short durations denote a logic0B, long durations denote a logic 1B, and very long durations signal aSTOP condition.
Figure 3 shows the transmission of twosubsequent BIF words. Words are separated by STOP codes and contain anodd number of bits. The STOP signal is only sent at a high voltagelevel, whereas 0B and 1B are not associated with a voltage level.
BIF data words. BIF defines data words of 17 bits in length as depicted in Figure 4 . This requires the BCL to toggle 18 times per word. Each 17-bit data word consists of the following elements:
- Training Sequence, BCF -> 2 bit
- Payload, D[9:0] -> 10 bit
- Parity, P[3:0] -> 4 bit
- Inversion -> 1 bit
Adata word can carry a command, a device or register address, read data,or write data. The training sequence bits are used to tell thecommunication speed and also tell whether the word is a Broadcast type(intended for all slaves) or a Unicast/Multicast type (intended forselected slaves).
Thepayload is the actual data to be transported. The use of 10 bits allowsthe system to distinguish between commands, device addresses, registeraddresses, and read or write data.
BIF slave data structure. BIF provides up to 64 Kbytes addressable register and memory space foreach slave. Certain rules determine how this memory space shall bestructured. Moreover, for certain standard functions, register layoutsare mandated. This allows building generic software drivers. However BIFalso provides support for vendor specific functions to enable slavedevice differentiation in the market.
An example of BIF slave data structure is illustrated in Figure 5 .Memory locations can be used for different storage types such as RAM,ROM, or reprogrammable NVM. The data map always starts with a fixedlength 10-byte Device Descriptor Block (DDB-L1) defined by the MIPIAlliance. DDB-L1 contains generic device identification information likeManufacturer ID and Product ID. The last two bytes of the DDB-L1 tellthe total size of the function directory following immediately after theDDB-L1.
Charging with BIF: changing the rules
BIFprovides the User NVM function and the standardized data object storagemechanism to clearly separate the charging control software running onthe host from the actual battery-related charging parameters stored inthe battery pack (see ). Each battery pack may come with its ownoptimal charging recipe. The charging recipes may even be modified overthe production life of a battery.
BIF proposes a “Rule BasedAlgorithm” for host-side charging control that specifies thebattery-related charging rules to be stored inside the battery pack.There may be additional system-related charging rules stored on the hostside. This algorithm is implemented on the host once when the mobiledevice is designed and can remain unchanged regardless of the batteryqualified for the particular device later.
Figure 6 illustrates how Rule Based Charging is performed. In the acquisitionphase the set of charging rules is read from the battery pack. In thevalidation phase all rules are checked if they are valid under theprevailing operating conditions (valid rules are marked in green andinvalid ones in red in Figure 6). In the election phase the rule withthe best charging performance is selected from the valid rules(encircled in blue in Figure 6).
Sincethe rules are stored in prioritized order, this is the topmost validrule of the list. And finally in the application phase the chargingcircuit is programmed to the charging current or voltage stored in thisrule. Each charging rule stored in User NVM contains the parameterslisted in Table 1 .
What about analog ‘dumb’ batteries?
BIFis intended to support both traditional analog batteries as well assmart batteries. Support of low-cost analog batteries is required forlegacy designs and for the simplest mobile devices. Most of the low-costbatteries currently in the market have a built-in pull-down resistor inthe battery pack.
The measured value of the pull-down resistorusually represents certain capacity and chemistry information of thebattery pack. For this function, the BIF standard supports measurementof a pull-down resistor value with a defined range and accuracy.
Severalmanufacturers now are sourcing BIF-compatible parts and significantadoption is expected before the end of 2014. Earliest adoption isexpected in mobile phones and tablets, to be followed by cameras andultrathin laptops. BIF interoperability testing is offered by UNH-IOL(University of New Hampshire Interoperability Laboratory). An example ofa MIPI BIF-compliant slave device implementation from InfineonTechnologies is shown in Figure 7 .
MIPIBIF presents a comprehensive standardized interface solution for themanagement of rechargeable batteries used in mobile devices. Itaddresses all the functionality needed for safe and efficient batteryoperation from physical interface implementation to host controlsoftware design. It enables smart batteries with highly desirablefeatures such as cryptographic authentication of batteries andrule-based charging.
MIPI BIF is supported and maintained bymajor stakeholders in the mobile device industry , andinteroperability testing is offered by the University of New Hampshire Interoperability Laboratory (UNH-OL).
Wolfgang Furtner received a degree in electrical engineering at the PolytechnicalUniversity in Munich, Germany. He worked for 11 years at PhilipsSemiconductors developing SOC (system on chip) architectures for videoand graphics applications. He has been with Infineon since 2006 and works as a Senior Principal Architect on systemarchitectures, algorithms and methodology for power conversion systems.He is a member of the MIPI Alliance Battery Interface [BIF] Working Group since its foundation in 2010, and currently acts as its vice chair.
Lionel Cimaz received a BSc degree in electronics from ENIB French graduateengineering school in 1997. After some activities in sound engineering,he worked for Mitsubishi Electric Telecom Europe in audio and powerareas from 2000 to 2003. Up to 2013, he worked for microelectroniccompanies including Silicon Laboratories, NXP, and ST-Ericsson,addressing the mobile phone markets. His contribution in audio and powerarea was covering system architecture, analog and digitalarchitecture/design, and audio algorithm development. Since 2013, he hasoccupied the position of Senior Principal Engineer in STMicroelectronics power conversion division.
1. BIF –Battery Interface Standard for Mobile Devices . Custom Integrated Circuits Conference (CICC), 2013 IEEE, 22-25 Sept. 2013
2. MIPI BIF data sheet , MIPI Alliance, February 2012
3. MIPI BIF Whitepaper , MIPI Alliance, February 2012
4. IEEE1725-2006, IEEE Standard for Rechargeable Batteries for Cellular Telephones , Institute of Electrical and Electronic Engineers, 2006.
5. SP 800-57, Recommendation for Key Management – Part 1: General (Revised) , National Institute of Standards and Technology, 8 March 2007
6. A Guide to the Safe Use of Secondary Lithium Ion Batteries in Notebook-type Personal Computers , Japan Electronics and Information Technology Industries Association and Battery Association of Japan, April 20, 2007
7. MIPI BIF rule based charging whitepaper , MIPI Alliance, 2013
8. MIPI Alliance Member Directory , MIPI Alliance, 2013