一、前言

在汽車電子、工業(yè)自動化等眾多領(lǐng)域，CAN 總線作為一種可靠的通信協(xié)議被廣泛應(yīng)用。而 AS32S601 芯片憑借其卓越的性能和可靠性，在這些領(lǐng)域也發(fā)揮著重要作用。其中，CAN Bus Off 功能作為 CAN 總線通信中的關(guān)鍵錯誤處理機制，對于保障整個通信網(wǎng)絡(luò)的穩(wěn)定性具有重要意義。

二、CAN Bus Off 功能詳解

（一）定義與作用

CAN Bus Off（總線關(guān)閉）是指 CAN 節(jié)點因發(fā)送錯誤幀過多，超出設(shè)定數(shù)量后，被總線 “關(guān)閉” 進入 Bus Off 狀態(tài)。此時節(jié)點無法收發(fā)消息，直至被重置或自動恢復(fù)。其主要作用是防止故障節(jié)點持續(xù)干擾總線通信，確保其他正常節(jié)點能繼續(xù)工作。

（二）錯誤狀態(tài)分類

1. 主動錯誤狀態(tài)（Error Active） ：節(jié)點正常參與通信時的狀態(tài)。檢測到錯誤會發(fā)送主動錯誤標志（連續(xù) 6 個顯性位），強制中斷當前總線報文傳輸。
2. 被動錯誤狀態(tài)（Error Passive） ：節(jié)點發(fā)送或接收錯誤計數(shù)器超過 127 時進入。此狀態(tài)下節(jié)點雖能通信，但發(fā)送錯誤標志時用被動錯誤標志（連續(xù) 6 個隱性位），不會強制中斷總線報文傳輸。
3. 總線關(guān)閉狀態(tài)（Bus Off） ：最嚴重錯誤狀態(tài)，節(jié)點發(fā)送錯誤計數(shù)器（TEC）超過 255 時觸發(fā)。節(jié)點完全脫離總線，不能收發(fā)報文。

:

Bus Off機制的設(shè)計目的是為了避免某個設(shè)備因為自身原因（例如硬件損壞）導(dǎo)致無法正確收發(fā)報文而不斷破壞總線的數(shù)據(jù)幀，從而影響其他正常節(jié)點通信。

三、Bus Off 產(chǎn)生原因與觸發(fā)條件

（一）產(chǎn)生原因

1. 物理層故障 ：如 CAN_H/CAN_L 線路開路或短路（包括對電源或地短路）、終端電阻缺失、接地不良等，會影響信號傳輸?shù)耐暾院涂煽啃?，進而導(dǎo)致 CAN 節(jié)點出現(xiàn)錯誤幀。
2. 信號干擾 ：強電磁干擾、強電流干擾會破壞 CAN 總線上傳輸?shù)男盘枺构?jié)點接收到錯誤的報文，從而引發(fā)錯誤計數(shù)器增加。
3. 節(jié)點故障 ：CAN 控制器或收發(fā)器硬件損壞、軟件邏輯錯誤導(dǎo)致持續(xù)發(fā)送錯誤幀，會使節(jié)點自身發(fā)送錯誤幀數(shù)量迅速上升，最終觸發(fā) Bus Off 狀態(tài)。
4. 總線負載過高 ：CAN 總線負載率長期接近或超過理論上限（如 >70%），會導(dǎo)致報文無法及時發(fā)送，節(jié)點重試次數(shù)增加，錯誤計數(shù)累積。

（二）觸發(fā)機制

基于 CAN 協(xié)議定義的錯誤計數(shù)器機制，主要包括發(fā)送錯誤計數(shù)器（TEC）和接收錯誤計數(shù)器（REC）。當 TEC 超過閾值（通常為 255）時，節(jié)點進入 Bus Off 狀態(tài)。錯誤計數(shù)規(guī)則如下：

• 發(fā)送錯誤時：TEC + 8
• 接收錯誤時：REC + 1
• 成功發(fā)送后：TEC - 1（最低降至 0）
• 成功接收后：REC - 1（最低降至 0）

狀態(tài)轉(zhuǎn)換路徑依次為主動錯誤狀態(tài) → 被動錯誤狀態(tài) → 總線關(guān)閉狀態(tài)。

四、Bus Off 的檢測與解決測試

（一）檢測方法

1. 錯誤計數(shù)器監(jiān)控 ：通過監(jiān)控 TEC 和 REC 值預(yù)測節(jié)點狀態(tài)變化。當 TEC > 127 時進入被動錯誤狀態(tài)；TEC > 255 時進入 Bus Off 狀態(tài)。可使用如下代碼監(jiān)控并打印 TEC 計數(shù)：

/*------監(jiān)控并打印TEC計數(shù)------*/

Printf("TEC: 0x%x ！rn", CANFD3- >ECR & CANFD_ECR_TEC);

Printf("ESTAT: 0x%xrn", CANFD3- >SR & CANFD_SR_ESTAT);

** 2.狀態(tài)寄存器查詢** ：在錯誤中斷處理邏輯中查詢 CAN 控制器的狀態(tài)寄存器相應(yīng)位。示例代碼如下：

PLIC_InitTypeDef PLIC_InitStructure;

CANFD_ITConfig(CANFD3, CANFD_IT_EBSOFF, ENABLE);//打開BUSOFF中斷

/*

* Function: CANFD3_IRQ_Handler
* Description: CANFD3 interrupt handler function.
* Param: None.
* Return: None.

*/

**void** CANFD3_IRQ_Handler()

{

**if** (CANFD_GetITStatus(CANFD3, CANFD_FLAG_BSOFF) != RESET)

{

Printf("BusOff!rn");

/* Clear the interrupt pending bits */

CANFD_ClearITPendingBit(CANFD3, CANFD_CLEAR_BSOFF);

}

}

（二）解決方案

1. 自動恢復(fù) ：若支持自動恢復(fù)功能（auto bus on），可使用以下代碼開啟：

/*------打開BUS-OFF自動回復(fù)功能------*/

CANFD_AutoBusOffRecoConfig(CANFD3,ENABLE);

2.手動恢復(fù) ：需重置 CAN 控制器或重新初始化 CAN 節(jié)點。讓 CAN 進入初始化模式，再進入正常工作模式。示例代碼如下：

/*------打開BUS-OFF自動回復(fù)功能------*/

**if** (key3_flag)

{

key3_flag = 0;

CANFD_SetBusOff_Recovery(CANFD3);

Printf("The key3 pressed，BUS-OFF Recovery!rn");

}

3.快慢恢復(fù)策略

：快恢復(fù)適用于臨時性錯誤，短時間內(nèi)（如 50ms）嘗試恢復(fù)；慢恢復(fù)適用于較長時間（如 1s）后恢復(fù)，避免頻繁錯誤影響系統(tǒng)。代碼示例如下：

/*------BUS-OFF慢恢復(fù)-快恢復(fù)策略------*/

**if** （Quick_Recovery_Flag < 5）

{

**if** (time50_flag)

{

time50_flag = 0;

Quick_Recovery_Flag++;

CANFD_SetBusOff_Recovery(CANFD3);

Printf("50ms BUS 0FF Quick Recovery!rn");

}

}

**if** (Slow_Recovery_Flag < 3)

{

**if** (time1000_flag)

{

time1000_flag= 0;

Slow_Recovery_Flag++;

CANFD_SetBusOff_Recovery(CANFD3);

Printf("1000ms BUS 0FF Slow Recovery!rn");

}

}

五、Bus Off 的影響與后果

（一）對節(jié)點的影響

1. 通信能力喪失 ：節(jié)點無法發(fā)送報文或應(yīng)答總線上的報文，也不能對總線產(chǎn)生任何影響，但部分實現(xiàn)下仍可接收總線上的數(shù)據(jù)。
2. 功能限制 ：雖然 ECU 節(jié)點從總線脫離，但 ECU 依然正常運行，所有任務(wù)仍被操作系統(tǒng)調(diào)度。

（二）對系統(tǒng)的影響

1. 保護機制 ：防止故障節(jié)點不斷發(fā)送錯誤幀，影響整個網(wǎng)絡(luò)的通信質(zhì)量，確保其他正常節(jié)點可以繼續(xù)通信。
2. 潛在風險 ：若關(guān)鍵節(jié)點進入 Bus Off 且無法恢復(fù)，可能導(dǎo)致系統(tǒng)功能降級或失效，在安全關(guān)鍵系統(tǒng)中可能引發(fā)更嚴重的后果。

總結(jié)

CAN Bus Off 功能作為 CAN 總線通信中的重要錯誤處理機制，在 AS32S601 芯片中得到了良好的支持和實現(xiàn)。通過深入了解其原理、產(chǎn)生原因、觸發(fā)條件以及檢測和恢復(fù)方法，我們能夠更好地應(yīng)對 CAN 總線通信中可能出現(xiàn)的問題，提高系統(tǒng)的可靠性。在實際應(yīng)用中，應(yīng)根據(jù)系統(tǒng)需求選擇合適的檢測和恢復(fù)策略，平衡系統(tǒng)可靠性和響應(yīng)速度。

審核編輯 黃宇