Busoff后的快/慢恢复机制

尾音╮ 发表于 2023-3-3 12:33:54 | 显示全部楼层 |阅读模式 对于Busoff的会商，以前有写过，能够参照前文CAN通信：Busoff目前，为何要等候128次持续11个隐性位？、Autosar开辟：CanSM模块怎样处置Busoff？等文章。可是，那个成就仍然会搅扰许多同学，原文，对于Busoff的快/缓规复体制再截至一个弥补会商。睁开会商以前，再次分析：CAN节面发作busoff，是因为TEC（Transmit Error Counter）＞255。总线上有毛病帧，分析网段内乱有节面识别到总线毛病，处于主动大概主动 毛病形状的节面会中收主动大概主动 毛病帧。可是，那其实不表示着毛病帧会使患上一般节面也加入busoff形状，因为，那些节面不过支到其余节面收收的毛病帧，领受毛病，会使患上REC（Receive Error Counter）乏减，可是REC最年夜只可即是128，其实不会使领受毛病帧的节面加入busoff形状，至多只可加入Error Passive形状。节面加入busoff形状，必然是因为节面自己识别到自己收收毛病，TEC年夜于255招致的。 一、busoff规复体制 11898-1标准中，划定：当节面busoff目前，最少要等候持续128个11 bit隐性位，以下所示： 假定，使用500Kbps的典范CAN帧，1 bit = 2µs，缺陷节面从头到场通信的最快时间 = 128 * 11 * 2 = 2816µs = 2.816ms。那取咱们工程中罕见的快/缓规复需要时间有些差别，那又是为何呢？ 二、工程快/缓规复时间请求 好比：工程中请求，节面busoff目前，快规复时间10ms，缓规复时间1000ms。第一小节中，计较busoff节面从头到场通信的最快时间= 2.816ms，也即是道，刚巧此时间范畴内乱，共网段内乱的其余节面没有需要使用总线。理论的工程中，该工况呈现的可以性比力高，一个网段内乱，一般会有多个节面，组成的通信矩阵会比力庞大，以是，一般通信过程当中，远3ms的时间不节面使用总线的几率比力高。以是，每一野OEM，会按照自野的EE架构，设想busoff的快/缓规复时间，尽可以天使总线通信颠簸。以是，当有节面发作busoff时，为了避免滋扰共网段内乱的其余节面通信，缺陷节面不该过快天到场通信。先让缺陷节面截至一个快规复，如许，因为奇收滋扰招致的节面缺陷能够快速规复，从头到场通信。假设缺陷节面颠末了几回快规复，依旧不规复一般通信，为了尽可以天低落对于共网段其余节面的通信滋扰，可让缺陷节面加入缓规复，即：让缺陷节面没有要过快天参加总线，低落其对于总线的滋扰。以是，那即是工程中提出快/缓规复体制的启事。 （一）busoff取DTC 节面busoff，是一种缺陷举动，正在满意必然次数后，需要记载对于应的DTC，以就于车辆成就排查战培修。工程理论中，很少一次busoff便上报Busoff DTC，一般来讲，需要持续屡次busoff（eg：10次），才截至Busoff DTC处置。 （两）busoff处置 Autosar中，CanSM_ControllerBusOff()交心由CanIf挪用，见告CanSM对于应节面Busoff发生，以后，截至busoff的规复处置体制。关于规复体制的处置，可以果Autosar硬件供给商的差别，代码上会有所差别。好比：有些供给商，会颠末设置选项（一般正在CanSM_Cfg.h文献）增加busoff处置前/后callout，对于应的宏以下所示： #define CANSM_BUSOFF_BEGIN_INDICATION         STD_ON #define CANSM_BUSOFF_END_INDICATION           STD_ON 复造代码 云云设置目前，便可截至节面busoff前/后的自界说处置。BusOff Begin处置暗示以下所示： #if ( CANSM_BUSOFF_BEGIN_INDICATION == STD_ON )   (*CanSM_CurrentChannelVarPtr).CanSM_TxOnlineDelayTime = 0;   (*CanSM_BusOffBeginIndicationFctPtr)( CanSM_GetNetworkHandleOfChannelConfig( CanSM_CanNetworkIdx ), &( (*CanSM_CurrentChannelVarPtr ).CanSM_TxOnlineDelayTime ) ); #endif 复造代码 既然有callout，法式员处置busoff便有了很年夜操纵性。 （三）Flexray、Lin Busoff理论的名目中，各人可以听过Flexray Busoff战Lin Busoff的道法，相对CAN总线，Flexray战Lin并无真实意思上的busoff形状，不过对于应controller毛病形状的一种嚷法，留神辨别。 奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫 存眷微疑公家号“高兴因 Need Car”，共同会商Autosar开辟中碰到的这些“坑”！ 奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫奸淫 朝期出色回忆 Autosar朝期出色文章汇总：1~70 Autosar朝期出色文章汇总：71~100 Autosar朝期出色文章汇总：101~150 Autosar朝期出色文章汇总：151~200 启源Fast-DDS装置示例及DDS模子架构 DDS概括及DCPS模子 鉴于CMake，穿插编译C、C++ TRACE32：多核调试设置 Autosar EcuM：APP由RUN到POST_RUN浅析 Autosar收集办理：再道CAN FD帧可否叫醒收集？ 嵌进式开辟：TLF35584中狗之WWD 嵌进式开辟：怎样理解ECU叫醒、戚眠、Reset? C语言根底：do{...}while(0)的使用，很秀 Autosar EcuM：ECU的启用、封闭过程 嵌进式开辟：使能Cached功用，招致数据不合性破坏

回复 使用道具 举报 提升卡 置顶卡 沉默卡 喧嚣卡 变色卡 千斤顶 照妖镜