CAN Bus 錯誤訊框是什麼？

錯誤訊框是 CAN 協定中的錯誤處理結構，不是帶有一般應用資料的正常訊框。它包含 Error Flag（錯誤旗標）及 Error Delimiter（錯誤分隔符）；後者為 8 個隱性位元。

處於 Error Active 狀態的節點偵測到錯誤時，可發出由 6 個顯性位元組成的主動錯誤旗標。其他節點偵測到被破壞的訊框後，依協定處理當前訊框，並可能發出自己的錯誤旗標。Error Passive 節點的旗標則由 6 個隱性位元組成，其影響與主動旗標不同。

CAN 控制器如何偵測與處理錯誤？

Classical CAN 透過位元監測、位元填充檢查、格式檢查、ACK 檢查與 CRC 檢查偵測錯誤，並搭配錯誤通知、重傳與錯誤限制維持通訊。仲裁時正常輸掉優先權，不應直接判定為位元錯誤。

以下以三個 Error Active 節點作簡化說明：發送節點察覺送出與讀回的位元不一致，發出主動錯誤旗標；其他節點偵測到異常後亦反應。受影響的訊框被捨棄，發送端在匯流排可用及控制器設定允許的條件下重新傳送。

位元填充與錯誤旗標的關係

Classical CAN 的動態位元填充規則適用於 SOF 至 CRC 序列的相關區段：連續五個相同邏輯值的位元後，發送端插入一個相反值的填充位元，接收端再移除填充位元。不是整個訊框的所有欄位都採這項規則。

主動錯誤旗標包含連續 6 個顯性位元，因此在填充區段能引發其他節點的填充錯誤。若錯誤發生於固定格式欄位，其他節點也可能透過格式檢查察覺異常，不能將所有錯誤通知都只解釋為填充錯誤。

錯誤計數器如何限制故障節點？

每個 CAN 節點以發送錯誤計數器 TEC 與接收錯誤計數器 REC 追蹤錯誤狀態。錯誤累積可使節點轉為 Error Passive；當 TEC 超過 255 時，節點進入 Bus Off。

常見入門示例會將發送錯誤表示為 TEC 增加 8、接收錯誤表示為 REC 增加 1，但完整規則包含例外及其他增減條件。成功通訊可使計數下降，不能把這個簡化示例當成所有錯誤的固定公式。

主動錯誤旗標為何可能形成 6～12 個顯性位元？

單一節點的主動錯誤旗標仍是 6 個顯性位元。當不同節點在不同時間開始發出旗標，匯流排上的旗標疊加區段可能形成 6～12 個顯性位元；這不是單一旗標自行變長。

6 位元範例：節點同時發現錯誤

各節點同時發出主動錯誤旗標時，6 位元序列完全重疊，匯流排上的旗標區段維持 6 個顯性位元。此圖例用來理解起點相同的疊加結果。

12 位元範例：其他節點較晚反應

若其他節點直到第一個旗標的第 6 個位元才偵測到填充錯誤，接著才開始送出自己的 6 位元主動旗標，疊加區段可延長至 12 個顯性位元。

9 位元範例：旗標部分重疊

若第一個旗標開始前已有 3 個顯性位元，其他節點可能在第一個旗標進行到一半時就偵測到填充錯誤。後續旗標與前一旗標部分重疊，使圖中從第一個旗標起點計算的區段為 9 個顯性位元。

圖例的計數必須先確認起點；旗標之前已存在的資料位元，不應全部算成錯誤旗標。旗標區段與後續 8 位元錯誤分隔符，也不能混成同一長度。

Error Active、Error Passive 與 Bus Off 有何差異？

Error Passive 仍可參與通訊，Bus Off 則停止參與正常匯流排通訊。區分狀態時，需同時看 TEC／REC 與節點行為，不能只憑看到錯誤旗標就認定 Bus Off。

Error Passive 發送節點與接收節點的差異

被動錯誤旗標由隱性位元組成，不能像主動旗標一樣強制匯流排呈現顯性。對發送節點而言，它偵測錯誤後的行為可能使其他節點也發現填充或格式異常，其他 Error Active 節點便可能發出主動旗標；但不是每次被動旗標都必然引發全網反應。

對 Error Passive 接收節點而言，它的隱性旗標不能覆蓋其他發送節點的顯性資料。因此，不能把它在本地偵測到的每個錯誤，視為所有節點都一定會丟棄當前訊框。

如何使用 Kvaser 觀察 CAN 錯誤？

使用支援相關功能的 Kvaser CAN 介面與 CANlib，可在接收資料流程中辨識錯誤事件，並讀取所選介面通道的控制器狀態與錯誤計數資訊。這些資料有助於建立異常時間紀錄，但不會自動提供全網所有節點的內部狀態。

錯誤事件、控制器狀態與電氣波形的分工

CANlib 的三項觀察入口各有不同用途。硬體、韌體、驅動及軟體支援情況應依實際設備確認。

• 錯誤事件：檢查 canRead() 回傳旗標中的 canMSG_ERROR_FRAME，先辨識錯誤事件，再處理一般資料訊框。
• 介面自身狀態：以 canReadStatus() 查看所選通道的 Error Active、Error Passive 或 Bus Off 等狀態。
• 錯誤計數資訊：以 canReadErrorCounters() 取得介面控制器資訊；部分控制器不提供精確計數，可能回傳估計值。

一般錯誤事件的識別碼、DLC 與資料欄位不應當作正常應用訊框解碼，也不能假設它們直接指出故障節點。若要確認振鈴、電壓異常或逐位元邊緣時序，仍需合適的示波器或實體層量測設備。

出現 Error Frame 時的基本檢查順序

先核對網路配置與接收條件，再將錯誤事件和現場條件對照，通常比只反覆更換介面更有診斷價值。

1. 確認協定與位元時序：核對 Classical CAN／CAN FD、位元率、取樣點與 SJW，避免節點設定不一致。
2. 檢查接線與終端：確認 CAN H、CAN L、參考接地與拓樸。對典型高速 CAN 雙端 120 Ω 終端網路，可在斷電且適當隔離條件下檢查約 60 Ω 的等效電阻；其他實體層與拓樸不可直接套用。
3. 確認 ACK 節點與監聽模式：發送端需要其他正確接收且可回覆 ACK 的節點；靜默監聽介面不提供 ACK。
4. 記錄錯誤與自身狀態：將事件時間、狀態及計數變化，與供電、線束操作和設備啟停條件對照。
5. 必要時補電氣波形：針對疑似線材、終端或雜訊問題進行實體層量測，修正後重做相同條件的測試。

常見問題

延伸閱讀與 Kvaser USB to CAN 選型

若需要在支援腳本的設備上進行本地 CAN 處理，可延伸閱讀Kvaser t Script 開發與 CAN 閘道器應用指南。t Script 能力須依型號確認，不是所有 Kvaser 介面都支援。

若想了解資料擷取的實際應用，可參考Kvaser 車輛排放資料擷取案例；該案例用來理解應用情境，不作為錯誤訊框定位能力的證明。