CAN模組-3

先前的文章中，我們逐步介紹CAN模組的特色，其支援CAN 2.0A（Standard CAN）、CAN 2.0B（Extended CAN）、CAN FD等協議，以及MR2操作介面之CAN通訊相關設定。本文將延伸討論CAN協議之錯誤處理機制，幫助讀者進一步掌握 CAN 協議，並在應用層面能更有效地偵測與排除錯誤。

(圖1) CAN Bus模組之實體圖

CAN Controller具備三種運作狀態，用於表示該節點是否屬於正常運作的CAN裝置，其狀態分別為Error Active、Error Passive與Bus Off，並且搭配兩個錯誤計數器TEC(Transmit Error Counter)與REC(Receive Error Counter)等，動態調整CAN Controller運作狀態。當系統啟動時，節點初始狀態為Error Active，表示該裝置為正常運作的CAN節點，隨著運行過程中的錯誤累積，當TEC或REC大於等於127時，此節點將進入Error Passive狀態，若錯誤持續增加而未改善，最終將進入Bus Off狀態，此時該節點視同從Bus中隔離，不再輸出任何資訊於Bus上，直到重置CAN Controller，或連續收到128次11個Recessive bit時，才會恢復到Error Active狀態，如(圖2)所示。

(圖2) CAN state[1]

無論CAN節點在Bus中擔任發送端或接收端，都會持續監控Bus上的訊號變化，這代表發送端即使在傳遞資料的同時，也會即時檢查自身輸出的正確性。CAN協議定義5種錯誤類型，分別為Bit error、Bit stuffing error、ACK error、Form error與CRC error等，如(表1)所示。當上述錯誤發生時，錯誤計數器將依節點為發送端或接收端有所差異，其常見情況為發送端檢測錯誤時TEC + 8，而接收端檢測錯誤時REC + 1。此設計是基於實務考量，因為發送端相較於接收端更容易發生錯誤，而為了避免發送端進入異常時，意外造成正常運作的接收端進入Bus Off，故讓TEC增加幅度大於REC，此機制能快速隔離有問題的發送端，避免影響通訊。另一方面，當發送端與接收端順利完成一筆封包傳遞時，則會TEC - 1與REC - 1，這種機制允許Bus上出現偶發性錯誤，而不會讓節點過早進入Bus Off，確保系統能持續穩定運作。

(表1) CAN協議之錯誤類型

當CAN節點偵測到錯誤時，會立即發送Error frame以中斷錯誤封包的傳輸，並且Error frame的Error flag，將依偵測錯誤的節點，其所處的狀態而有所差異，該節點若處於Error Active或Error Passive狀態，其Error flag分別為 6 個連續的 Dominant bit 或 Recessive bit，如(圖3)所示。區分Error Active與Error Passive的Error flag，其主要目的是為了避免異常裝置誤判錯誤，進而干擾正常裝置的傳輸。在Bus上有許多CAN節點時，每個節點可能因Propagation delay的影響，導致各節點響應發送Error frame的時機點不同，從Bus的觀察角度下，將會發現Error flag維持超過6個連續的Dominant bit或Recessive bit。

(圖3) Error frame[2]

於本文中，我們聚焦於CAN錯誤處理機制，說明狀態切換如何透過內部錯誤計數器動態調整，並淺談五種錯誤檢測方式，以及CAN節點檢測錯誤時的應對方式。透過這些機制，CAN不僅能快速隔離故障節點，同時也容許發生偶發錯誤，在可靠性與容錯性之間取得平衡，確保整體CAN Bus能持續穩定運作。理解CAN錯誤處理機制，有助於開發人員在實驗過程中，更精準掌握各節點狀態變化，以及分析錯誤來源，並加速問題定位與解決，進一步提升整體CAN系統之穩定性。

凱登將陸續推出MR2軟體特色、電機模型解析、編碼器驗證、各式外掛模組、應用案例等文章，敬請期待。

如有任何問題歡迎請隨時聯繫我們，並給與我們指教。

參考資料

[1].    “CAN,” https://wiki.csie.ncku.edu.tw/embedded/CAN, Retrieved on Oct 2025.

[2].    “CAN Protocol: Your Car’s Secret Language (P3: Error Frame, Overload Frame & Bit Timing).,” https://medium.com/@osazizsg1/can-protocol-your-cars-secret-language-p3-error-frame-overload-frame-bit-timing-d6bb3c7a5441, Retrieved on Oct 2025.