1. 课程导入

在嵌入式系统、工业控制、汽车电子和通信设备中，绝大多数故障并不是稳定复现的“硬故障”，而是偶发、瞬态、与时间窗口强相关的“软故障”。这类问题往往在实验室无法复现，却在现场随机出现；用普通断点调试会破坏时序，用简单日志又抓不到关键瞬间。本课程围绕“复杂触发”和“偶发故障捕获”两条主线，建立一套从问题建模、触发设计、数据采集到复盘归因的完整方法论。

一、学习目标

完成本课程后，学习者应能独立完成以下任务：

• 区分硬故障、软故障、间歇故障和边界故障，判断问题是否适合用触发捕获方法解决。
• 根据信号特征设计单级触发、多级触发、组合触发和状态机触发条件。
• 使用逻辑分析仪、示波器、片上调试单元和软件探针搭建捕获链路。
• 理解触发深度、采样率、预触发/后触发比例、时间戳精度之间的参数权衡。
• 对捕获到的波形、日志和状态快照进行时间对齐与因果分析。
• 建立可复用的偶发故障捕获清单和复盘模板，减少重复排查成本。

二、核心概念

本课程涉及的概念较多，但可以归纳为四组：故障类型、触发机制、捕获资源和证据链。理解这四组概念之间的关系，是后续所有章节的基础。

其中，触发机制是课程的技术核心。普通调试往往只关注“看到什么”，而复杂触发关注的是“在什么条件下开始看”。触发条件设计得越精确，捕获窗口越窄，证据密度越高，归因速度越快。

三、整体框架

本课程按“认知—设计—实施—分析—复盘”五个阶段展开，共30章。整体框架可以用下面的关系图表示：

五个阶段并非严格线性，实际项目中经常需要回到上一阶段调整触发条件。例如，分析阶段发现证据不足，就要回到设计阶段增加触发层级或扩大捕获窗口。

四、典型场景与误区

先看一个典型场景：某工业控制器在运行数小时后偶发通信中断，现场无法复现。工程师最初用串口打印日志，但日志显示一切正常。后来改用逻辑分析仪，设置“CAN总线错误帧出现”作为触发条件，并保留故障前200ms的预触发数据，最终发现是电源纹波导致收发器在特定负载下进入错误状态。这个案例说明：触发条件的选择直接决定能否看到真正的故障现场。

初学者常见的误区包括：

• 只关注故障瞬间，忽略故障前上下文。没有预触发，看到的只是结果，不是原因。
• 触发条件过于宽泛。例如用“任意边沿”触发，导致捕获大量无关数据，关键帧被淹没。
• 采样率与信号带宽不匹配。采样率不足会丢失窄脉冲，导致误判为“没有故障”。
• 忽略时间同步。多通道、多设备数据没有统一时间基准，无法做因果排序。
• 把偶发故障当成稳定故障处理。反复重启、反复复现，消耗大量时间却抓不到现场。

五、本课程的学习方法

建议按以下方式学习：每章先理解概念，再对照参数表或配置示例，最后用一个小实验验证。课程中会出现大量真实参数，例如采样率、存储深度、触发位置和超时时间。下面是一个典型的触发配置片段，后续章节会反复用到类似结构：

trigger:
  mode: sequence
  stage1:
    source: CAN_ERR
    condition: rising_edge
  stage2:
    source: POWER_RAIL
    condition: below_threshold
    threshold_mv: 3300
    holdoff_us: 120
  capture:
    sample_rate_msps: 100
    depth_samples: 1048576
    pretrigger_percent: 40
    posttrigger_percent: 60
    timestamp_unit: 1ns

这段配置表达的是：先等待CAN错误帧上升沿，再在120微秒内检测电源轨是否低于3.3V，两个条件都满足才开始捕获，并保留40%的预触发数据。这种“序列触发+参数约束”的组合，正是复杂触发的典型形态。