MIB head unit stuck in emergency mode after a failed update
Applies to: MHI2 / MHI2Q (Harman); MST2 (Technisat and Delphi, PQ and ZR); MIB2 Standard / Composition Media / Discover Media; MIB3; MHS2; MH2P / PCM5 (Porsche); MOI3
A firmware update that is interrupted, fed from a bad SD card or built from the wrong or modified package can leave a MIB head unit in emergency mode. The unit either stays there or returns to it after every reboot. In most reported cases it can be recovered from an SD card with a clean, matching firmware package. When that fails, recovery moves to serial (UART) or network access, and some units turn out to have a failing eMMC. This article collects what owners report about recognising the problem, the likely causes, the recovery order and the steps that did not help.
How to recognise it
The unit no longer reaches the normal home screen after an update attempt. Instead it shows an emergency screen, a red or blue error screen, or the logo only. Some units reach the normal screen and then drop back into emergency update after a few minutes.
Screens and messages owners report include the following.
- Blue 'Emergency Update Assist' screen with 'Scan metainfo' that never progresses (MHI2).
- Red Emergency Flash Utility screen, sometimes with 'No bootable image specified in update info (101)'.
- 'Actual file size differs from tag in metainfo' or an SD hash mismatch, repeated in a loop.
- 'No suitable update found, will reset now' on Technisat MST2 units.
- An 'EMERGENCY UPDATE' media prompt that resets after a few minutes, or a reboot every few seconds.
- An emergency update that starts, then stops at the same stage (for example around 2% or 50%, or during the last steps) and restarts.
- MMC error 00018000, or a read error or red error during the SD download.
- A black screen or logo-only boot after an emergency update that appeared to finish.
Likely causes
The notes point to a small set of recurring causes. Several can apply at the same time.
- Bad update media. The most common causes are cheap or worn SD cards, micro SD cards in an adapter, exFAT formatting and corrupted downloads.
- Incomplete firmware package, such as missing folders. One MST2 package had an empty touch folder.
- Wrong firmware for the hardware. Examples include a different region or variant, a navigation image on a 'plus' unit or the reverse, or a 04xx train on a 03xx Technisat unit.
- Modified packages. Patched SWDL or metainfo files, or patch files dropped straight into the firmware directory, can cause checksum and meta errors in emergency mode.
- IOC/RCC mismatch after a partial update, often after region conversions or aftermarket all-in-one (AIO) packages.
- Power loss during the update, which leaves corrupted partitions.
- Hardware. On units where every correct package fails at the same point, a failing or write-locked eMMC is suspected.
Before you start
Recovery means reflashing firmware, and on some units also working over a serial console. Prepare before attempting it.
- Note the current software train and the unit's part number. Take them from the label, the box, the SWDL log or /tmp/version.txt if the unit still boots far enough.
- If any diagnostic or console access still works, back up coding and adaptations, and an eMMC image if possible.
- Keep the supply voltage stable for the whole process. Use a battery charger or support unit in the car, or a lab power supply on the bench.
- Do not change several things at once. Change one variable, then retry.
Recovery from SD card
Start with this route. Owner confirmations for successful recoveries mostly come from it.
- Use a good-quality, full-size SD card of 32 GB or less, formatted as FAT32 rather than exFAT. Check that the write-protect switch is off. Avoid micro SD cards in adapters.
- Download the firmware again from a reliable source and extract it. Confirm that every folder is present and not empty. Corrupted or incomplete files were behind hash mismatch and file size errors, including a confirmed case on MHS2_US_AU_P2037 MU0185.
- Put the package in the root of the card, not in a subfolder. On MHI2, emergency flash mode is reported not to scan subdirectories.
- Use an unmodified package with its original metainfo2.txt. Owners disagree on whether emergency mode tolerates a previously patched SWDL. Some report meta errors whenever the SWDL was touched.
- Insert the card before entering emergency mode or powering the unit up. A confirmed report notes the emergency screen appeared briefly and vanished until the card was already in place.
- Let the unit pick up the update. If it stalls, try Retry, or Skip all where offered. Some owners also disconnect the battery or pull the fuse for about 30 seconds and then power up with the card inserted.
- Once the unit boots normally, run a normal software update to bring all modules up to date. Apply any patched or customised update only after a clean update has succeeded.
Choosing the right firmware
Emergency mode is picky about variant. On many units the unit is more particular about variant than about exact version. The reports below vary by platform, and some disagree.
- MIB3: a confirmed recovery (part number 3G0919605D) needed the same software version as the one installed, placed in slot 1. A normal update to the newest version followed afterwards.
- Technisat MST2: owners report that any train from the same series (for example 03xx) usually works. A navigation unit (two SD slots, 8 GB eMMC) needs navigation firmware, and a 'plus' unit has a 4 GB eMMC. MST2_EU_VW_ZR_P0140T recovered a unit that asked for MST2_EU_VW_ZR_P0138T. In another case, however, 0140T was reported as wrong for a navigation unit and 0138T was recommended. Some units appear to accept only the version printed on the box.
- Technisat MST2: where MST2_EU_VW_PQ_P0478T could not be found, MST2_EU_VW_PQ_P0480T was suggested instead. A version close to and above the original, rather than the latest, was also suggested in one case.
- Delphi MST2: choose firmware by its MU number and board variant rather than the xxxxD train name alone.
- MHI2: one owner was told to use a fresh copy of the original MHI2_ER_AU57x_K3663 rather than the K3663_1 AIO variant. Another was advised to use MHI2_ER_AU57x_K3663_1_MU1425_AIO directly from a FAT32 card. Neither approach has broad confirmation.
Recovery over UART, telnet or D-Link
If the unit ignores the SD card or loops at the same step, owners move to console access. These procedures differ by manufacturer. They usually need the unit out of the car, and for MHI2 often opened. They carry more risk, so follow a procedure written for your exact hardware.
- Technisat MST2/MIB2: connect a USB-TTL adapter to the RX/TX pins on the quadlock, crossed over, and open a serial session in PuTTY at 115200 baud. Short the two J5 test pads to reach the emergency menu, then select emergency update (reported as 2, or 2 then 1). Keep the SD card with the correct firmware inserted before removing the bridge.
- If the emergency update stalls on the download screen, resetting the emergency download counter over UART and retrying is reported to help, with one confirmation. Choosing 'continue boot' did not help.
- MHI2 (Harman): recovery goes through the RCC/MMX UART, the emergency flash utility and the emergency IFS. Flashing images to the wrong address or offset made units worse.
- IOC/RCC mismatch: a confirmed recovery updated the IOC over a D-Link USB network adapter, then restored through emergency mode and ran an SWDL update. One owner reports the emergency IFS procedure hung on MHI2Q until the IOC was updated.
- Porsche PCM: owners suggest trying D-Link recovery before any UART work.
When the eMMC is the problem
Suspect the eMMC if correct, freshly prepared packages on known-good cards fail at the same stage every time. Other signs are serial logs showing eMMC flush or read errors, a 'no valid container' result, or a write-lock message after an eMMC swap. Suggested remedies are advanced. They include checking or reformatting the QNX partitions, repartitioning, and replacing the eMMC chip. None was confirmed in the notes.
What did not help
The following were reported as unsuccessful, or carry an explicit warning.
- Waiting with the car switched off, or repeated reboots alone.
- Editing metainfo2.txt to skip checksum, variant and region checks. In the reported case the unit then failed to see the update.
- Using a different but equally unsuitable firmware: a newer version where the unit wanted the boxed version, or a neighbouring version on a unit with a suspected eMMC fault.
- Swapping SD cards once the unit consistently failed at the same step.
- Flashing RCC or IFS images at a wrong address, or copying partial files.
- Holding E to force emergency mode on an MH2P unit.
- Starting a region conversion through the green menu region change. This was suspected of causing a unit to return to emergency update every few minutes.
Frequently asked questions
- Will any firmware on the SD card get the unit out of emergency mode?
- No. The package must match the hardware variant, and on some units the installed version as well. Wrong-variant images produce errors such as 'No suitable update found'.
- Can I use a micro SD card in an adapter?
- Owners repeatedly link adapters and cheap cards to failed recoveries. Use a good-quality, full-size FAT32 card of 32 GB or less.
- Should the firmware be in a folder on the card?
- Put it in the root. On MHI2, emergency mode is reported not to look in subfolders.
- The update fails at the same point every time. What next?
- First rule out the media and package by re-downloading the firmware and using another card. If it still fails at the same point, move to UART or D-Link recovery. If that also fails, suspect the eMMC.
- Can I install my patched firmware straight away after recovery?
- Owners advise completing a clean, unmodified update first. Apply a patched update only after that succeeds.