Resolving IOT2050 Boot Failure After Industrial OS eMMC Install

Problem Overview

The SIMATIC IOT2050 Advanced can enter a non-bootable state after a service-stick image has been used to install the SIMATIC Industrial OS onto the internal eMMC storage. Once the eMMC has been re-flashed with the Industrial OS, subsequent attempts to re-boot the device from the original service stick USB drive may fail even though the same image on the same USB media previously booted successfully. The fault is reported by a red STAT LED on the front bezel displaying a "no boot image found" pattern, while a microSD card containing the IOT2050 Example Image continues to boot without issue. This distinction is critical: it confirms that the IOT2050 hardware, the bootloader, and the eMMC subsystem are functional, and isolates the fault to the USB boot path.

This document captures the root-cause analysis and recovery procedure developed from a field case in which the SIMATIC IOT2050 Advanced was flashed with the service stick image service-stick-image-industrial-os-iot2050-IPC-2.1_S0061.img using balenaEtcher to an 8 GB USB stick. After the Industrial OS was successfully installed to eMMC and the system was rebooted, the service stick no longer booted. The fault persisted across multiple re-flash attempts on the same USB media and only cleared when a fresh, previously unused USB drive was used.

Affected Hardware and Image

The fault was reproduced on a SIMATIC IOT2050 Advanced (MLFB 6ES7647-0BA00-0YA2) running service stick image revision service-stick-image-industrial-os-iot2050-IPC-2.1_S0061.img. The Advanced variant provides 32 GB of internal eMMC storage, an Intel Apollo Lake SoC, two GbE interfaces, and four USB 2.0 ports routed through internal EHCI controllers. The Basic variant (6ES7647-0AA00-0YA2) ships with 16 GB eMMC and the same Apollo Lake silicon but a reduced feature set.

The SIMATIC IOT2050 supports two distinct boot artifacts that engineers frequently confuse:

• Example Image – A ready-to-run Debian-based image that boots from microSD or USB and is used to demonstrate IOT2050 functionality, prototype applications, and recover from a corrupted eMMC.
• Service Stick Image – A provisioning image that includes the mel-setup configuration environment used to install, customize, and deploy the SIMATIC Industrial OS onto eMMC during commissioning.

Both image families share the same U-Boot environment but differ in partition geometry. The service stick image is a hybrid ISO/IMG containing a small EFI System Partition (ESP), a Linux /boot partition with the IOT2050 kernel and initramfs, and a mel-setup partition containing the installer tooling. The Example Image has the same ESP and /boot partitions but replaces the mel-setup partition with a populated root filesystem.

STAT LED and Boot State Reference

The IOT2050 front bezel carries a multi-color STAT LED that reflects the boot state. Field observation confirms the following patterns:

When the STAT LED is solid red and the device still enumerates USB host controllers in the OS (or reports the expected count from U-Boot), the bootloader is alive but cannot find a valid partition table or boot file on the chosen media.

USB Enumeration Indicator

The IOT2050 firmware exposes four USB host controllers internally. With no external USB device attached, three controllers appear in lsusb output; with a USB stick inserted, four controllers appear. This 3↔4 enumeration delta is a useful field indicator that the USB sub-system is alive even when the STAT LED reports "no boot image found." It does not, however, validate the integrity of the media itself. An IOT2050 reporting 3 USB controllers with a USB stick physically inserted indicates that the stick is electrically invisible to the hub and should be reseated or replaced.

Root Cause Analysis

Two distinct failure modes were investigated during this case.

Service Stick Partition Layout vs eMMC Layout

The service stick image is laid out for USB boot. The image's first-stage bootloader looks for an EFI/BOOT/bootx64.efi file at a specific LBA offset. After the eMMC is re-partitioned by mel-setup, the original boot order written by U-Boot may still try the service stick's signature and silently drop to the next boot source if the USB media has been re-inserted with a different partition signature. In the field case, the eMMC install completed cleanly and the installed Industrial OS booted correctly the first time; the fault only appeared on a subsequent re-insert of the service stick.

USB Media Capacity Drift After Re-Flash

The decisive root cause observed in this case was wear-induced capacity drift on a re-flashed USB 2.0 stick. After the first successful flash with balenaEtcher and the first OS install to eMMC, the USB stick was re-imaged using the same .img file. balenaEtcher reported "flash successful" and the verification step passed, but a subsequent compare in Windows Disk Manager showed that the first partition had been shrunk by approximately 32 MB compared to a freshly imaged second drive. This small capacity delta corresponds to a corrupted PE/EFI binary in the ESP, which the bootloader silently rejects. The result is a USB stick that mounts and reads as a valid FAT32 partition but does not contain a bootable EFI loader.

Boot Order Side Effects After eMMC Install

A secondary contributor is the U-Boot boot_targets variable. By default, the IOT2050 firmware sets boot_targets=usb0 usb1 mmc1 mmc0 pxe. After mel-setup provisions the eMMC, the variable is updated to prioritize mmc0 (eMMC) and demote USB. If the USB stick is left inserted at next boot, the firmware still attempts bootcmd_usb0 first; if it fails, it drops to mmc0 and boots normally. When both mmc0 and USB are missing or invalid, the bootloader reaches the red STAT LED state.

Step-by-Step Recovery Procedure

1. Power down the IOT2050 and disconnect the 24 V supply.
2. Remove any existing USB boot media and microSD card from the IOT2050.
3. On a separate workstation, write service-stick-image-industrial-os-iot2050-IPC-2.1_S0061.img to a new, previously unused USB 2.0 or USB 3.0 stick of at least 8 GB using balenaEtcher, Raspberry Pi Imager, or dd. Verify the write with the balenaEtcher verify pass.
4. Compare the partition layout of the freshly imaged stick with a second control flash using fdisk -l /dev/sdX or Windows Disk Manager. Confirm the first FAT32 partition size matches the value published in the IOT2050 Service Stick release notes for the specific image revision.
5. Reconnect the 24 V supply to the IOT2050.
6. Insert the new service stick USB drive and observe the STAT LED. A green flashing → green solid transition indicates successful boot.
7. If the STAT LED is red, attach an FTDI USB-to-serial cable to the IOT2050 internal debug header (3.3 V TTL, 115200 baud, 8-N-1) and capture the U-Boot banner. See FTDI Debug Console Diagnostics below.
8. Once booted, re-run mel-setup and select Install System to re-image the eMMC if a clean Industrial OS install is required.
9. After installation, remove the service stick and reboot from eMMC to confirm a clean runtime state.

FTDI Debug Console Diagnostics

The IOT2050 Advanced exposes a 4-pin UART header on the main PCB, located near the SoC. Connecting a 3.3 V FTDI USB-to-serial adapter (FT232RL, CP2102, or CH340) provides access to the U-Boot and Linux kernel console. The header is keyed for 2.54 mm pitch Dupont connectors.

Serial settings: 115200 baud, 8 data bits, no parity, 1 stop bit, no flow control. Use a terminal program such as PuTTY, minicom, or screen. Power the IOT2050 with the FTDI adapter already connected so that the first U-Boot bytes are captured.

The U-Boot banner appears within 2–4 seconds of power-on. If the banner reports No USB device found after enumerating the four EHCI controllers, the USB stick is not being detected and the issue is media-related, not bootloader-related. If U-Boot enumerates the stick but reports Invalid FAT filesystem, EFI load error, or Bad Magic Number, the ESP on the stick is corrupt and the stick must be replaced. A clean boot from the service stick produces output similar to:

U-Boot 2022.04 (Jan 15 2024 - 09:42:11 +0000)
CPU:   Intel(R) Processor(R) N4200 @ 1.10GHz
DRAM:  3.8 GiB
MMC:   mmc@ff3f0000: 0, mmc@ff3f8000: 1
Loading Environment from SPI Flash... OK
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot: 0
IOT2050>

Forcing a USB Boot from U-Boot

Once U-Boot is paused at the prompt, the boot source can be forced manually. The IOT2050 registers the following environment variables:

To force a boot from a specific USB port:

Hit any key to stop autoboot: 0
IOT2050> setenv bootcmd "run bootcmd_usb0; run bootcmd_usb1; run bootcmd_mmc1; run bootcmd_mmc0"
IOT2050> saveenv
IOT2050> boot

If both USB ports fail with the same media, the issue is the USB stick itself and the recovery is to replace it. The saveenv command persists the new boot order into SPI NOR, so the change survives power cycles.

Comparing Boot Sources for Recovery

The IOT2050 supports a recovery path that does not depend on USB media at all. If a working IOT2050 Example Image microSD card is available, the device can boot from microSD and re-image the eMMC without ever touching USB.

If USB boot remains unreliable after a media replacement, switch to the microSD Example Image for recovery. Mount the eMMC partitions from the running microSD environment and use dd or bmaptool to write a known-good image back to eMMC.

Re-Imaging the eMMC from microSD

Once booted from the IOT2050 Example Image microSD:

# Identify the eMMC device
lsblk
# Typical: /dev/mmcblk0 = eMMC, /dev/mmcblk1 = microSD

# Write the Industrial OS rootfs to eMMC (p1 = boot, p2 = rootfs)
dd if=/media/example-image/industrial-os-iot2050-IPC-2.1_S0061.img \
   of=/dev/mmcblk0 bs=4M conv=fsync status=progress

# Sync and reboot
sync
reboot

Alternatively, use bmaptool for a 4-6x speedup on large images and built-in integrity verification:

bmaptool copy industrial-os-iot2050-IPC-2.1_S0061.img.bmap \
    industrial-os-iot2050-IPC-2.1_S0061.img /dev/mmcblk0

Industrial OS Partition Geometry

Understanding the partition layout of the installed Industrial OS is essential for targeted recovery without a full re-flash. The default geometry produced by mel-setup on the Advanced variant is:

If mmcblk0p2 is corrupted but mmcblk0p3 and mmcblk0p4 are intact, the recovery is faster: re-write only the rootfs partition while leaving the persistence partition untouched.

Verification

After recovery, validate the installation end-to-end:

1. Power cycle the IOT2050 and confirm the STAT LED transitions to green solid within 90 seconds.
2. From the host workstation, ping iot2050.local (mDNS) or the static IP assigned during commissioning.
3. SSH into the device as root (default password simatic; change immediately) and verify the OS release: cat /etc/os-release | grep VERSION.
4. Run mel-setup --check to confirm the mel-setup partition is still intact on the eMMC.
5. Re-test the USB service stick on a separate, known-good USB drive to confirm the boot path is functional.
6. Verify the four-port USB enumeration count using lsusb | grep -c "EHCI". Expected value: 3 with no external USB, 4 with one USB stick.
7. Confirm OPC UA server reachability on port 4840 and MQTT broker (if enabled) on port 1883 from a connected PLC or SCADA client.

Best Practices and Field Notes

• Treat USB boot media as consumable. Once a USB stick has been re-flashed more than three times on the same controller, replace it.
• Always compare the post-flash partition size against the release-note baseline. A deviation greater than 1 MB indicates a degraded media controller.
• Keep at least one verified-good microSD Example Image on hand as a recovery media. The Example Image is sufficient for emergency recovery, boot diagnostics, and eMMC re-flash.
• Document the IOT2050 firmware version stored in SPI NOR. If a firmware update is applied after commissioning, the boot order environment variables in U-Boot may be reset to factory defaults, and a service stick that previously booted may stop booting until the boot order is restored.
• For long-term installations, prefer a read-only industrial-grade SD card or mSATA SSD for the operating system rather than USB sticks. Industrial-grade media is rated for the temperature range of the IOT2050 enclosure (-20 °C to +60 °C for the Advanced variant) and is rated for an order of magnitude more write cycles than consumer-grade USB sticks.
• Label USB sticks with the image revision, flash date, and flash count. A physical label is more reliable than a file system note in a partition that may be wiped.
• Avoid front-panel USB ports for boot media in permanent installations. Use the internal USB header with a panel-mount extension routed to an IP65 enclosure gland for shock and vibration resistance.

Diagnostic Decision Matrix

Use the following matrix to map observed symptoms to the most likely root cause and the appropriate first response.

Related Siemens Documentation

• Siemens Industrial OS Installation Procedure (TIA Portal Documentation)

Frequently Asked Questions