Consortium brought its two-core messaging stack onto an NXP development board with a hardware-in-the-loop test that loads Cortex-M7 firmware, runs the Linux application for 15 seconds, and grades stages from both processors' logs. The test found a wrong device tree that let Linux touch a controller it didn't own, stale shared memory that made a new session accept an old reply, and an interrupt line that stayed masked after firing before the application opened it.
Those failures only make sense when the rig keeps state across runs. A warm reboot preserved an old descriptor in memory. A cold boot cleared it and passed every stage, but pulling power immediately after copying firmware also discarded the new file before storage had flushed it. The team proved that last failure by comparing checksums before and after the power cycle, then added an explicit sync step to the procedure.
The remaining fixes are concrete: re-arm the userspace input/output interrupt when the device opens, add a per-session value to reject stale replies, and verify the copied firmware after a power cycle. Embedded test rigs should treat reset method, stored artifacts, and pre-test memory as inputs, because otherwise a green run can depend on whichever state the previous run left behind.