SRL-P Safety Filter — STM32F407 Bare-Metal Hardware Experiment: Raw On-Device Results (Firmware v7 and v9)

What these logs contain, and what they establish This deposit contains the raw on-device output of two bare-metal experiments on an STM32F407VGT6 (ARM Cortex-M4F, 16 MHz HSI, no RTOS): a 100,000-iteration benchmark (firmware v7) and a 24-hour continuous stress test (firmware v9). The v9 stress-test log records aggregate quantities only: the total iteration count (2,421,500,225), the hard-constraint violation count (0), the global worst-case latency (1,029 µs), and 24 hourly snapshots of a single running-maximum register. It does not record a latency distribution, per-path counts, or independent per-hour maxima; the 24 identical hourly values (all 1,029 µs) are repeated reads of the same running-maximum register, not independent measurements. The stress test drives the filter with a fixed 100-iteration input cycle: fast path on most iterations; intermediate-validation path every 50th iteration; emergency-suspension path (the longest execution path) every 100th iteration. This cycle is repeated approximately 24 × 10⁶ times without variation. On the Cortex-M4F pipeline used here — no data cache, no instruction cache beyond fixed flash wait-states, no dynamic branch predictor, no preemption — an identical input deterministically traverses an identical instruction path on every repetition. The 24 identical hourly worst-case values confirm this: the maximum is reached within the first 100 iterations of the first hour and does not change thereafter. What these logs establish Endurance and determinism: the worst-case execution time is reached within the first 100 iterations and does not drift, degrade, or exhibit any transient hardware fault across 24 continuous hours of operation; zero hard-constraint violations occur throughout. Worst-case latency: the genuine measured WCET of the emergency-suspension path is 1,029 µs — a 14.57× margin below the 15 ms medical deadline. What these logs do not establish These logs do not establish 2,421,500,225 statistically independent safety trials. The number of distinct input conditions exercised is approximately 100; the large iteration count reflects deterministic repetition of those 100 conditions, not independent sampling of the input space. The Clopper–Pearson upper bound reported in the companion manuscript (p_upper = 1.24 × 10⁻⁹ at 95% confidence, N = 2,421,500,225, k = 0) is a reliability statistic on the implementation under repeated identical loading. It quantifies the probability that the firmware would have produced an infeasible output on any given invocation of the fixed 100-iteration cycle, given that none of the 2.42 × 10⁹ invocations did so. Its strength derives from the architectural determinism of the platform — the guarantee that identical inputs produce identical outputs on every cycle — rather than from statistical independence of distinct input conditions. It is reported as an endurance bound and does not enter the combined software-domain Clopper–Pearson bound (N = 931,356 across twelve independent software-domain experiments), which is computed independently and is unaffected by this caveat. Relationship to companion manuscript These files are companion hardware data for: Serra-Taylor et al. "Reflected dynamics induced by deterministic safety projections." (in preparation, 2026). The v7 benchmark establishes per-path latency; the v9 stress test establishes endurance. Together they constitute the hardware-in-the-loop validation for the STM32 embedded experiment reported in that manuscript. The Clopper–Pearson bound (1.24 × 10⁻⁹) corresponds to the v9 run.