Batteries
Since the beginning, Apple took a slightly different, but very intelligent approach to battery monitoring. Texas Instruments make some great products for Lithium batteries, including ICs that can charge, and monitor the health of a battery. The ICS can also track battery discharge, usage, capacity, and degradation over time. For this reason, they are industry leaders when it comes to this technology.
System Side Gas Gauge
BQ27441-G1 System Side Gas Gauge and Charging Monitor ICFor most device manufacturers, they use something called a “System Side” gas gauge IC. These ICs are usually found on the devices motherboard, and track the cells capacity using “Compensated End-of-Discharge Voltage (CEDV)”, or “Impedance Track™” technology. This technology is reasonably accurate, but requires the manufacturer to calibrate the data, and assumes that an installed battery will follow a certain discharge curve.
There are a few reasons to use this method of System Side monitoring. For one, the battery can be easily removed and replaced. Separating the battery from its Gas Gauge IC, does not require manufacturer intervention. That is, assuming your replacement battery follows the pre-programmed manufacturer expectations. Using a system side gas gauge, you can produce batteries with few parts. A PTC fuse and a thermistor for safety, is really all that’s needed. This makes production very cheap.
This also means each device only needs one Gas Gauge IC in its perceivable lifetime. Another cost benefit. Those cost benefits however, result in slightly less accuracy and features. The alternative, is a “Smart Battery”.
Pack Side Gas Gauge
SN27545, Similar to BQ27545So what is a Smart Battery? A Pack Side gas gauge has some great benefits, but is more expensive to produce. We see these in laptops all the time, usually using I2C or SMBUS communication. TI have their own communication protocol too, High-speed Data Queue(HDQ).
A Pack Side Gas Gauge can monitor all kinds of information. Everything a System Side gauge can store and more. For example, manufacturers can program serial numbers, batch numbers, and manufacture dates into the battery itself. The battery can record its own degradation and chemistry, and literally learn over time. A battery that can educate itself? Now you can see the “Smart Battery” reference right?
Replacing this battery will replace all of its associated data too. A device can read this data, and immediately report correct information to a user, such as battery health and percentage. Apple decided a smart phone, should have a smart battery. This allowed them to incorporate some other technology from TI, that uses the same HDQ protocol.
Unfortunately the protocol was so popular and documented, it also resulted in reproductions with less than desirable consequences. You can read about some of those consequences here, and see how we intend to correct a massive part of the device repair industry.
HDQ Communication
We could talk in depth about HDQ and Gas Gauge ICs, but to move forward in understanding some signature failures and symptoms, we will skip to the important part.
The HDQ protocol requires a pull-up resistor. In the case of Apple devices, this pull-up is internal to the battery itself, so the HDQ pin usually has about 2v in an idle state. Apple call this line Single Wire Interface (SWI).
When a device wants to query the battery data, which it does quite regularly, it pulls the line low in a specific pattern. The Gas Gauge IC then does the same, responding with the requested data. The communication is therefore bidirectional, and relies on the line being high in an idle state.
Typical HDQ Read Cycle
This is important, because the lack of a high logic line, or a high logic line in certain conditions, can result in different issues. We’ll look at those shortly.
Charging
To start with we’ll take a look at iPhones. Specifically iPhones that have an 8 Pin Lightning Port, and a dedicated protocol negotiation (TRISTAR), and charging IC (TIGRIS). From the iPhone 5 onward, the 30 pin connector was no longer used, and was replaced with an 8 pin connector. This 8 pin connector was still able to provide most of the same functions as its predecessors, by assigning up to 2 functions at any given time, to 2 sets of data pairs.This required the use of a new IC to handle this handover of functions, the Tristar IC (U2).
Lightning
1610A3 Tristar IC
U1700 – Tristar
The Tristar IC is sometimes called a “Charging IC”. In reality, the Tristar serves no charging function at all. Its purpose is to identify what is currently attached to the lightning port, and assign the correct lines to it. In the case of an audio accessory, this would be digital audio from the audio codec. In the case of a charger or USB connection, this is the USB data lines from the CPU. The CPU will then determine what type of charger is in use, by measuring the voltage on the data pins. Based on this assessment the device knows how much current it can draw from the 5V USB bus (500, 1000, 2000mA).
U1700 Tristar IC Schematics
U1703 – Accessory Power Switch
U1703 plays no role in charging. Its task is to provide power for external accessories. This power is distributed by Tristar where needed to up to 2 devices. Generally these are things like lightning headphones/DAC’s. Excessive current draw on these lines can cause Tristar failure very quickly. Despite this, there seems to be an abundance of devices like the “Lightning Fan” available, which are absolute tristar killers.
Q1703 – Reverse Polarity
Q1701s role is initially reverse polarity protection. By connecting the MOSFETs gate to ground, it is always on, provided the USB 5V is connected correctly. This line is not actually a power input, as you may have noticed by the fact that it exits the FET as a thin trace. The function of this line is to provide 5V logic power, which used to perform a “handshake”.
The handshake is part of the initial identification of the connected accessory. Without this power, the Tristars only power source is the 1.8 and 3V rails, which is not high enough voltage to communicate with and identify whatever is connected to lightning.
PP_TRISTAR_PIN is therefore very susceptible to failure, due to electrical noise. So are the 2 data pairs, 90_TRISTAR_BI_E75_PAIR*. If there is a failure at any of these points, or some other detected failure (like over-voltage), TRISTAR_TO_PMU_OVP_SW_EN_L will stay HIGH. This is important to other functions, as will be explained later.
iPhone 6 I2C Address Map
I2C Implications
Due to Tristars connection to the I2C0 bus, failure resulting in interference with this bus, can cause symptoms beyond just charging. If you take a look at the I2C0 bus address map, you will see not only is the bus shared by the Display PMU (Chestnut), and the Backlight Driver, but the PMU itself. Failure of Tristar in some circumstances can therefore cause entire device failure, resulting in no signs of life at all. This obviously isn’t the only cause of these symptoms, but it is one of them.
Electrical Noise
Electrical noise is measured Peak-to-Peak, and should always be lower than 100mV. Unfortunately, the market is flooded with aftermarket chargers that are not designed to comply with this low noise margin. Lets take a closer look at that.
In an AC to DC adaptor, such as that of a USB wall charger, the power initially enters as an AC waveform. With AC, the polarity alternates, so the power is both positive and negative. That AC is then “rectified” to DC. This results in the negative waveform being inverted. The P-P voltage is 100% of the peak voltage in this case. This is terrible.
AC Waveform
DC to AC Rectified Waveform
The waveform must be filtered with capacitors at the least. Generally, an array of different values, to get the smoothest ripple possible. A very, very simplified circuit explaining this is as follows:
Example of AC-DC circuit with filter
The resulting ripple should be no more than 100mV (0.1v) Peak-to-Peak. Generally, substantially less than that is acceptable. There should really be no detectable oscillation at all, and an oscilloscope is required in order to test.
Some chargers will produce noise under certain load conditions, or at certain temperatures. Testing chargers for noise is therefore very difficult, but it should be assumed that if an after-market charger has been used, the device has been subjected to some form of noise.
Inside an original, MFI certified Lightning Cable, there is some additional protection from noise, temperature, excess current, ect. The protection is minimal, but a lack of protection in your cable, combined with noise from your charging source, is a recipe for disaster. That’s not to say however that damage cannot be caused by using an original cable with a 3rd party power source, or that an after-market cable is certain to cause damage.
Tigris Charging IC
Tigris IC
Prior to the iPhone 6, the actual charging function was part of the devices PMIC. This means that a part that plays a vital part in the entire devices function, is prone to failure from external sources. Apple decided to change this as of the iPhone 6, which resulted in another new IC, known as TIGRIS.
Tigris does more than just charge your battery. It is capable of testing a variety of conditions, and determining when it is safe to do so. Tigris decides when PP_VCC_MAIN should be powered from battery, when it should be powered from USB, or when neither condition is safe.
U1401 Tigris IC Schematics
First, take note of the Tigris IC’s methods of communication. There are 2 types – I2C, and HDQ(SWI).
I2C
I2C is for bidirectional communication with the CPU (and potentially other devices on the I2C1 bus). The data is on SDA, which much like HDQ, is half-duplex. Communication can only happen in one direction at a time. Unlike HDQ, the timing of this communication comes from SCL, the clock signal which is generated from the CPU. This is important, because it means this communication can only happen when the CPU is actually active, and the device is on. That means a different set of behaviour can be expected, depending on the devices power on state.
HDQ/SWI
HDQ is for bidirectional communication with the Battery. You will notice that Tigris doesn’t handle this communication alone. BATTERY_SWI heads toward the battery, where AP_TO_TIGRIS_SWI, the CPU. As with the I2C communication, AP_TO_TIGRIS_SWI is not used when the CPU is not on, for obvious reasons. When the CPU is on, AP_TO_TIGRIS_SWI and BATTERY_SWI are connected together, and Tigris then performs its functions based on CPU communication, rather than battery data. While Tigris is directly monitoring battery data, it generally does so to make sure temperature is not too high or low.
VBUS_OVP_OFF
You will notice that TRISTAR_TO_PMU_OVP_SW_EN_L reappears here. This signal comes from Tristar as previously mentioned, and tells Tigris if everything checks out with lightning communication, handshake, and voltage. Tigris also performs its own tests on voltage, but the two IC’s are there to help each other.
ACT_DIODE
Depending on a variety of conditions, Q1403s gate is either HIGH (OFF) or LOW(ON) as driven by CHG_ACT_DIO. This is how Tigris recovers the battery from a fault state, by allowing the voltage it produces on PP_VCC_MAIN, to make it to PP_BATT_VCC. It’s common practice for board level technicians to “jump” the source and drain of Q1403, forcing VCC rails together, in diagnosis of charging/communication issues.
This should never occur, as the mosfet is designed to only be turned on in a specific condition (battery LOW, HDQ HIGH = FAULT). Unless the Battery is in a fault state, the mosfet plays no role in other functions.
BUCK_SW
CHG_LX provides a fast switching power to L1401, which results in the chargers actual voltage regulation (it varies, but we’ll call it 4.2V). The name of this type of circuit is a “buck converter”. Step down of the USB 5V supply occurs, so that the battery does not overcharge. The specific duty cycle and voltage supplied depends on the batteries current voltage, assuming the battery is detected. This allows the regulation of current at the same time, and enables safe charging for Lithium cells in 3 stages.
Precharge – When a cell is below a set threshold (say 3.0V) current is limited to 100mA. This prevents damage to the cell, when it is in a low state. Failure to limit current in this stage, can result in the battery swelling. Current measurement takes place with an internal current sense resistor.
CC/Constant Current – When the precharge threshold is passed, a constant current is used to charge the cell, depending on what is available on the USB 5V rail.
CV/Constant Voltage – After reaching the max charging voltage (say 4.2V), it remains at this level for the duration of the rest of the charge cycle, and the current draw declines.
This is the typical 3 stage process of charging a lithium cell
BAT_SNS
CHARGER_VBATT_SNS tests for the presence of battery voltage. If CHARGER_VBATT_SNS is LOW, ACT_DIODE will remain high, isolating PP_VCC_MAIN from PP_BATT_VCC. This is subject to certain conditions. For example if HDQ is HIGH, but BAT_SNS is low, Tigris can tell the Pack Side gas gauge is in a fault state. For a list of fault conditions, you can see the datasheet for a BQ27545.
Pre-boot Behaviour
Prior to boot, Tigris only performs limited hardware tests and functions, as software is not available yet. It expects HDQ to be high, and Battery voltage to be present, both at the same time (generally speaking).
In the case of an expected gas gauge fault condition (BATT LOW, HDQ HIGH), Tigris can momentarily turn Q1403 ON, or hold the HDQ line low, both of which will result in a recovery from this fault condition. However, it will only do so if USB power checks out, as determined by Tristar.
This is why a faulty Tristar may result in a device unable to charge a flat battery, where a good Tristar will result in the recovery of the fault condition. The reason a charged battery is still able to charge sometimes when Tristar is faulty, is that software takes precedence over the basic hardware function of Tigris. So if a device is able to boot, Tigris may behave differently, as it does what its told.
If you have experienced SWI/HDQ failure, you may now be wondering about the very common “charges until 1-2%, then stops during boot” symptom.
So if HDQ data is missing, why does the device charge prior to boot at all?
Lets take a look at how the iPhone X handles HDQ. Note that the iPhone X does not use HDQ to communicate with the gas gauge, instead opting for I2C.
You will see that in this application, the HDQ lines are LOW. When HDQ is LOW, Tigris performs its default hardware based functions, without worrying about gathering data from HDQ.
Given that the pull-up is within the battery, a device missing HDQ has a LOW line. Once the device boots however, charging cannot take place, due to the lack of battery data. This is due to software intervention.
So we now know that missing HDQ data (or I2C data on the iPhone 8>) results in lack of charging once the OS loads. In addition to this, you will notice a periodic reboot every X minutes (it varies per device/OS version). This reboot is due to missing temperature data, and generally only occurs on 3 pin battery terminals. This is due to the fact that 4 pin batteries also have a Negative Temperature Coefficient (NTC) thermistor, which takes precedence over HDQ/I2C recorded temp, on some iOS versions.
The HDQ circuit
Aside from Tigris, HDQ/SWI data has to make its way through a few parts depending on device. So finally, lets go through those parts, and the role they play.
SWI Filter
First, there is typically a resistor inline with HDQ/SWI, which is the first stop after the battery terminal. In many devices, this filter sits directly behind the battery terminal itself, and is commonly damaged by pry tools during battery disconnection. For other devices, the filter/resistor may be on the rear of the board, protected from pry tools. In the latter case, the filter pretty much never fails. If you have an iPhone 6>, it doesn’t hurt to check it if you have missing HDQ data, but there is almost no chance that’s where your issue is. Remember, replacing parts “just because” rather than actually testing them, is guessing, not diagnosis/repair.
6S Logic Level Shift Mosfet
Shift Converter
Instead of a filter, after the filter, or after the Tigris IC, you may find a MOSFET used for logic level shifting. This has been the case since the iPhone 6S, and is still the case for the iPhone X (although, the shift converters are now used on the I2C bus). Shift converters are used when 2 devices on the same bus use different voltages between their HIGH and LOW state. Having for example, a 3.3V I2C master, with a 1.8V slave, would result in damage to the slave when the voltage exceeds the maximum allowed voltage on the slave device. This also applies in reverse (1.8V Master > 3.3V Slave)
Level Shift Example
The shift converter in most devices is only shifting a ~2V HIGH, to a 1.8V HIGH. Previously 2V was considered acceptable, despite being outside of the recommended GPIO voltage. This is because it didn’t quite exceed maximum ratings. The use of a shift converter prevents high voltage from damaging the CPU’s GPIO. This is especially important if battery voltage should find its way to the HDQ line, resulting in up to 4.2V entering the 1.8V tolerant I/O. This could occur from misaligned connection, or some form of failure on the batteries PCB, or flex.
As with Q1403, it is ill advised to jump or bypass this mosfet. However, because it connects to PP1V8, corrosion here is common in the event of water damage.
General Purpose Input/Output (GPIO)
After passing through Tigris (or the Shift Converter), HDQ data reaches the dedicated HDQ GPIO. A GPIO is a programmable logic line used by software as a data input, output, or in the case of bidirectional communication, both. Damage to the GPIO is irreparable, and requires replacement of the part in which the GPIO is contained, usually the CPU. The GPIO used for HDQ data is not always part of the CPU though. Lets have a look at iPads.
iPads
So after looking at all of the above, what is different about iPads, vs iPhones? Well, not much, and lots. The Lightning port, Tristar, and Battery are still susceptible to failure as before. HDQ data is still read by a GPIO, and much of the behaviour remains the same. However, there are some key differences, like the lack of a Tigris IC. Lets take a look at the…
iPad Air
Yes, THAT one. PMIC failure is a known issue in iPad Airs, but there is little understanding as to why. Much to your surprise and disappointment, you, or a prior tech probably caused it. Lets have a look at some of the key differences, as see why that is.
The PMIC/PMU
U8100 iPad Air PMU/PMIC
As you can see, the function assigned to Tigris in iPhones, is part of the PMIC on an iPad Air. The circuits are incredibly similar, and the pins on the IC are even given the same names. One might even speculate TI is responsible for this ICs manufacture. All of the same applies for the circuits in and around Tigris, as with the PMIC. Failure of the charging circuit itself, as with Tigris, is fairly rare. This usually isn’t the source of failure of an iPad Air PMIC. So, what’s different?
U8100 HDQ/SWI GPIO
HDQ/SWI
Here’s the biggest difference. The GPIO for HDQ is not part of the CPU like it is in iPhones. In the iPad Air, it’s part of the PMIC. Now we know a damaged GPIO would result in no battery data.
We also know that no battery data would result in charging to 1-2%, then no charge after boot. Sound familiar?
iPad Air Battery TerminalSo how does the GPIO in an iPad Air PMIC get damaged? In order to damage a 1V8 tolerant GPIO, you would need to exceed its max rating. In most batteries, HDQ is right next to BATT+, so that shouldn’t be hard.
If you take a look at this battery pinout though, you will see in the iPad Air that’s not the case. The only pin close to HDQ, is THERM. The batteries NTC thermistor.
Speculation
The NTC thermistor works using an Analog to Digital Converter (ADC). An ADC measures the voltage on an input, and converts it to a digital signal. The power from this ADC, comes from the PMIC itself.
Voltage is applied to THERM via a common reference from the PMIC. The batteries NTC thermistor then creates a resistance to ground (about 10K at 25C), forming a voltage divider. This is how the batteries temperature is measured (although, its also measured via HDQ).
The voltage applied to NTC, is undocumented in the schematics. However looking at ADC’s in iPhones, the thermistors are applied 3.3V.
At the time this article was published, it is unconfirmed if the same voltage applies to the thermistors in the iPad Air. If this is true however, a simple misalignment would cause 3.3V to enter the 1.8V tolerant GPIO used for HDQ data. This would likely destroy the GPIO.
Replacement Batteries
What is confirmed, is that most replacement iPad Air batteries do not contain an original TI Gas Gauge IC. The specific voltage applied to HDQ, the frequency of the return data, and everything else about the “Gas Gauge IC”, is a rough guess at best.
If an after market battery is installed in a device, it also has the potential to damage the GPIO.
This is important to point out, because the process for diagnosing charging issues (iPad Air included), is usually something like this.
Try new modular parts (Battery)
Replace easiest motherboard part (Charging Port)
Try replacing next easiest motherboard part (Tristar)
Finally, the hardest motherboard part (PMIC)
Because of this normal order of operation, it’s very possible to turn a simple charging port issue, or Tristar failure, into a PMIC GPIO failure in step 1.
When a motherboard repair technician receives a device like this, outsourced from another repair shop, its safe to assume they tried a new battery, or possibly several first. If all it takes is misalignment or an after-market battery, to cause irreparable damage to the PMIC, you can see how this might occur.
On top of this, the original issue is generally rectified in the same process. Perhaps the original issue was the Tristar, but the GPIO is damaged during diagnosis. Now, the Tristar is replaced, but there’s a second issue resulting in the same symptoms.