Resolving SIMATIC IOT2050 Boot Failure on FS02 Hardware

Problem Description

Field engineers deploying the SIMATIC IOT2050 Basic (MLFB 6ES7647-0BA00-0YA2) frequently encounter a no-boot symptom after inserting a flashed SD card. The STATUS LED stays continuously ON in green instead of blinking, no console output is produced on the debug UART, and the device is unreachable over any of its network interfaces (X1, X2, or the optional WLAN module).

The triggering scenario is reproducible across multiple units:

1. An Example Image is written to a micro-SD card using a standard imaging tool (Raspberry Pi Imager, balenaEtcher, dd, or Win32DiskImager).
2. The same SD card is inserted into two IOT2050 Basic units in sequence.
3. The first unit (older hardware revision) boots normally; the second unit (newer hardware revision) hangs with the LED stuck solid green.

The discrepancy is not caused by a corrupted SD card, an incorrect u-boot environment, or a power supply defect. It is the result of a hardware/firmware version mismatch that manifests only on the newer FS02 (Functional State 02) variant of the Basic.

Affected Hardware and Firmware Identification

Before any corrective action, identify the exact model variant and functional state. Siemens encodes the hardware revision in the device label as a two-digit FS suffix (FS:01, FS:02, FS:04, etc.). On the IOT2050 family the currently documented FS codes are:

Determine the FS of your specific unit from the rating-plate label or by querying the device:

Or read the production data via dmidecode once a compatible image is running:

Documented firmware releases shipped or referenced on Siemens support and the official meta-iot2050 Yocto layer include:

Root Cause: Hardware Revision vs Image Compatibility

The IOT2050 transitioned from a first-generation hardware platform (PG1) to a second-generation platform (PG2) without a visible model-number change. The MLFB 6ES7647-0BA00-0YA2 covers both PG1 (FS:01) and PG2 (FS:02) units. The two platforms differ in:

• System-on-Chip (SoC): PG2 integrates a different TI Sitara revision and an updated PMIC power-tree that requires new pinmux and clock initialization in u-boot.
• EEPROM / board ID: A unique board ID is stored in on-board EEPROM and read by u-boot to select the correct device tree blob (DTB) at boot time.
• Memory training: DDR3L timing parameters on PG2 differ; an FS:01-trained firmware cannot bring up DRAM reliably on PG2.
• Display output: PG2 changes the HDMI/DP PHY routing; legacy device trees cause the kernel to hang during framebuffer initialization.

When an Example Image compiled for FS:01 (such as V1.0.2 or V1.1.1) is inserted into an FS:02 device, the bootloader succeeds in reading the FAT partition and starts the kernel, but the kernel cannot complete the platform initialization and stalls before mounting the root filesystem. The STATUS LED pattern reflects this state.

Compatibility Matrix

The following matrix defines which combinations of firmware, Example Image, and functional state will boot successfully. Use it as a definitive reference when planning a deployment.

✗ entries typically result in a solid green STATUS LED, no kernel console, and no Ethernet link-up on X1. The boot is aborted during board-ID verification or during the device-tree application phase.

STATUS LED Decoding

The front-panel STATUS LED (green/red/yellow tristate) provides the primary diagnostic channel when no console is attached. The decode is documented in the operating instructions shipped with the device.

A solid green LED without blinking after 60+ seconds is the canonical symptom of the FS:01 image on FS:02 hardware mismatch. Capture a console trace through the Micro-USB debug port (/dev/ttyUSB0, 115200 8N1) to confirm.

Resolution Procedure

Three viable resolution paths exist. Choose based on the FS state of each unit in your fleet.

Resolution A — Update FS:01 devices to firmware V01.02.01 and unify on Image V1.2.2

This is the recommended path for mixed FS:01 / FS:02 fleets because the same SD card image can then be used on every device.

1. Download Example Image V1.2.2 from the Siemens Industry Online Support portal under entry ID 109758673 and write it to a micro-SD card (≥8 GB, Class 10 or better).
2. Boot an FS:01 device from this card. Confirm normal operation (blinking green LED, SSH access via X1).
3. Within the running image, execute the firmware update tool that ships inside the V1.2.2 image to install the bundled firmware V01.02.01 bundle:

4. Wait for the STATUS LED to turn yellow (update in progress). The unit will auto-reboot when complete (yellow LED off, green blinking).
5. Power off, re-insert the same SD card, and verify boot. The same card will now boot both FS:01 and FS:02 hardware.

Resolution B — Use a dedicated V1.2.1 / V1.2.2 image only on FS:02 units

When the FS:01 units must remain on an older, validated image (for example, because of regulatory re-qualification), keep two SD cards:

• SD #1: Image V1.0.2 or V1.1.1 — reserved for FS:01 only.
• SD #2: Image V1.2.1 or V1.2.2 — used on FS:02 and FS:04 only.

Color-code or label the SD cards by FS to prevent accidental swaps on the shop floor.

Resolution C — Reflash an FS:02 device with a freshly written supported image

If the on-board firmware on the FS:02 device itself has been corrupted (for example by an interrupted firmware update), follow the recovery procedure:

1. Write the Example Image V1.2.2 to a second SD card.
2. Power off the FS:02 unit.
3. Hold the recovery button (recessed, behind the front panel — see operating instructions) while applying power.
4. Release the button when the LED turns solid red (recovery mode active).
5. Insert the recovery SD card and reboot. The bootloader re-flashes firmware V01.02.01 from the card into the on-board SPI flash.
6. After re-flash completes (green blinking), reboot normally with the target application image.

Firmware Update Procedure (FS:01 to V01.02.01)

Field engineers upgrading an FS:01 unit for the first time should follow this end-to-end sequence. The firmware update is non-destructive: the application filesystem on the SD card is untouched; only the SPI flash is rewritten.

1. Verify the boot image is at least V1.1.1 (the update tool is not present in V1.0.2). If the device is on V1.0.2, write a V1.1.1 image to a temporary SD card and boot from it first.
2. Download the firmware bundle iot2050-firmware-V01.02.01.zip and extract firmware_V01.02.01.bin.
3. Copy firmware_V01.02.01.bin to /tmp on the running IOT2050.
4. Confirm battery-backed RTC clock is set; an invalid date causes the signed-bundle verification to fail:

date
sudo timedatectl set-time "2025-01-15 12:00:00"

5. Run the updater with elevated privileges:

6. Monitor the LED. Yellow = update in progress, do not power-cycle. Green blink = success.
7. After the auto-reboot, verify the new firmware version:

The command should report V01.02.01. If it still reports V01.00.00, the update did not persist — re-run with the recovery procedure (Resolution C).

Firmware Downgrade Procedure

Downgrades from V01.02.01 back to V01.00.00 are supported only through the bootloader recovery path. There is no in-OS downgrade tool.

1. Obtain the legacy firmware bundle from Siemens Support (reference the IOT2050 firmware archive entry on the Industry Online Support portal).
2. Write Example Image V1.2.2 to an SD card and place firmware_V01.00.00.bin in the /boot partition.
3. Boot the device into recovery mode using the front-panel button.
4. The recovery bootloader detects the legacy bundle in /boot and writes it to SPI flash.
5. After the green-blink confirmation, remove power, replace the SD card with the desired operating image, and reboot.

SD Card Image Flashing Procedure

To eliminate SD card write issues as a contributing factor, validate each card after flashing:

1. Write the image using a bit-exact tool. On Linux:

2. On Windows, use Raspberry Pi Imager with the "Use custom image" option; checksum-verify after write.
3. Mount the first (FAT) partition and confirm the following files exist:

ls /media/$USER/boot
# Expected: MLO, u-boot.img, uEnv.txt, sysfw.itb, *-iot2050-basic.dtb, Image, wic-image-*

3. Verify the DTB filename matches your device variant: iot2050-basic.dtb for FS:01/FS:02, iot2050-advanced.dtb for FS:03/FS:04.
4. Run sync and remove the card only after the OS reports the write cache flushed.

Verification Steps

After applying Resolution A or C, verify the fix end-to-end:

1. Power-cycle the FS:02 unit. Observe STATUS LED transitions: off → fast green blink → slow green blink → solid green on OS ready.
2. Connect a serial console (115200 8N1) to the Micro-USB debug port and confirm the kernel prints Booting Linux on physical CPU 0x0 followed by rootfs mount of /dev/mmcblk0p2.
3. Confirm network reachability on X1 (default DHCP):

ssh root@<dhcp-lease-ip>
uname -a
cat /etc/os-release | grep VERSION

4. Verify the firmware version reported by the device matches the expected baseline:

sudo iot2050-firmware-update --version
# Expected: V01.02.01

5. Insert the same SD card into the FS:01 unit (after it has been firmware-updated to V01.02.01) and confirm identical boot behavior.

Known Issues and Edge Cases

Beyond the FS/image mismatch root cause, several documented edge cases can mimic or co-occur with the no-boot symptom:

• 60-day reboot hang (issue #440): Devices running continuously for 60+ days may fail to complete a sudo reboot command and require a hard power-cycle. The mitigation is to schedule supervised reboots (cron-driven reboot) at intervals below the failure threshold, or to apply the latest BSP patch level referenced in the meta-iot2050 issue tracker. See the issue thread on the meta-iot2050 GitHub repository for the current patch status.
• RTC battery depletion: A dead CR2032 backup cell causes the bootloader to fall back to a default timestamp that fails the signed-bundle verification on every boot. Replace the cell and re-run the firmware update.
• Industrial SD card wear: Consumer-grade cards with insufficient write endurance may develop bad blocks on the ext4 rootfs partition, producing the same solid-green LED symptom. Replace with an industrial-grade card (e.g., Swissbit, ATP, or Siemens-approved SD card from the catalog).
• Watchdog false-positive: A user-space service that fails to pet the hardware watchdog will trigger a reset that boots correctly the second time. Confirm by checking journalctl -b -1 for watchdog entries.
• Power supply undervoltage: A 24 V supply sagging below 19 V under load will trip the PMIC and abort boot. Measure at the Phoenix connector under full load.

Preventive Measures for Mixed Fleets

To prevent recurrence across sites:

1. Maintain a single baseline image (V1.2.2 or newer) and a single firmware baseline (V01.02.01 or newer) for every IOT2050 Basic or Advanced unit, regardless of FS.
2. Log the FS state of every unit at commissioning in your asset database. A two-character field (FS:01, FS:02, FS:03, FS:04) prevents future confusion.
3. Use color-coded SD card cases (blue for FS:01, red for FS:02, green for FS:04) to prevent field swaps.
4. Schedule firmware baseline audits quarterly against the latest entry on the Siemens Industry Online Support portal for IOT2050.
5. Subscribe to firmware release notifications via the Siemens Support RSS feed to be alerted when a new PG2-capable image ships.