IPhone 13 and 13 mini Panic Log and 3-Minute Reboot

🔒 This article is maintained by PhoneRepair.biz's automated research assistant and checked against public sources. Last reviewed: 2026-07-01. Spotted a mistake? Report an error on the talk page — or just edit the article. Suggestions from readers are reviewed before going live.

Recovery at a glance
Difficulty	Advanced (board-level diagnosis; micro-soldering may be required)
Risk to data	Low to user data; moderate to device if board rework is attempted
Time estimate	30 minutes (part swap) to 3–4 hours (board repair)
Storage type	Apple NVMe NAND (PCIe), hardware-encrypted (FBE) with Secure Enclave
Device state	Device powers on and boots to the lock screen, then kernel-panics and reboots roughly every 3 minutes
Key tools	iOS Analytics panic log access, precision screwdrivers, microscope, multimeter/diode-mode, known-good OEM parts, hot air/soldering (if needed)

The iPhone 13 and iPhone 13 mini (SoC: Apple A15 Bionic) exhibit a well-documented failure mode in which the device boots normally, remains usable for approximately three minutes, then kernel-panics and reboots — repeating indefinitely. On these models the trigger is almost always the system failing to receive expected thermal-sensor (and related SMC) data within a watchdog window. This article documents the panic tokens you will see on the iPhone 13/13 mini, the enforced sensors and components whose failure, absence, or post-repair mismatch produces the loop, and a safe diagnosis-and-repair workflow. It is a hardware-stability procedure, not a data-extraction or lock-bypass method.

Overview

Starting with the iPhone 13 generation, Apple's on-device thermal and power management enforces periodic "check-ins" from a distributed array of temperature/NTC sensors and a Sensor/Board-Support Chip (BSC) path monitored by the SMC. If a required sensor stops reporting — because its cable is damaged, the part is missing, a non-genuine/unpaired part was installed, or a data line on the logic board is open/shorted — the kernel treats the missing data as a safety fault and forces a reboot. Because the watchdog window is on the order of three minutes (roughly 180 seconds), the visible symptom is a device that reboots every ~3 minutes, unrelated to app usage, charging, or temperature.

Two closely related panic families appear on the iPhone 13/13 mini:

Userspace watchdog timeout / thermalmonitord — the classic "no successful check-ins from thermalmonitord" watchdog panic inherited from earlier models.
SMC PANIC — ASSERTION FAILED / SMC BSC failure — a newer assertion-style panic prominent on iPhone 13 and later, which typically carries a hexadecimal sensor array value pointing at the implicated subsystem.

Both are diagnosed the same way: read the panic string, identify the missing sensor or sensor-array code, then confirm by substituting known-good parts and, if needed, tracing the sensor data line on the board.

Applies to

Brand / models: Apple iPhone 13 and iPhone 13 mini. The 13 Pro / 13 Pro Max are electrically similar but use a different sensor set and different codes — do not assume the mappings here transfer to the Pro models.
SoC: Apple A15 Bionic.
Storage: Apple NVMe NAND over PCIe.
OS & encryption: iOS 15 through current iOS releases. Data is protected by File-Based Encryption (FBE) with keys bound to the Secure Enclave (SEP). This procedure does not touch, weaken, or bypass that encryption.
Required device state: The device powers on and boots far enough to reach the lock screen before rebooting. If it never boots, this article's watchdog/SMC diagnosis does not apply — investigate a different fault (short, PMU/Tristar, NAND, SEP) instead.

Risk to data

This is fundamentally a hardware repair problem. Reading the panic log and swapping OEM sub-assemblies (battery, charge-port flex, front sensor/proximity cable) carries low risk to user data.
No point of no return exists at the software/encryption level for this procedure. Nothing here erases or re-keys user data, and none of these steps require restore/DFU. If someone advises a "Restore" to "fix" a reboot loop, understand that an iOS restore/erase is an irreversible data-loss event — avoid it until you have exhausted hardware diagnosis, and never do it on a device you are recovering data from.
Board-level rework is the real risk. Hot air near the connectors, pads, or NTC circuitry can lift pads, damage adjacent components, or (worst case) damage the NAND or SEP path. Damage to the NAND/SEP region can render user data permanently unrecoverable, because the encryption keys are bound to that specific hardware. Treat any soldering step as high-risk and reversible only by skill, not by undo.
If the goal is data recovery rather than repair: you often do not need to fully fix the loop. A device that boots for ~3 minutes at a time can frequently be backed up incrementally between reboots (see Verifying the result). Prioritize a backup before attempting board rework.

Tools and materials required

Access to Settings → Privacy & Security → Analytics & Improvements → Analytics Data (to read on-device panic logs), or a Mac/PC with a sysdiagnose/analytics export tool.
Precision screwdrivers, spudgers, and display/opening tooling for iPhone 13/13 mini.
Known-good OEM parts for substitution testing: battery, charge-port (Lightning) flex, front sensor/proximity flex. Genuine or original-pull parts are strongly preferred because of pairing/enforcement (see below).
Microscope (for connector and pad inspection).
Multimeter with diode-mode for continuity/short testing of sensor data lines.
Only if board repair is confirmed: hot-air station, soldering iron, flux, low-temp solder, and a boardview/schematic for the exact model.
Optional: a panic-log analyzer utility (community tools exist) to help parse the sensor-array value.

Prerequisites and safety

Confirm the ~3-minute cadence. Time the reboots. A consistent ~180-second cycle strongly supports the sensor-watchdog/SMC family. Random or usage-triggered reboots point elsewhere.
Rule out software first. A clean iOS update (without erase) or checking whether the loop occurs in Safe/recovery contexts can distinguish a pure-software watchdog (often springboard, logd, wifid, or a bare thermalmonitord timeout with no missing-sensor token) from a hardware sensor fault. Do not erase.
Establish consent and ownership before opening the device (see Legal and consent note).
Back up first if possible. Even a partial iCloud/Finder backup captured between reboots protects the customer's data before you introduce board-rework risk.
Observe ESD precautions and disconnect the battery before any connector work.

Step-by-step procedure

Capture the panic log. On the device: Settings → Privacy & Security → Analytics & Improvements → Analytics Data. Scroll to the most recent file named panic-full-YYYY-MM-DD-HHMMSS.ips. Open it (or share/export it to a computer for readability).
Read the panicString. Near the top of the .ips JSON/text you will find the panicString field. On the iPhone 13/13 mini the relevant patterns are:
- userspace watchdog timeout: no successful checkins from thermalmonitord — thermal watchdog; look for an accompanying Missing sensor(s): line.
- SMC PANIC - ASSERT: ... together with SMC BSC failure and a sensor array hex value — the iPhone 13+ assertion-style panic.
Extract the sensor token or sensor-array code. You are looking for one of:
- A named Missing sensor(s) token such as Prs0 (barometer/pressure), Mic1, TG0V / TB0V / TG0B (battery gas-gauge/thermal), etc.
- A hexadecimal sensor array value (e.g. 0x800, 0x1000, 0x4000, or a combined value like 0x1800). Combined values are bitwise/hex sums of individual sensor bits, so more than one component can be implicated at once.
Map the code to a subsystem — but verify, do not trust blindly. Field references for the iPhone 13 family commonly cite mappings such as those below. These tables are not fully consistent across sources or across iOS versions, so treat them as a starting hypothesis and confirm by substitution, not as ground truth:
{| class="wikitable"

|- ! Reported token / sensor-array bit !! Commonly-cited implicated component (iPhone 13 / 13 mini) !! Confidence |- | Prs0 (barometer) || Charge-port / Lightning flex assembly || High (well-established token) |- | TG0V, TB0V, TG0B, "Gas Gauge" || Battery / battery flex (fuel-gauge & thermal) || High |- | Mic1 || Bottom-left mic path (charge-port flex region) || Medium |- | 0x800 || Charge-port flex || Medium — verify against service data |- | 0x1000 || Front sensor / proximity flex (display side) || Medium — verify |- | 0x4000 (some sources 0x40000) || Battery || Low–Medium — sources disagree on the exact bit |- | 0x10000 (per some sources) || Front sensor assembly || Low–Medium — sources disagree |- | 0x400 || Reported as a "sandwich board" issue on the mini specifically || Low — verify against boardview |}

Because published bit values conflict (e.g. battery cited as both 0x4000 and 0x40000), do not order a rework based on the hex code alone. Cross-reference the code against a current boardview/service document for the exact model and iOS version, and prefer the named sensor tokens (Prs0/TG0V/etc.), which are more stable than the array bits.
Substitute known-good parts (least-invasive first). In order of likelihood for this loop:
1. Known-good battery / battery flex (gas-gauge and battery NTC are frequent culprits).
2. Known-good charge-port (Lightning) flex (carries the barometer/Prs0 and bottom-mic paths).
3. Known-good front sensor / proximity flex (display-side sensor path).
Reassemble and re-time. If the loop stops, the swapped part (or its connector) was the fault.
Inspect connectors under the microscope. Look for widened/splayed FPC pins, tombstoned components, liquid residue, or corrosion on the sensor connectors and their board-side pads. Reseat and clean before concluding a part is bad.
Diode-mode the sensor data lines. With the battery disconnected, check the implicated sensor line(s) for a dead-short to ground or an open. A normal NTC/sensor line reads a characteristic non-zero diode value; 0.000 (short) or OL (open) points at board damage.
Board-level repair (only if a data line is confirmed faulty). Typical faults are damaged NTC/sensor filter components, a broken trace, or a failed sensor-relay chip in the SMC/BSC path. Repair per the boardview: replace the specific passive/IC, or repair the trace. Do this only with schematics and appropriate skill — see Risk to data.
Re-test after each change — do not stack multiple changes before re-timing the reboot cycle, or you will not know which fixed it.

Test-point/pinout note: Exact test points, filter designators, and connector pinouts vary by model and board revision on the iPhone 13 vs 13 mini and are not reproduced here to avoid error. Verify every coordinate against a boardview/service schematic for your specific unit before probing or reworking.

Required / enforced sensors & components (iPhone 13 / 13 mini)

Components whose failure, absence, or post-repair mismatch is known to affect this model. Note carefully which ones cause the reboot loop versus which only cause a feature loss or warning:

Battery — thermal + gas-gauge sensors. Failure/absence → can trigger the reboot loop. Also: a non-genuine or unpaired battery raises an "Unknown Part"/service warning and hides Battery Health, but that warning alone does not cause the 3-minute loop.
Charge-port / Lightning flex — carries barometer (Prs0) and bottom-mic sensor paths. Failure/damage → can trigger the loop.
Front sensor / proximity flex (display-side) — proximity/ambient path. Failure → can trigger the loop; also affects auto-brightness/proximity behavior.
Front camera / TrueDepth (Face ID) module — serialized/paired to the logic board. Swapping it breaks Face ID (does not by itself cause the reboot loop). Face ID hardware cannot be transplanted between devices to restore function.
Display assembly — on early iOS 15, an iPhone 13 screen swap disabled Face ID due to a small paired microcontroller on the flex; Apple later relaxed this via a software update, but True Tone and auto-brightness still require pairing/transfer of the original panel data. This is a feature/enforcement issue, not the reboot loop.
Rear back-glass / wireless-charge coil assembly (where applicable) — some sub-assemblies carry a calibrated sensor; using a non-Apple part without System Configuration can produce warnings and, in some cases, sensor faults. Verify per case; do not assume it drives the 3-minute loop.
Logic-board NTC / SMC-BSC sensor path — the on-board thermal circuitry and Sensor/Board-Support Chip path. Physical damage here → can trigger the loop and may require board repair.

Uncertainty flag: the precise list of "enforced" vs "advisory" parts shifts with iOS versions and with Apple's parts/pairing policy. Confirm current behavior for the installed iOS version before promising a customer a specific outcome.

Verifying the result

Primary check: After the repair, let the device run for well past the ~3-minute window (target 15–30+ minutes of uptime through lock/unlock and light use). Stable uptime through several would-be reboot windows is the pass criterion.
Log check: Trigger nothing; simply re-open Analytics Data after some uptime and confirm no new panic-full-* entries are being generated.
Feature check: Confirm the previously implicated function works (e.g. barometer via a compass/altitude app, proximity by covering the sensor during a call, battery health readout).
Data-recovery variant: If you are extracting data from a device you could not fully stabilize, use the ~3-minute windows to run a Finder/iTunes or iCloud backup incrementally; encrypted local backups will capture the most data. Confirm the backup restores/opens before declaring success.

Success rate and limitations

When the panic string names a specific missing sensor and a known-good OEM part swap clears it, success rates are high and the repair is straightforward.
When the fault is on-board (damaged NTC circuitry, broken trace, failed sensor-relay/BSC chip), success depends on board-repair skill and schematic availability; outcomes are mixed and rework carries real risk.
What this does NOT recover or bypass:
- User data encryption is untouched. FBE keys remain bound to the SEP. Fixing the reboot loop does not decrypt anything; it merely lets a device that already has the correct keys boot stably.
- Activation Lock / FRP is unaffected. A stabilized device still requires the owner's Apple ID/passcode. This procedure is not, and must not be used as, an anti-theft bypass.
- Face ID cannot be restored by swapping the TrueDepth module — it is paired and non-transferable.
- If board damage extends into the NAND or SEP region, user data may be permanently unrecoverable, because the keys cannot be reconstructed off-device.

Common pitfalls and troubleshooting

Trusting the hex code over the named token. Sources disagree on exact sensor-array bit values for the iPhone 13. Prefer the named tokens (Prs0, TG0V…) and confirm by substitution.
Assuming Pro mappings apply. iPhone 13 Pro/Pro Max use a different sensor set and codes; don't cross-apply.
Bare thermalmonitord timeout with no missing-sensor line. This often correlates to a software issue or genuine thermal event rather than a dead sensor — investigate iOS state before opening the device.
Non-genuine part warnings mistaken for the cause. An "Unknown Part" battery/display warning is a pairing message; by itself it does not create the 3-minute loop. Don't chase the warning if the panic points at a different sensor.
Stacking changes. Swapping battery + charge port + front sensor at once, then testing, tells you nothing about the actual culprit. Change one thing, re-time, repeat.
Erasing/restoring "to fix a reboot." This destroys user data and rarely fixes a hardware sensor fault. Never restore a device you are recovering data from.
Combined codes (e.g. 0x1800). These indicate two or more implicated sensors summed together; decompose the value and check each component.

Legal and consent note

Only perform this work on devices you own or are explicitly authorized to service, with documented owner consent. This procedure is a hardware-stability repair; it does not defeat Activation Lock, Apple ID, passcode, or Find My, and it must not be represented or used as an anti-theft or ownership-bypass technique. If a device shows Activation Lock and the presenter cannot demonstrate ownership, stop and follow your jurisdiction's and shop's chain-of-custody and lawful-recovery requirements. Handle any recovered user data in accordance with applicable privacy law and the owner's instructions.

Sources

PhoneRepair.biz is a free community knowledge base. Data recovery and board-level repair carry a real risk of permanent data loss — when the data matters, back up any raw dump before modifying a device and consider a professional lab. Only work on devices you own or have documented authorization to service. See PhoneRepair:Legal notice.