September 18, 2020

September 17, 2020

Please reload

Recent Posts

NFC - 101

September 18, 2020

Please reload

Featured Posts

iTunes - 4014

March 16, 2020

Dear Reader,

I have added a DONATE button for this post if you appreciate my works. (AT THE END OF THE POST)
This will help contribute to future online content I have planned.

Its not compulsory and totally up to the reader.

I hope you enjoy this post as I believe there is nothing else out there relating to this information and I will be adding this type of stuff to my course and feel it is a skill that will help to stop the stressing out
and dissapointment these jobs can cause us, well some :)


i7 - Dead

This job started as just a trashed device who was unfortunate enough to have a wall run into it and then be used as a trampoline, then it came to me from another tech.

I started off with simple tests of TRISTAR using ICC PRO, Battery Check, USB current v DCPS Current.



There was no USB current at all 0.00

DCPS showed a 3amp short , I then removed the AUDIO IC and started again.


DCPS current showed no leakage and triggered at 170-190ma (7) 6s showed up as 230ma locked, with no heat.

While the device in under DCPS power I tested RAM supplies 1v1, 1v2, 1v8 SDRAM = PASSED (didnt test static ram at this stage)

I then tested the NAND voltages 1v8, 3v0,and 0v9 and all are ok

At this stage I can pre determine the NAND is at fault as TRISTAR is doing its job with handling USB comms so far.

We will see just how good ICC PRO is at confirming our good TRISTAR during this repair.

RAM supplies are good - usually if shorted it will kick into DFU right away as system voltages are bad. Shorts on these will lead to DFU.

NAND voltages are OK!

The current leads to NAND on the DCPS as over usb we know 80ma is our DFU connection (powering the device by the way), this is important to know!

Now if it was say 40, 50ma,70,80 ,90 - 0ma cycle loop then it will be a RAM issue.


No Battery shows as : 60ma, 30ma, 70ma, 120ma to 0ma and loops over USB

The 170-190 / 230ma or even up to 370ma sometimes means the system is prepairing to load and requiring the NAND access and hangs at that point.


Some current values can vary depending on loads, IC demands, partial shorts (drains) and so on.

This could be a totally bad NAND, UL Data corruption or any of the little resistors along the NAND perimeter.

The next thing I did was check the restore process to lock the fault and confirm further.

The device would not connect to pc comms by plugging in to usb in normal state.

I FORCED DFU and the device connected,the original battery was connected at this stage.

I flashed the device in 3utools EASY mode to get a visual of the restore AND transitions process :)


Sometimes I use all 3 modes for comparisons to lock a fault, as well as PANIC LOGS!!!!!!! If your lucky to get the access.


I also like to start in DFU as its the lowest access and then work up the Modes proving each stage.

The first flash gave me a Error 4014 , now during this part of the flash it connected in DFU mode and reached 11% and then went to transition mode of RECOVERY but failed, the reason for this was a bad VBAT voltage.


Transistion stages are DFU, RECOVERY, NORMAL.


When in DFU MODE and connected to a pc the device is powered up over USB comms and when it transistions over to RECOVERY it switches to normal operation and uses and expects BATTERY voltage to be available and if it cannot detect battery voltage then the device is dead according to the flash and comms.

When I say powered by USB, I mean the main power source for TIGRIS whether its Battery or 5V0_USB



It then spits out ERROR 4014 and its basically telling you its in DFU Mode and its Expects it to be in Recovery Mode but it cant be as the battery is either not connected properly,loose batt fpc etc and it can only use USB comms power in DFU as thats its only power source.

Please note: Short circuit on system power supplies can also cause this issue including RAM voltages.



 At this stage the NAND isn't used, its used when it reaches the RECOVERY mode switch.


So this is one instance of ERROR 4014 - "4014 VBAT"

I tested the battery which was fine but the FPC was loose under DCPS probing.

FPC replaced and this time it TRANSITIONS to RECOVERY and fails at 11% expecting Recovery again but still in DFU.


Now I always run a 3utools restore AND iTunes for the ERROR number to lock faults. this information is very

important in steering us towards the faults. this is how I ended up with a ERROR 4014 or 11% DFU RECOVERY ERROR in 3uTools.


I run iTunes within 3uTools for visual representation, I do not use a device screen and instead read the information in realtime during the restore..


It states the same information for the ERROR as 3uTools 11% in DFU but Expects RECOVERY.

As stated earlier there were no shorts found to keep it in DFU Mode so it can only be the NAND at this stage as the RECOVERY needs NAND and if not available the LLB and iBOOT wont be available so NAND access is needed or it defaults back to DFU, so we have a BAD NAND confirmed again with the 170-190ma (7) / 230ma (6s) current lock on the DCPS.

So this could be Bad NAND , BAD LLB or iBOOT File as all three have a route to recovery from the NAND PARTITION.

Nand Removed, pads were checked for readings, all were fine but the CLKREQ (OL) and not available so the resistor was replaced and back to normal.


Checked the NAND on the Programmer and it just hung there trying to read it but couldnt read it after multiple times.


The NAND cannot be accessed and is why its defaulting to DFU as there is no way for it to get to RECOVERY as the NAND is BAD and UNREADABLE as its trying to get access at this stage.

I decided the NAND was the issue and instead of waiting for the GSX info due to the NAND being toast and nothing there for transfer, I made the decision to test the rest of the device and put on a BLANK NAND unbound and run a RESTORE although it wont be able to activate I can still carry out tests to confirm Modem and other important info.




Check Information
SN: Query SN failed
Mode: Query mode failed
Region:  Query region failed
WIFI Address: Query wifi address failed
bluetooth: Query bluetooth failed
EMac: Query EMac failed
color: Query color failed
Model: Query Model failed
MLB#: Query MLB# failed
NvSn: Query NvSn failed
NSrN: Query NSrN failed
LCM#: Query LCM# failed
Batt: Query Batt failed
BCMS: Query BCMS failed
FCMS: Query FCMS failed

The RESTORE went smoothly and the device booted up and connected to 3utools as seen here.

As you can see there are missing portions of information due to me not programming the GSX DATA

The info I needed was obtained and when the GSX data arrived the NAND was removed and sys/config formatted followed by UNBIND and the 4 bits of DATA added from the GSX info. Thankyou Mr "C"

Nand installed and activated as seen here, GRRRRRR!


The rest is just functional tests before going back.

So this instance was a BAD NAND 4014 and a VBAT 4014.




I had a 6s with a BAD FPC that gave the same Error of Cannot switch DFU to Recovery and iTunes 4014



One of these 4014 errors can cause DFU MODE not being able to switch to Recovery Mode, this is the mode that will allow the restore and also the NORMAL transitional mode during writing of the flash data to the NAND.

The other 4014 error WILL be able to switch into RECOVERY and give the same error as the DFU 4014 so it matters what mode your in to determine the fault .



One defaults to DFU only as it cannot use secondary VBAT power to proceed and reboots into DFU again to start over. RAM and Shorted supplies to NAND can also cause this instance leaving only DFU as the option.


Ths is classed as Power Supply Fault. NOT NAND



One Defaults back to DFU while NOT able to switch to recovery due to no NAND access or bad LLB or iBOOT to proceed.

Can you see the path to RECOVERY ? It comes from the NAND sections LLB and iBoot



 This is classed as a NAND fault.

There is another which is TRISTAR that can cause 4014 and its DFU only as the UART/AP TX and RX lines are not working AP/CPU disconnect.


Also the Baseband Clock circuit for the PMIC can also cause 4014 and 4013 (RARE)


Logs will steer you towards USB MUX failing :) (incorrect)


So an easy test for this error is to probe VBAT with suitable voltage and run the restore again even if its to see if it gets into RECOVERY MODE.

If it does, your VBAT line needs looking at and if its fine then the 4014 Error will be a NAND detect error, either from failure, data corruption, missing voltage or shorted supply to NAND.

So we have Error 4014 caused by : in order of checks

1) TRISTAR - Cannot switch from DFU to Recovery - Caused by AP/CPU disconnect UART or Main Failure.

2) RAM - Cannot switch from DFU to Recovery - Caused by shorted RAM, Unstable voltage on RAM

3) SECONDARY POWER - VBAT - Cannot switch from DFU to Recovery - Caused by secondary power failure when DFU over USB is disconnected.

4) NAND - Cannot switch from DFU to Recovery - Cannot access NAND or DETECT NAND (no path to recovery) - Caused by Bad NAND, Dropped Pads for NAND Comms (ie) RESET, CLKREQ SYS_ALIVE

5) BASEBAND POWER SUPPLY INC CLK - 19.2M, S1-S5 (tested during restore)


If you can reach RECOVERY stage from DFU then your power supplies are healthy and it could be

NAND side of things now.


DFU ONLY = Power supplies, TRISTAR, NAND


RECOVERY = BAD NAND, Dropped Pads or Underlying Data CORRUPT , Inc PARTITONS


Summary: Why cant it change over to recovery or normal mode in restore?

The BootRom needs NAND access for LLB and iBOOT and both are on the NAND if they cannot be accessed then it will enter recovery out of DFU.

BootRom needs NAND access for LLB and iBOOT but NAND is corrupt and these cannot be accessed or the NAND and no path to RECOVERY.

Restore has Transistional stages that require both sources of power VBAT and 5V0_USB if DFU disconnects from pc and no battery power is available then reverts to DFU as will any shorts on power supplies NAND, RAM etc.

Same applies to NAND signals, RESET, CLKREQ, SYSTEM ALIVE will all render NAND undetected if faulty, short/open.


Always test the pads for power, reset, sys_alive and the RESREF as this can render the NAND inaccessible,

undetectable and so on....most of these errors are due to the resistors attached to the NAND CLKS and data lines.




Last thoughts....


As a precaution the NAND will not let access to it if the Battery is low and there is a chance the device could go into dead state during a write process to its pages.


This is a low state voltage signal and can be pulled down by mod if needed but its a low state 0.0/0.6v


No Battery voltage detected will put the NAND into this mode. Error 4014.


You MUST check SYS Alive for any shorts or low state it should be 1.8V, why? This line connects to other ICs that can be shorted that are knowhere near NAND and prevent NAND operation.


Open SWD data lines can also prevent NAND operation causing Error 4014.



Get a feel for voltages, I prefer to use voltage over diode mode as it presents us with realtime operations as it happens , outputs, resets as they happen, diode mode can give you a good reading but doesnt mean that the IC that sends that signal WILL actually send it over.


Current is important in this too, as we can have a 50/57ma DFU 4014 which means this hasnt got to the stage of needing NAND access yet and is still part of the boot process at 50ma meaning CPU power, Clocks and so on and in this case it will be the 19.2M Crystal for the BASEBAND PMIC, I reported this a few years back along with it being able to cause 4013 on iOS 12.




So now lets test my approach and thought process to some of my cases of 4014.

1) Apple Logo bootloop

No Recovery only DFU Mode available.

3uTools :

DFU over PC Connection = OK

DFU MODE - 11% ERROR - "Cannot swtich from DFU to Recovery"


This has not yet touched the NAND as there is no TRANSITION to Recovery.

It Kicks straight back into DFU MODE when it should have been switched over to RECOVERY 11% "Entering Recovery Mode"

This is a TRISTAR ISSUE and would have been picked up with ICC PRO test in the beginning set of tests.


Tristar has been replaced but still bootloops. :)


This time it CAN be put into a Recovery Mode Connection and downloads the drivers (displayed on screen)


This means it can reach the NAND at least but there could still be data corruption.

Lets move on .....



In Recovery Mode we connect to 3uTools and it shows up as in RECOVERY MODE in top left corner under connection.


We reach "Entering Recovery Mode" at 11% and it starts the FLASH this time....


RECOVERY MODE 11% - All data comms upto the 11% stage are DFU tasked and downloaded over the Net iBSS iBEC etc.

16% It sends the RAMDISK


18% It then sends the KERNEL CACHE

It should then disconnect to transition over to NORMAL MODE.


NOT CONNECTED 19% (transition)


Now it is in NORMAL MODE the RESTORE can take place.




20% It then sends over the NORData


20% Updates the NANDS S3E FIRMWARE

20% It will then check the filesystem

20% Then it sends over the FDRTrust Data

20% The filesystem is then UNMOUNTED


This now allows the NAND full Access to create the NAND PARTITIONS

20% Now it can Create the FILESYSTEM


20% - 60% is the FILESYSTEM write.

Once written to disk the FILESYSTEM is then checked

We are now at the 60% stage.

60% The KERNEL CACHE data is sent over

60% The KERNEL CACHE data is then installed

60% The DEVICE TREE is then sent over


80% Starts FLASHING the firmware

80% AOP data is sent


80% Sends over HOMER data


80% Sends over the RESTORE TRUST CACHE (creates secure net tunnel)


80% Sends ove the  STATIC TRUST CACHE

80% The BATTERY GAUGE data is updated
- Remember this one.


80% Now STOCKHOLM is being updated (NFC)




Its still  in NORMAL MODE, so NAND and the rest of our targets are out of the fault.

Look what was updated a few lines back.

BATTERY GAUGE data updated! This was the cause of the BOOTLOOP.  Poxy APPLE!

This will conflict with the original batttery data and the battery must be disconnected and reconnected to calibrate.

Restore again after the reconnection of battery and the GAUGE data will now match and the NAND "LOW BOOT" will not kick in again. This is sent by the PMIC

Once we get to the STOCKHOLM stage again it then follows on to:


80% sends over the FUD IMAGE TRUST data


80% It then sends over the BASEBAND DATA


80% updates the SEP FIRMWARE


80% It then finalises updating the NAND S3E Firmware UL DATA PARTITIONS

80% FIXES UP /VAR directory

80% Last of all it creates its SYTEM KEYBAG





I only REPLACED TRISTAR and fixed an on the fly error due to the BATTERY UPDATE. The original ERROR 4014 was TRISTAR. BOOM!

Again this would have been picked up in the first set of tests using ICC PRO.

1) 4014 caused by TRISTAR FAILURE

2) ERROR -1  caused by misconfigured BATTERY GAUGE data after updating during flash resulting in the NAND LOW BOOT Battery detection circuit to kick in and shut down NAND access.



DFU only 4014:

No Recovery only DFU Mode available.

3uTools :

DFU over PC Connection = OK

- "Cannot swtich from DFU to Recovery"

This has not yet touched the NAND as there is no TRANSITION to Recovery.

Kicks straight back into DFU MODE when it should have been switched over to RECOVERY 11% "Entering Recovery Mode"

Again as the NAND is not touched as of yet and it kicks right back into DFU Mode at 11% this will be a Voltage issue on the supplies. RAM NAND VBAT and so on.

In this case the SPKRAMP is the cause of this ERROR 4014 but not directly.

The SPKRAMP is shorted and attached to VBAT, this is pulling down VBAT voltage to below its normal threshold.


The NAND detects this and DOES WHAT THE UK DOES NOT IN A PANDEMIC and shuts up shop.

The SPKRAMP removed and VBAT is fine again .

Now restore again and at 11% it TRANSITIONS from DFU to RECOVERY and then in to NORMAL MODE


It then gets to 20% Sending NORData and reverts back to DFU MODE.

NAND voltages have been checked and HAVE passed on supplies, so this can be data / clocks not working on the NAND circuit. TRUST ME ITS NOT EEPROM!

Remove the NAND confirm its OK and read/backup/restore, copy data to another known good NAND. (just in case)!

This time round I only backed up the original nand BUT did not alter its data structure at all, the reason was to see if its an ULD or Board based fault..

Installed original REBALLED NAND. REBALLED ONLY !!!


This was Dropped Pads under NAND


This was NAND area of the fault.

So this was originally found out to be ERROR 4014 caused by shorted SPKRAMP attached to VBAT causing VBAT to be low and NAND LOW BOOT circuit kicked in and disconnected.

Cause: Shorted supply and dropped pads

The NORDATA error was fractured dropped pads on critical data lines for comms rendering the NAND DEAD or inaccessible.

This would have been picked up during NAND removal and a PADS test.


Last of all was a job that was stuck DFU Mode only and was a bridged 1v8-1v2 line under RAM causing 1.8v on a 1.2v line this kicked right in to DFU only and was at approx 390ma->1amp

So basically as long as you follow the sequence of tests you should lock the fault without removing too many components.


2) RAM



5) BASEBAND POWER SUPPLY INC CLK - 19.2M, S1-S5 (tested during restore)

These tests appear from outside to inside in a logical approach .



If you have enjoyed this post or gained knowledge from this post, I have added a donation BUTTON where you can donate if you appreciate my works, its not compulsory but will help with new things to come, everyone else is doing it so why not.




Hope this helps a few!   -


Regards Dee





The content in this posting is copyright DeeGee - and images are shown for the illustration purposes of teaching.





Share on Facebook
Share on Twitter
Please reload

Follow Us

I'm busy working on my blog posts. Watch this space!

Please reload

Search By Tags