CAN总线唤醒为何误触发？休眠电流怎么压？

静态电流总是压不下来，偶发还会自己醒一次，这类问题常常不是软件睡得不够深，而是物理层待机边界没定稳。CAN总线进入低功耗后，真正难的是既别误唤醒，又别把该醒的事件漏掉。

待机收发器并不会完全无视线路，它仍要监视总线电平变化，以便在外部节点发起活动时把主控拉醒。问题在于，车载和工业现场的线路上本来就有浪涌、抖动、地弹跳和插拔瞬变，这些变化在收发器眼里未必都和真实报文活动明显不同。若唤醒判据太松，系统就会在噪声下频繁自唤醒；判据太严，又可能漏掉真正需要响应的唤醒模式。

选择性唤醒收发器试图把这件事做细：只有匹配特定ID或特定模式的帧才触发主控上电。可代价是判别窗口、滤波时序和本地时钟都要足够稳，否则低功耗状态下的误判会比普通唤醒更难查。很多问题白天实验室复现不了，到了夜里、电池电压更低或干扰更复杂的环境里才突然出现。

静态漏电往往又来自另一侧。终端偏置、唤醒引脚上拉、隔离电源待机损耗和外设背供电路径，只要其中某项没有在休眠架构里被单独审计，总电流就可能比预期高出一截。更糟的是，某些漏电通道只在总线部分显性、节点半上电或外围模块未完全掉电时才出现，表面看像“偶发高电流”，根因却是路径设计本来就不干净。

对CAN总线而言，低功耗设计不能只看主控睡眠电流，而要把收发器、终端、唤醒源和外设供电域一起算。若主控睡得很深，收发器却仍在被外围电路拖着消耗，整机静态电流照样压不下去。把责任只推给软件任务，通常会错过真正的耗电通道。

显性超时机制和唤醒滤波窗口也值得单独审查。线路若被故障节点持续钳在显性，待机收发器可能反复尝试上报或维持异常状态，既影响休眠也影响后续恢复。若滤波窗口设置与现场噪声特征不匹配，误唤醒会集中出现在某些继电器动作、接触器切换或充放电瞬间。

验证这类问题时，最好把正常唤醒、噪声注入、显性钳位和低电压待机放在同一套测试脚本里跑，并记录每次唤醒前线路到底发生了什么。只要能把误触发时的总线脉冲、供电状态和漏电路径同时抓到，问题通常就不再神秘。

维护和后装模块也常把低功耗边界改坏。新增一个常电节点或诊断设备后，原本干净的待机网络就可能多出背供电与误唤醒通道，所以任何后装都不该只做功能测试，还应复核休眠电流和唤醒稳定性。

若系统还跨多个供电域切换，最好把各域断电顺序和唤醒路径一并画清楚。很多误唤醒不是线路上真有报文，而是供电边界切换时自己制造了像报文的脉冲。

若平台支持唤醒源日志，最好把每次从待机回到运行的触发条件留下来。因为低功耗问题最难的并不是修复，而是先把偶发触发变成可回看的证据链。

所以，低功耗并不是简单把主控关掉，而是要让这条链路在沉睡时仍保持可控判断。把唤醒判据和漏电路径一起收紧，系统才不会在夜里自己把自己叫醒。