Podczas uruchamiania, resetuje się w pętli. Na wyświetlaczu można to zauważyć jako pojawiające się po naciśnięciu guzika „power” logo Apple’a ale po kilkunastu sekundach znika i wszystko zaczyna się od początku. Wydaje się, że uruchomienie nie ma końca. Nazywamy to klasycznym bootloop’em ale na tym klasyka się kończy. Przy próbie odtworzenia w iTunes pojawia się w iPhone 7 error 4013.

W iPhone 7 error 4013 należy do grupy błędów ogólnych. W tłumaczeniu na „ludzki” znaczy dosłownie „nie można przywrócić urządzenia”

Tak też było w tym przypadku. Na podstawie rozmowy z użytkownikiem, dowiedziałem się że telefon mrugnął i przeszedł do trybu serwisowego. Dlaczego? Właściciel twierdzi, że telefon nie upadł, jednak ekran został wymieniony. Zapewne z powodu „mody” na wymianę ekranu w iPhone 😉 Znowu zaczynają się schody. Po drugiej rozmowie telefonicznej, okazało się że użytkownik to właściwie serwisant a telefon oddany do wymiany ekranu, po upadku i rozbiciu (działający) przestał się włączać jak tylko „serwisant” (vel. użytkownik) zamknął i zakręcił wymieniony ekran. Co za pech… (a na marginesie, po co ta ściema?)

Error 4013 może objawiać się na wielu poziomach. Począwszy od komunikacji do poważnej usterki sprzętowej, zwłaszcza po upadku. W pierwszej kolejności, rozłączam wszystkie akcesoria podłączone do płyty głównej i kontroluję prąd uruchomieniowy. Tak, należałoby zacząć od sprawdzenia komunikacji i pracy modułu radiowego ale wydaje mi się, że jeśli byłby to tak oczywisty przypadek (uszkodzony Lightning) poprzedni serwisant zauważyłby nieprawidłowość. Z tego powodu pomijam na tym etapie lub z powodu doświadczenia, przekładam raczej na koniec mojej listy kontrolnej.

Podłączony zasilacz serwisowy pokazuje faktyczne zużycie podczas uruchomienia. Lubię to sobie obrazować na wykresie czasu i obciążenia ale nie jest to konieczne by zrozumieć co się wewnątrz dzieje. Widać dokładnie, jak w okolicy 10 sekundy następuje zrzut prądu do zera, zapewne w wyniku przeciążenia lub wykonania nieprawidłowej procedury.

Tutaj, znowu rozwidlenie diagnostyczne. Widzę problem sprzętowy, bo trudno wyobrazić sobie, by w systemach zamkniętych, jak IOS spodziewać się błędu. To jest mniej niż nieprawdopodobne. Komunikacji nie używam, więc nie podlega badaniu na tym etapie, zresztą iTunes widzi telefon w trybie serwisowym i komunikuje się z nim więc zakładam, że działa prawidłowo.

Podobne problemy może przysparzać moduł radiowy, więc odłączenie go na czas weryfikacji wydaje się być dobrym pomysłem. Usuwam zasilanie ( układ PMB6826 ) basebandu, w przypadku błędu IOS pominie podukład (zaznaczy problem z uaktualnieniem ustawień operatora lub niemożność aktywacji słuchawki) ale przejdzie dalej. Jeśli się uruchomi, mam winnego i potwierdzenie właściwego kierunku diagnostycznego. Jeśli nie, pozostaje już tylko jeden: SOC – Power Supplies czyli (PP_GPU_VAR i PP_GPU_SRAM_VAR), (PP_CPU_VAR i PP_SOC_VAR). PS: pamiętaj o odpowiednich narzędziach i zabezpieczeniu ESD. Jeden błąd może kosztować całe urządzenie.

• 

• 

• 

SOC to określenie zintegrowanej platformy procesorowej (System On a Chip), w Apple do niedawna opartej na architekturze ARM. Czym jest sam ARM, przeczytaj sobie w sieci, (dostrzeżesz ocean nieprzebytej wiedzy), dla nas istotną informacją będzie to, że procesor ma zintegrowany rdzeń graficzny a pamięć operacja jest bondowana do górnej płaszczyzny procesora. Inaczej, łatwiej jest w iPadach, gdzie RAM jest przylutowany obok procesora (co ma znaczenie w kontekście re-worków).

Nie jesteśmy w stanie stwierdzić czy procesor działa prawidłowo bez dostępu do kompilatora (w takim przypadku, nawet w trybie serwisowym doszukiwałbym się problemów) ale jesteśmy w stanie sprawdzić model zasilania na podstawie odczytu potencjału elektrycznego z jego linii zasilania. Tak więc mamy do sprawdzenia prądowo i rezystancyjnie

(1)CORE:

• PP_SOC_VAR na poziomie 0.020 (niska rezystancja synapsów silikonowych) i napięcie wewnątrz-układowe do max. 0.60V,
• PP0V9_FIXED i odpowiednio 0.080 oraz 0.50V – do max.0.9V
• PP_CPU_VAR – 0.020 i 0.55V
• PP_GPU_VAR – 0.020, 0.60V dla stanów niskiej rozdzielczości
• PP_GPU_VAR – 0.92V dla wysokiej

(2)RAM:

• PP_GPU_SRAM_VAR – 0.420 i 0.35-0.90V
• PP1V1_SDRAM – 0.250 i 1.1V,
• PP1V8_SDRAM – 0.310 i 1.8V.

• 

• 

• 

Linia PP_GPU_SRAM_VAR jest zasilana urządzeniem typu „charge pump” czyli bierze tyle ile potrzebuje a zasilacz, w tym przypadku główny PMU (D2333A1) zachowuje się jak urządzenie SMPS w obwodach basebandu. Sprawdzenie multimetrem na jednej stronie pokazuje wartość 0.000, z drugiej 0.280 Jest to klasyczny objaw zespawania cewki zniszczonej mechanicznie. W grę więc wchodzi przełamanie rdzenia, zwarcie kondensatora w linii po jej lewej stronie lub zerwanie pada pod.

Jedynym sposobem naprawy jest wyjęcie cewki i sprawdzenie (jeśli się uda bez wyjmowania) kondensatorów podtrzymujących w linii. Cewka po podgrzaniu przełamała się na dwie części, chyba mogę założyć że była pęknięta. Wymiana cewki PIQA20121T 1UH 2.1A 0.12ohm pozwoliła na uruchomienie telefonu.

Płyta uruchamiała się w trybie niskiej rozdzielczości. Kiedy procesor próbował uruchomić obsługę interface użytkownika (w wysokiej rozdzielczości) nastąpiło zapotrzebowanie na moc, której uszkodzona cewka nie potrafiła wygenerować. Sygnał niskiej wartości doprowadzał do przeciążenia i zresetowania PMU. Nie dostrzegam innego rozwiązania problemu.

Przypominam sobie, jakiś czas temu, w polskiej sieci pojawił się film z jednej z pracowni naprawczych publikujących „live” z napraw telefonów. W tamtym przypadku chodziło o 6s. Technik oświetlił procesor w podczerwieni i na tej podstawie sformułował diagnozę o zwarciu w kości pamięci ram. Wydaje mi się, że był to jednak przypadek podoby a nadmierne zapotrzebowanie na moc zostało zaobserwowane jako wyższa amplituda temperaturowa (35 stopni na marginesie, 38 to normalna temperatura procesowa a ponad 60, to dopiero temperatura zwarciowa w półprzewodnikach). No nic… ciekawi mnie jednak tamta płyta, ciekawe czy poradziłbym sobie jak i z tą, tutaj.