We received an iPhone 6S for Data Recovery without any clear known history.
 

Initial Assessment

We always try the basics first. New screen assembly, battery, dock, an isolation test. The device does not appear to boot or have any obvious signs of life. During our initial assessment of the board, we found the Audio Codec IC U3500 was shattered (Sorry, we forgot to take a photo before removal).
We removed U3500, to find a large amount of pads fractured. It was pretty clear this device had sustained some shock, resulting in this damage.
 

 
Once removing the shattered, shorted IC were able to confirm the device booted in Normal Mode. Unfortunately we had no image at all. No Backlight, No Display.
 
 

Diagnosing No Image/No Display on LCD

The chain of events and conditions that result in display in most iPhones goes something like this:

• The PMU/PMIC, Agatha, generates PP1V8.
• PP1V8 becomes PP1V8_LCM via a filter/fuse(FL4205).
• When a screen is connected, PP1V8_LCM pulls LCM_TO_CHESTNUT_PWR_EN HIGH.
  This enables Chestnut (U4000 – Display PMU), and tells the CPU an LCD is connected.
  The CPU then tells the Backlight Driver, Muon (U4020) to turn on.
• With Chestnut turned on, some important voltages are generated. First PP6V0_LCM_BOOST, which is the basis for all other voltages.PP5V7_LCM_AVDDH, required by the LCD, and PN5V7_LCM_MESON_AVDDN, PP5V7_MESON_AVDDH, PP5V1_TOUCH_VDDH, required by the Touch/Digitiser overlay.
• With all of these conditions met, The CPU starts outputting data to the LCD. This occurs on the MIPI_AP_TO_LCM* lines
• As an LCD refresh is required, AP_TO_LCM_RESET_CONN_L is pulsed LOW, to instruct the LCD to prepare for a new set of data

Proceeding with the Recovery

With the above in mind, we know we need LCM_TO_CHESTNUT_PWR_EN for both LCD and Backlight, of which we have neither. If chestnut is shorted internally, it can also cause LCM_TO_CHESTNUT_PWR_EN to be stuck LOW, resulting in no backlight. So we check our PP1V8_LCM filter, FL4205. We know we have PP1V8 already, because the device is definitely booting, and connecting to the computer, and PP1V8 is required throughout the board for vital functions.

Everything’s fine there. PP1V8_LCM checks out, and we have tried multiple LCD’s during our initial assessment, so we know the display must be passing PP1V8_LCM to LCM_TO_CHESTNUT_PWR_EN. Our attention is turned to the Chestnut Display PMU (U4000). U4000 is in close proximity to the Audio Codec IC we removed earlier, so it wasn’t unlikely it sustained shock too. In fact, it was fairly unlikely it had not.

Removing Chestnut, and testing the pads under it for connection, proved that everything was as normal. So, we place a new Chestnut Display PMU, and test again.

Still no image or backlight. We may or may not be any closer to data. More investigation is needed.
We know Chestnut Display PMU, and Muon, The Backlight Driver, share the same I2C bus, I2C0. Generally speaking, an issue on this bus would result in no boot, however, we decide removing one of the variables on that bus wont hurt.

For data recovery, we don’t actually need backlight at all. We need Display, Touch, and a connection to computer. We can provide our own backlight to see what’s going on with the screen. So, off with the Backlight Driver..
 

 
Sure enough, there was a fractured pad underneath it as well. It’s only a cathode line, but its probable the IC is fractured as well.
 
 

So, did we get image?

Nope. Still no image. At this point we were feeling a little crazy. What have we missed? Are we 100% sure chestnut is providing the required power to the display?

We decided we should probably check this, by tricking the device into thinking there was a display connected. Its difficult to probe the LCD connector, with an LCD connected after all.

So, we ran a temporary wire from PP1V8_LCM to LCM_TO_CHESTNUT_PWR_EN, and powered up the device. EVERYTHING is there. Chestnut is working perfectly, but no display. What gives?

We finally turned our attention to the LCD data lines. These connect via some data chokes next to the LCD FPC connector.

Yep, that’s the issue. All 6 lines are unconnected. Looking at the board view, we can see they all connect to the same place, in the upper left corner of the CPU, right near that fractured Backlight Driver. Much to our displeasure, the device has a fractured CPU.
 

 
 

Uh-oh.. Now what?

Well, we never aimed to repair this device, because our end game is retrieving the customers data. So anything we could do to temporarily gain access would be okay. We could have guessed at this point what we were pressing on the display, but that rarely goes to plan, and could result in a disabled device. So, we thought we would put pressure on the CPU to see if we could get our data lines back. It took a lot of pressure, and eventually, we decided to clamp the corner of the CPU and rig the board up in an unconventional manner:

So with our CPU clamped, a battery and dock flex connected, a test screen with the backlight reflector removed, and another device providing backlight, we prompt to boot. Fingers crossed!
 
 

The result?

WE HAVE DATA!!

Excuse our excitement. But we love happy endings 🙂

Summary of Repair

In conclusion, a short summary of the steps we needed to take in order to get data from the device are:

• Remove Audio Codec IC (U3500), causing no boot.
• Replace Chestnut Display PMU (U4000) – (We may not have needed to do this, but we likely would have found ourselves doing so if we didn’t)
• Remove Backlight Driver IC (U4020), potentially causing an issue on the I2C0 bus, shared by U4000.
• Clamp the CPU to temporarily reconnect LCD data lines.
• Trust the computer using a test screen, and backup the data.
• Export the data to a usable format for the customer.