Validation status

Build results, protocol checks and reproducible test commands.

Evaluation evidence as of 1 October 2026.

Real-stack integration · 1 October 2026

The exact version pair matters

A fresh real-stack run passed 6 of 9 integration cases and 14 of 15 CTest targets. Three cases failed: mandatory tag writes (-4), Data Storage write/read mismatch, and Data Storage restore (-6).

Tested master: d23fd3034c0203ef829bd9734806389f8708fa94
Tested device (develop): 0cb3ed9f06f8f4ab820f06369a42e724ae50ea93

Open integration issues for this version pair: mandatory tag writes and Data Storage write/read and restore.

Reproduce the real-stack check

Start in an empty directory on Linux with Git, CMake, a C compiler and the CMocka development library installed. These commands pin both repositories to the tested pair. 

git clone https://github.com/w1ne/iolinki.git iolinki-device
git clone https://github.com/w1ne/iolinki-master.git iolinki-master
git -C iolinki-device checkout --detach 0cb3ed9f06f8f4ab820f06369a42e724ae50ea93
git -C iolinki-master checkout --detach d23fd3034c0203ef829bd9734806389f8708fa94
cmake -S iolinki-master -B iolinki-master/build -DIOLINKI_DEVICE_DIR="$PWD/iolinki-device"
cmake --build iolinki-master/build
ctest --test-dir iolinki-master/build --output-on-failure

For this known pair, expect the three integration cases described above to fail and CTest to exit with a nonzero status. They belong to the real-stack test target, so the suite reports 14 of 15 CTest targets passing. Inspect the pinned real-stack test source for the assertions and individual cases.

Evidence by validation level
Check Current evidence What it establishes
Linux host build and tests v2.1.0 built with GCC 13; 36/36 CTest targets passed on 2 October 2026. Reproduce the commands and inspect test source. Buildability and the behaviors covered by host tests.
Device / standalone master simulation Separate master stack and software testing are available. Software protocol interactions between the device and master stacks.
MCU reference firmware Firmware builds pass for STM32G0B1RE/TIOL112, Nucleo-U575ZI-Q/Zephyr/TIOL112 and ESP32-C3-DevKitM-1/ESP-IDF/STEVAL-IOD003V1. See the reference projects. Reproducible source and MCU firmware compilation.

Release firmware execution evidence

The v2.1.0 release packages firmware and simulator logs together. Its LabWired recipes execute actual MCU instructions and firmware interrupt handlers in both engine execution modes.

  • STM32G0 / TIOL112: startup, 1 MHz timer, GPIO/UART configuration, wake interrupt and COM2 setup; engine 4ff8cba.
  • ESP32-C3 / L6362A: ROM and second-stage boot, application execution, GPIO ISR, UART GPIO-matrix routing and COM2 8E1; experimental published engine d528c78.
  • STM32U5 / TIOL112: firmware compilation and host adapter tests.

WAKE and overload edges are explicit simulator inputs. These checks establish the listed firmware behaviors; analog transceiver and supply-fault coverage, physical master interoperability and conformance require their respective measurements. Download firmware, recipes and IODD tooling.

What a useful physical validation report contains

The new reference-device commit passes 30/30 host CTest targets, including cyclic frame exchanges, both transceiver control drivers and UART error handling. Complete firmware images build for STM32G0B1RE/TIOL112 with Arm GCC, Nucleo-U575ZI-Q/TIOL112 with pinned Zephyr 3.7.2, and ESP32-C3/L6362A with ESP-IDF 5.4.0. The Linux demonstration also passes a virtual-master parameter persistence check across process restarts. The embedded reference projects use RAM parameter storage.

  1. Reproducible setup: release or commit, build tools, MCU board, PHY and revisions, schematic/wiring, power setup and the master model/firmware.
  2. Link behavior: wake-up and startup, negotiated COM mode and cycle time, stable cyclic process data, byte counts and measured C/Q timing.
  3. Services: identification and mandatory parameters, ISDU reads/writes, errors and events, and data storage where applicable.
  4. Recovery: cable disconnect/reconnect, power cycles, invalid frames and relevant fault handling, with pass/fail criteria and logs.
  5. Scope: test duration, tested modes, limitations, and links to captures or reports. Certification, if obtained, needs its own official record.

Consult the IO-Link Community for official technology and conformance information. Product qualification depends on the actual device, electronics and integration.

Maintenance evidence

Review the release history, v2.1.0 changelog, CI runs and open issues. They show published changes and current work; they do not create a release cadence or a new support SLA. Purchased support remains governed by the commercial terms and your agreement.

Start with host evaluation, then choose a hardware path.