Restoring IOT2050 Advanced When STAT LED Turns Red on FS:04/05

Restoring IOT2050 Advanced When STAT LED Turns Red on FS:04/05

The SIMATIC IOT2050 Advanced (MLFB 6ES7 647-0BA00-1YA2) is a Siemens industrial IoT gateway in the SIMATIC IPC family. A known configuration state appears on PG2 hardware revisions manufactured before Siemens began pre-flashing the Industrial OS: after 24 V DC is applied at X80 the green STAT LED holds for roughly ten seconds and then locks to a steady red, with no blink pattern. The gateway cannot be reached via PROFINET DCP discovery, IPv4 ARP, ICMP ping, or SSH on either of the two GbE ports. The DisplayPort output and RS232 console emit no shell prompt. The symptom is identical whether the gateway is power-cycled or has RESET held and released. Inserting an SD card programmed with the Siemens Example Image makes the gateway fully bootable, which proves that the SoC, DDR4, GbE PHYs, and 16 GB internal eMMC are physically sound. The fault is software, not hardware: the eMMC was never provisioned with a bootable image at the factory. This article documents the affected FS revisions, the layered root cause, the recovery procedure from a bootable SD card, the procedure to copy the bootable image back to the internal eMMC, and the full LED status reference so the same symptom can be distinguished from PROFINET alarms and firmware fault codes.

1. Problem Description

The following behavior is observed on first commissioning of an IOT2050 Advanced 6ES7 647-0BA00-1YA2 (and on the related 6ES7 647-0AA00-0YA2 Basic variant on FS:04/05 hardware):

1. 24 V DC applied at X80; STAT LED lights green within ~2 s.
2. Green holds steady for ~10–20 s (typical 10 s on FS:05, up to 20 s on FS:04).
3. STAT LED transitions to a non-blinking red and remains red until power is removed.
4. Pressing the recessed RESET button (front face, X10 position) extinguishes the LED while held; releasing it re-runs the same green→red sequence with no diagnostic blink inside the red phase.
5. X1 P1 (PROFINET port, MAC prefix 00:0E:8C) and X1 P2 (LAN) do not respond to ARP from any device in the same subnet. TIA Portal "Accessible devices" (PROFINET DCP multicast 01:0E:CF:00:00:00, UDP/34964) does not list the gateway.
6. DisplayPort output (X6) shows no EDID hand-shake on most monitors; no kernel or bootloader log is emitted because no bootloader has handed off to a kernel.
7. Inserting an SD card programmed with the Siemens Example Image and re-applying 24 V restores full boot, including the getty shell on the serial console at 115200 8N1 on X9 (RJ45 RS232/485).

The failure mode is recoverable in the field by the user; no RMA is required for the symptom alone. A genuinely faulty eMMC presents differently: the boot phase emits MMC controller errors to the serial console, and the eMMC reports zero or near-zero capacity to lsblk. If those symptoms appear instead, escalate to RMA through your normal Siemens Industry Online Support channel.

2. Affected Hardware and FS (Feature State) Versions

Siemens labels each IOT2050 hardware revision with an "FS" or "Feature State" code that is encoded in non-volatile memory and surfaces as a Linux device-tree property. The internal eMMC provisioning policy differs by FS revision; knowing which FS you have is mandatory for picking the right Example Image and for understanding whether the unit was ever shipped with a working Industrial OS.

The 6ES7 647-0BA00-1YA2 Advanced variant ships as FS:05 in most channels. FS:04 and FS:05 are the two revisions that left the factory with an empty eMMC, which is exactly the precondition for the symptom documented in this article. To read the FS code in the field from a working Image, run cat /proc/device-tree/chosen/iot2050-fs-version from a shell prompt on the booted gateway, or check the printed label on the right side of the enclosure next to the serial number.

2.1 Distinguishing Variant Article Numbers

IOT2050 Advanced and Basic variants share the same PG2 PCB family but differ in memory and interface count. The MLFB on the side label maps to the variant:

Both variants exhibit identical behavior on FS:04/05 with empty eMMC; the recovery procedure below applies to either, with the substitution of the matching image variant.

3. Root Cause Analysis

The IOT2050 boots from U-Boot, which is stored in a 16 MB SPI NOR flash on the carrier board. U-Boot then looks for the next-stage bootloader and the root filesystem in this fixed order on PG2 hardware:

1. SD card slot (X11), exposed to Linux as /dev/mmcblk1 with a GPT table expected at LBA 0.
2. Internal 16 GB eMMC, exposed as /dev/mmcblk0 with the same partition table convention.
3. Network boot (PXE) — not enabled by default; reserved for service and only available if U-Boot is configured via the service menu to attempt it.

If none of the boot sources contain a recognized boot.scr along with a kernel image (Image, zImage, or fitImage) and a root filesystem, U-Boot aborts the boot attempt and hands control to a hard-coded error indicator that drives the STAT GPIO line to a steady red. On PG2 hardware the firmware was tightened compared to PG1 to halt immediately and signal solid red, which is why the symptom is so deterministic on FS:04/FS:05.

Two conditions converge to produce the symptom:

• Empty eMMC: the GPT on /dev/mmcblk0 contains no boot or root partition, or the partition table itself is missing because the NAND controller was never initialized with a layout.
• No SD card: the user's recovery medium is not present in X11.

The reason the eMMC is empty in the field is that PG2 hardware was originally planned to ship with Industrial OS, and Siemens held the pre-installation step while aligning the IndOS image with the new Sitara AM6548 SoC. A subset of FS:04/FS:05 units left the factory in that window before the pre-installation kitting line caught up. IndOS pre-installation was reinstated for FS:06+ without a public service bulletin; some channels shipped mixed stock. The user-visible consequence is that a brand-new IOT2050 Advanced can arrive with no operating system on its internal storage, and the only working user-reachable medium is whatever SD card the integrator prepares.

3.1 U-Boot Environment Snapshot

For traceability during recovery, the following U-Boot environment variables govern the boot order on PG2 firmware. The values below are read from a healthy FS:05 unit after recovery:

If the boot targets are missing mmc1, the unit will not attempt SD boot regardless of card presence. Verify via printenv at the U-Boot prompt (hit a key during the green phase to break into U-Boot).

4. Pre-Checks Before Recovery

Before flashing the eMMC, validate that the failure really matches the "empty eMMC" root cause rather than a power, cabling, or downstream memory fault. Each check is non-destructive.

1. Supply voltage at X80: 24 V DC nominal, allowable range 19.2–28.8 V DC per the IOT2050 manual equipment design. Measure under load, not at the PSU terminals; long 24 V cabinet runs can drop 1–2 V. If the voltage sags below 19.2 V during the 10 s green phase, the SoC resets itself and the STAT LED never reaches red as expected — the symptom is similar but the root cause is upstream.
2. PWR LED steady green: confirm both PWR LEDs (one near X80 area, one general status) are solidly green. A missing or dim PWR LED means the carrier board is not fully powered and STAT LED behavior is undefined.
3. Audible cues: listen for the eMMC and SD card slot. An eMMC fault (controller or NAND failure) is typically silent during the green phase; a working U-Boot boot produces a soft tick from the SPI NOR as it reads.
4. Validate the SD card on a PC: with the SD card mounted, run lsblk -f. Expect two partitions, the first FAT32 (boot, mount point /boot), the second ext4 (rootfs, mount point /). Verify file presence: ls /media/$USER/BOOT/ should show Image, iot2050-advanced.dtb, and boot.scr.
5. Live-boot the SD image and verify the eMMC is present: from a booted shell on the gateway, run lsblk to confirm mmcblk0 enumerates with ~14.6 GB. Run dmesg | grep -i mmc to verify the MMC controller enumerated both buses. If the eMMC is absent or reports 0 MB, escalate to RMA — the fault is hardware, not FS-related.
6. FS code confirmation: cat /proc/device-tree/chosen/iot2050-fs-version. Expect fs04 or fs05. If the FS code is something else and the eMMC is empty, you have an unusual mixed-stock unit and the appropriate next step is to engage Siemens Industrial OS support with the FS code and serial number.

5. Recovery Procedure

The recovery has two distinct stages: first, get the gateway running by booting the Example Image from SD; second, copy that live image back onto the internal eMMC so the device boots without the SD card. The whole procedure can be completed in 15–25 minutes on a cold unit.

5.1 Stage A — Stage the bootable SD card

1. Download the latest Example Image for IOT2050 PG2 (FS:04/05) from the Siemens Industry Online Support product-support entry index. Use Example Image 1.2.2 for FS:05; 1.2.1 is also valid and is what Siemens initially flagged for FS:04. Do not use Example Image 1.1.x: it predates PG2 hardware support and will not complete the kernel hand-off.
2. Unzip the archive to a working directory on a Linux host. You will see a .wic file (e.g. iot2050-example-image-1.2.2.wic.xz) and a signature/hashes file.
3. Flash the .wic to a microSD card of at least 8 GB (recommended 16 GB, Class 10 / A1 or better) using a Linux host with dd, or balenaEtcher from Windows or macOS. From a Linux shell:

   # Identify the SD card reader; double-check before issuing dd
   lsblk
   # Decompress and write to /dev/sdX (substitute correct device)
   xzcat iot2050-example-image-1.2.2.wic.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
   sync

   Pointing dd at the host drive destroys the host filesystem. Confirm the device tree by size and by unplugging the SD reader once.
4. Re-insert the SD card into the IOT2050 with the contacts facing down (label up). Make sure the card seats with a positive click. A partially inserted card sometimes appears seated but does not engage the detect pin and produces intermittent boots, which can mask the actual eMMC fault.

5.2 Stage B — Boot from SD and verify the live image

1. Apply 24 V DC. STAT LED should hold green for the full boot duration (30–60 s on a cold system) and not turn red, because the SD card supplies a valid image.
2. Watch the DisplayPort output (X6) or the serial console (X9, RJ45 RS232, 115200 8N1, no flow control). U-Boot banner, Linux boot log, and a getty prompt appear in sequence. The first boot may apply a filesystem resize and reboot; the second boot brings up the network interfaces.
3. From a host in the same subnet, log in over SSH or via the serial console. Default credentials are documented in the IOT2050 manual equipment manual; change them on first login before exposing the gateway to a routable network.
4. Confirm the internal eMMC is visible to the running kernel:

   lsblk
   # expect:
   # mmcblk0     14.6G  — internal eMMC (target for recovery)
   # mmcblk1      7.4G  — SD card (source) with partitions mmcblk1p1 (FAT32) and mmcblk1p2 (ext4)

5. Confirm the FS code:

   cat /proc/device-tree/chosen/iot2050-fs-version
   # expect: fs04  or  fs05

   If the FS code is other than fs04/fs05 and the eMMC is still empty, the unit is from an unusual mixed-stock batch and the IndOS image (not the Example Image) is the correct next step; contact Siemens support with the FS code, MLFB, and serial number.
6. Quick health check of the live image:

   systemctl --failed
   dmesg | grep -Ei 'error|fail|critical'
   ip a

   No "failed" services and no error/fail lines on the last boot is the pass criterion.

5.3 Stage C — Write the image back to internal eMMC

From the live SD boot, write the bootable image to mmcblk0 using the toolkit shipped with the Example Image. The preferred helper handles GPT backup relocation and U-Boot environment updates that a bare dd does not.

# Inspect the helper
ls /usr/share/iot2050/
# The post-install helper writes the active SD image back to the eMMC
sudo /usr/share/iot2050/install-to-emmc.sh
# or, if the helper is not present on the running image, replicate it manually:
sudo dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=4M status=progress conv=fsync
sync

The helper restores GPT primary and backup headers, copies both partitions verbatim, and re-writes the U-Boot environment to point at the eMMC by default rather than the SD card. After the helper completes (typical 4–7 min depending on SD card speed class), shut the gateway down cleanly:

sudo shutdown -h now
# Wait for the PWR LEDs to drop, then remove the SD card.

6. LED Status Reference

The IOT2050 Advanced front face carries multiple status LEDs; the STAT LED is the one that drives recovery work. The full set, per the equipment manual, is tabulated below.

7. Verifying the Repair

After flashing the eMMC and removing the SD card, confirm a clean cold boot from internal storage:

1. Apply 24 V DC with no SD card present.
2. STAT LED should light green within ~2 s, blink green briefly during U-Boot hand-off, then hold green while Linux boots — no red phase.
3. GbE link LEDs on X1 P1 and X1 P2 should establish auto-negotiated link within 5 s; verify IPv4 reachability on the configured address (DHCP by default, with fallback to 192.168.1.100 on the Example Image if no DHCP server responds).
4. From a host in the same subnet, run ping 192.168.1.100 (or the DHCP-issued address shown in your router's lease table). Expect RTT < 5 ms on a direct copper link.
5. Open ssh iot-user@<address>; confirm login and the iot2050 prompt.
6. Run sudo systemctl status iot2050-led.service (or the equivalent health-check service shipped with the image) to confirm user space is healthy.
7. If the gateway will be used as a PROFINET IO controller or device, assign the PROFINET device name from TIA Portal and confirm with the profinet tool that the name is persisted in non-volatile storage on the gateway.
8. Verify eMMC integrity from inside the running gateway:

   sudo smartctl -a /dev/mmcblk0
   # or, for eMMC, the simpler:
   sudo mmc extcsd read /dev/mmcblk0 | grep -E 'LIFE_TIME|HEALTH'

   Both should report a high "DEVICE_LIFE_TIME_ESTIMATION" in the A1 field (typical 0x01 for new eMMC) and no pre-EOL info.

8. Industrial OS vs. Example Image: Choosing the Right Image

Siemens publishes two distinct system images for the IOT2050. Pick the right one for the deployment context before flashing the eMMC.

For unit recovery alone, the Example Image is sufficient. To move to production, install Industrial OS via the IOT2050 Industrial OS Installer after the eMMC is reachable. The Industrial OS .wic image is the one Siemens currently pre-installs on FS:06+ hardware at the factory.

8.1 Industrial OS Installer Path

When you intend to deploy production Industrial OS:

1. Once the Example Image is running on the eMMC (post Stage C of the recovery procedure), download the current Industrial OS .wic.xz for PG2 to the gateway, or stage it on a USB drive plugged into one of the X7/X8 USB 2.0 ports.
2. Run the Siemens on-device installer script provided with the IndOS image:

   cd /opt/iot2050-installer
   sudo ./install-indos.sh --image /path/to/industrial-os-iot2050-x.y.z.wic.xz

3. Reboot when prompted. STAT LED returns to green within ~15 s after the install completes.
4. Assign the PROFINET device name and verify from TIA Portal before any IO traffic is enabled.

9. SD Card Slot Mechanical Note

The X11 microSD slot on the IOT2050 uses a push-push mechanism; insertion requires positive force until the spring-loaded catch engages. A card that appears inserted but does not latch can produce this fault intermittently: U-Boot probes the slot, sees no SD card, then attempts the eMMC, sees the empty GPT, and lights red. If the symptom comes and goes between power cycles, particularly after recent panel rework or transit vibration, eject and reseat the card. Mechanical tolerance is narrow enough that cards from different vendors (SanDisk, Samsung, Kingston, Transcend) sometimes produce different insertion force; pick one and stick with it across a fleet so that field engineers reach for a known physical fit.

Recommended cards: industrial-grade microSD, rated −40 °C to +85 °C, with on-controller wear leveling and at least 8 GB usable capacity. Consumer cards often fail write endurance within months in an industrial gateway use case.

10. PROFINET Commissioning After Recovery

With the gateway booting cleanly from eMMC, the next step in most installations is PROFINET integration. The IOT2050 is a PROFINET IO Device or IO Controller depending on firmware; TIA Portal is the commissioning tool.

1. Wire X1 P1 to the PROFINET network. The PROFINET port is the lower of the two RJ45 jacks on the front face and labeled "X1 P1".
2. In TIA Portal, open "Online → Accessible devices". The gateway should appear within 5 s of link-up, identified by MAC address and PROFINET device name (default blank on Example Image, blank on a fresh IndOS until assigned).
3. Right-click the discovered device and choose "Assign PROFINET device name". Use a scheme consistent with the project (e.g. iot2050-a1, iot2050-line3-gw). The name is written to non-volatile storage and survives power cycles.
4. If the gateway will be an IO controller, also assign the IO supervisor role and configure the IO devices it owns in the PROFINET topology editor.
5. Verify with the on-device profinet tool from the shell:

   profinet show name
   profinet show ip

   The reported name and IP must match what TIA Portal assigned.

The PROFINET stack health is visible on the four PROFINET-specific LEDs (RUN, STOP, ERROR, MAINT). Investigate any of these going into the red fault state before assuming a re-flash is required — PROFINET alarms are runtime issues, not boot-image issues, and re-flashing the gateway does not resolve them.

11. Watchdog and Self-Diagnostics After Recovery

After recovery, configure the on-device watchdog and the health-check service so that future boot-image issues are caught and signaled before they become field faults:

1. Enable the systemd watchdog for the IOT2050 health-check service:

   sudo systemctl edit iot2050-health.service
   # add:
   # [Service]
   # WatchdogSec=30
   sudo systemctl daemon-reload
   sudo systemctl restart iot2050-health.service

2. Enable the Linux kernel hardware watchdog (TI Sitara AM6548 has an internal watchdog tied to the power-management controller):

   sudo modprobe omap_wdt
   sudo systemctl enable watchdog.service

   With a 30 s timeout, a hung user space triggers an SoC reset that re-runs the U-Boot hand-off. If the same image is healthy, the gateway boots green again; if the eMMC has been corrupted in the field, the STAT LED goes red and the symptom reappears, which is the actionable signal.
3. Forward health-check notifications to the site SCADA via OPC UA or PROFINET diagnostics. The Example Image ships an OPC UA server on port 4840 that exposes the watchdog and image-health tags out of the box.

12. Field Commissioning Checklist

Use the following checklist at every FS:04/FS:05 IOT2050 first-power-on, regardless of whether the symptom is observed:

13. Preventive Maintenance and Monitoring

Once recovered, treat the IOT2050 Advanced like any other fanless industrial gateway with respect to monitoring:

• Temperature: the SoC junction temperature is exposed via cat /sys/class/thermal/thermal_zone0/temp in millidegrees Celsius. Alert above 90 °C (the thermal derating threshold on PG2 is 105 °C, but operation above 90 °C shortens eMMC life).
• eMMC wear: read "DEVICE_LIFE_TIME_ESTIMATION_A" and "DEVICE_LIFE_TIME_ESTIMATION_B" from mmc extcsd read /dev/mmcblk0. Both should stay at 0x01 (0–10% used) for years in a typical gateway service life. Alert when they cross 0x10 (90% used) and plan replacement.
• Firmware updates: subscribe to the Siemens IOT2050 firmware release feed via Siemens Industry Online Support and apply security patches on the same cadence as the rest of the PLC fleet. The Example Image and the Industrial OS both update via signed packages; do not apply unsigned updates.
• Log retention: forward journalctl to a syslog server if the gateway is in scope of a plant-wide historian. SD-card corruption and unexpected reboots are easier to diagnose when the boot messages are persisted off-device.

14. Frequently Asked Questions