Most early RT-STACK faults become manageable when symptoms are separated into power, debug, trigger, communication and output layers. Change one variable at a time and retain the captures that prove the outcome.
Common symptoms
| Symptom | First checks |
|---|---|
| No boot or debug connection | Power rails, reset/BOOT configuration, ST-LINK wiring, option bytes and board revision. |
| No CAN status | 500 kbit/s setting, bus termination, CAN wiring, common reference and firmware boot state. |
| RPM but wrong angle/phase | Sensor polarity, tooth count, missing-tooth ratio, angular offset, cam pattern and scope capture. |
| Unexpected output activity | Boot/reset polarity, channel map, harness continuity, inactive states and load fixture. |
| Output timing mismatch | Engine-cycle convention, firing table, requested advance/duration, trigger synchronization and measurement reference. |
Useful support bundle
- RT-STACK board, harness and firmware revision.
- Exact engine/trigger configuration files.
- Power conditions and load type.
- Oscilloscope screenshots with timebase and probes identified.
- CAN log plus DBC version.
- Steps to reproduce, expected result and observed result.
Operational discipline
Keep a known-good bench configuration, tag every binary with its source revision, record every output map, and repeat the passive-load proof after any change that affects firmware, wiring, board revision or calibration. RT-STACK is not road-legal and must not be used as a safety-critical controller without the independent engineering, testing and approvals required for that use.
Suggested screenshot: fault-isolation flowchart or annotated CAN/oscilloscope support bundle.