ECU上下电过程CanSM为什么会多次设置CandTrcv和CanController模式

hk4835

前言

经常调试Can通信协议栈的朋友一定会发现在ECU上电过程中即使ECUM检测到有效的唤醒源（Wakeup Event）CanSM也会多次的去设置Can Controller到Stoped, Started状态，设置CanTrcv到Standby, Normal状态。为什么不是一次性设置Controller到Started状态，设置Cantrcv到Normal状态了？

AUTOSAR架构下，ECU的上下电是一个很复杂的过程，需要依赖CanTrcv, Can Controller, CanIf, CanSM, ComM, EcuM, CanNM等模块协同完成，本文着重介绍上电过程中CanSM多次控制Cantrcv和Controller的问题。

注意：本文假设ECU通过Cantrcv的polling模式来设置唤醒事件。

---

注：本文章引用了一些第三方工具和文档，若有侵权，请联系作者删除!

正文

1.Cantrcv设置唤醒事件

ECU被唤醒后，Cantrcv检测到有效的Can唤醒事件会调用EcuM_SetWakeupEvent()设置唤醒事件。



关于唤醒事件的详细介绍，可以参数《AUTOSAR架构下CanTrcv休眠唤醒问题再探》一文。



2.ECUM检验唤醒事件

ECUM发现有Pending的唤醒事件后就会调用EcuM_StartWakeupSources(), 这是一个Callout函数，需要用户自定义，一般在这个函数里面判断是否是Can唤醒源，如果是就调用CanSM_StartWakeupSources(). 同时EcuM在Timer Expired内检验是否收到了有效的唤醒报文（一般判断是否收到了有效的Can NM报文），如果收到了有效的Can NM报文，则认为唤醒校验通过，就会将唤醒源状态切换到ECUM_WKSTATUS_VALIDATED状态，同时调用ComM_EcuM_WakeUpIndication()通知ComM收到了正常的唤醒事件。



3.ComM被动唤醒到FULL COM状态

如果其他条件（CommunicationAllowed == True .e.g.）都满足ComM状态会从COMM_NO_COMUNICATION切换到COMM_FULL_COMUNICATION. 同时会调用CanSM_RequestComMode(COMM_FULL_COMMUNICATION)通知到CanSM模块。



4. CanSM模块上电过程控制

在ComM模块同时会调用CanSM_RequestComMode(COMM_FULL_COMMUNICATION)通知到CanSM模块后CanSM模块状态会从CANSM_BSM_S_PRE_NOCOM切换到CANSM_BSM_S_PRE_FULLCOM状态，随后执行一系列操作后切换到CANSM_BSM_S_FULLCOM状态。

CANSM_BSM_S_PRE_NOCOM和CANSM_BSM_S_PRE_FULLCOM状态都包含各自的子状态，在子状态中会调用CanIf_SetControllerMode()和CanIf_SetTrcvMode()操作CanTrcv和Can Controller.



4.1 CANSM_BSM_S_PRE_NOCOM子状态

在CANSM_BSM_S_PRE_NOCOM状态中会根据是否有PN配置进入到CANSM_BSM_DeinitPnNotSupported状态还是CANSM_BSM_DeinitPnSupported状态，本文基于无PN配置分析。

在CANSM_BSM_DeinitPnNotSupported状态中就会:

1)调用CanIf_SetControllerMode()将Can Controller设置到Stopped状态后再设置到Sleep状态。

2)调用CanIf_SetTrcvMode()将Cantrcv设置到Normal状态后再设置到Standby状态。



注意1：CanSM在设置Controller和Cantrcv模式的时候都会判断是否有正确的Indication回来，如果没有就会超时重试，超时时间和重试次数通过以下图中参数配置。



注意2: CanSM一定合Can Controller绑定，但是可以选着是否绑定CanTrcv，如果没有引用（绑定）Cantrcv, 则CanSM会bypass Cantrcv, 也就是所有对CanTrcv的操作都认为收到了Indication.



4.2 CANSM_BSM_S_PRE_FULLCOM子状态

在CANSM_BSM_S_PRE_FULLCOM状态中就会:

1)调用CanIf_SetControllerMode()将Can Controller设置到Stopped状态后再设置到Normal状态。

2)调用CanIf_SetTrcvMode()将Cantrcv设置到Normal。



5. 总结

通过以上模块的分析可以知道，在ECU上电过程中CanSM会去多次设置Controller和Cantrcv的模式，那么:

问题1：CANSM_BSM_S_PRE_FULLCOM状态中不直接将Controller状态设置到Started而是要先设置到Stopped了？

问题2：CANSM_BSM_DeinitPnNotSupportedProceed状态中不直接将Controller状态设置到Sleep状态而是要先设置到Stopped状态了？

问题3：CANSM_BSM_DeinitPnNotSupportedProceed状态中不直接将Cantrcv状态设置到Standby状态而是要先设置到Normal状态了？

答：如下图所示，因为AUTOSAR的Cantrcv和Controller标准模块已经限制了其状态之间的切换是否可行。





-end-

分享不易，恳请点个【👍】和【在看】

lichengwan

针对您关于ECU上下电过程中CanSM多次设置CandTrcv和CanController模式的问题，以下是专业回复：

在AUTOSAR架构下，ECU上下电过程中，CanSM多次设置CandTrcv和CanController模式是为了确保通信的可靠性和稳定性。上电时，ECU需要确保各个组件处于正确的初始状态，多次设置是为了确保各个模块能够正确响应并初始化。同时，多次设置也有助于检测和处理可能出现的异常情况，如通信故障等。一次性设置可能无法全面考虑各种情况，导致潜在的风险。因此，通过多次设置，系统能够更加稳健地过渡到正常工作状态。

以上仅是简要回答，详细的解释可能涉及更多关于AUTOSAR架构和CAN通信协议栈的专业知识。

针对您关于ECU上下电过程中CanSM多次设置CandTrcv和CanController模式的问题，以下是我的专业回复：

在AUTOSAR架构下，ECU的上下电过程中，CanSM多次设置Can Controller和CanTrcv的状态是为了确保通信的可靠性和稳定性。上电初期，ECU需要确保所有硬件模块都正确初始化并准备好进行通信。多次设置状态是为了确保各个模块都能正确响应并处于预期的工作状态。此外，这种设计也有助于处理可能出现的异常情况，如通信故障或错误。一次性设置可能导致某些模块未能完全准备好或未能正确处理异常情况。因此，这种分阶段设置的方式更有利于保证ECU的通信稳定和可靠。

针对您的疑问，ECU上下电过程中的复杂流程确实需要依赖多个组件协同工作，以确保系统的正常运行。