How LoopCheck Works¶

This section is the technical reference for LoopCheck. The Platform section describes what LoopCheck does and why you would use it. The pages here describe how it works internally and how you use it to test your device.

Everything below refers to the same system shown on the platform pages — the same board, the same runtime, the same test logic — described at the level of detail an engineer needs to work with it.

From platform concept to implementation¶

The platform pages use LoopCheck's own vocabulary. Here is what each part is, technically:

On the platform pages	Technically	Described in
LoopCheck Board	Real-time capable, multi-core microcontroller board (TI C2000 F2838x)	System Architecture
LoopCheck Runtime	Hardware abstraction firmware on CPU1: encoder simulation, analog and real-time I/O	Firmware Architecture
Test logic in C	Your own C code on CPU2, calling the hardware abstraction API over shared memory	CPU2 — your test logic
Test logic in Python	Host-side library that orchestrates your C code: starts sequences, sets variables, reads logs	Python API
Hardware Interfaces	Docking shield mapping the board's GPIO/SPI/UART peripherals to the DUT's connectors	Adapting to a New DUT
Automation & logging	CM core: log streaming and network bridge to the host	CM — logging and automation

The current implementation¶

LoopCheck runs automated, deterministic blackbox tests against embedded systems by simulating their peripheral environment.

The defining characteristic: real-time test logic runs in C on the board, orchestrated from Python on the host. You write the time-critical behavior as C code on a dedicated core, and drive it from an ordinary Python test suite. Timing never depends on network latency or host scheduling.

The system can be adapted to any Device Under Test (DUT) that interfaces via GPIO, SPI, I²C, UART, or similar protocols. Through a dedicated hardware adapter board, the board's peripherals are mapped to the DUT's connectors, allowing the test system to be fitted to any target. The adapter board can add support for specialized interfaces such as RS485, RS232, differential SPI, BLE, or relay-driven signals.

Deliverables and Scope¶

A LoopCheck delivery consists of the following components:

Programmable real-time core

CPU2 is yours. Your C test logic or simulation model runs there in real time and reaches the hardware through a shared-memory API — no register-level work. Standard C with the TI C2000 SDK, developed and debugged on-chip in Code Composer Studio (CCS VS Code).

CPU2 — your test logic
Hardware abstraction firmware

CPU1 provides encoder simulation, analog and real-time I/O behind a clean C API. The CM core handles logging and the network bridge.

Firmware architecture
Python test API

A UDP-based library that orchestrates your C code from a host PC or server: start sequences, set variables, read back logs.

Python API
Hardware adapter board

A docking shield connecting the LoopCheck board to the DUT's peripheral interfaces.

Adapting to a new DUT

Where to start¶

System Architecture — how host PC, firmware, adapter board and DUT fit together, and what runs on which core
Python API — the interface you write tests against
Example: Gherkin scenarios with Behave — one complete test setup, end to end
Adapting to a New DUT — what changes when the target system changes

Writing tests is not tied to a framework

LoopCheck does not prescribe a test framework. Everything is driven through the Python API, so pytest, a plain script, or an existing in-house harness works just as well. The Behave example shows the structure, not a required toolchain.