【Autosar Can网络远程唤醒】

关于Tja1043

网络上关于Tja1043芯片资源和工作特性的文章有很多，可以参考下面的博客
链接:https://blog.youkuaiyun.com/qq_42357877/article/details/128567660

关于网络管理

网络管理有一套状态机，搞清楚每个状态的意义，进入和跳出的条件，网络管理就清楚了。

网络上关于Autosar网络管理机制的文章也很多，个人觉得官方英文文档，每个人都会有自己的理解，之后通过汉语表达出来，很多时候都不能精准的表达出英文原文的意思，所以在这里就不把网络管理那一套机制再搬到这里，建议大家还是要去看去看Autosar的官方文档，不理解的地方再参考网络上大家的解读文章，没时间没精力的也可以参考下面的博客：
链接：https://blog.youkuaiyun.com/weixin_42967006/article/details/121715270

关于CAN总线状态管理

Can总线的控制流由CanSM和ComM完成，CanSM的状态跳转如下：

基于Tja1043实现唤醒

唤醒

硬件唤醒序列

唤醒的第一步是唤醒芯片，那么我们的芯片是如何被唤醒的呢？
这首先需要硬件的配合，根据1043的特性，当1043进入sleep模式之后，检测到总线上有符合唤醒条件的唤醒序列，就会进入standby模式同时INH脚被拉高，硬件需要再设计电路时，保证[1]1043常供电，能够随时检测总线电平变化；[2]将1043的INH脚与SBC（电源芯片）的唤醒脚连在一起，这样1043在检测到总线上的唤醒之后进入Standby模式拉高INH就会唤醒SBC，SBC给主芯片供电，主芯片上电。当然，唤醒也可以有别的实现方式，我目前还没接触过。
主芯片上电之后由软件接管，软件开始初始化，执行软件唤醒序列。

软件唤醒序列

软件唤醒不仅仅设计到网络管理，还有BswM，EcuM等模式管理。

芯片上电之后，从main开始运行，初始化EcuM，BswM等底层模块，打开OS，开始运行周期Task等等。周期任务开始运行之后，CanTrcv的MainFunction开始被周期调度，在这个周期函数中，需要周期检测Trcv是否有唤醒标志，检测到唤醒Flag之后，调度EcuM_CheckWakeup函数通知到EcuM。

随后，EcuM_CheckWakeup再调度CanIf_CheckWakeup，CanIf_Checkup再调度CanTrcv_CheckWakeup,在CanTrcv_CheckWakeup调度EcuM_SetWakeupEvents通知到EcuM。
随后EcuM开始Wakeup Validation(找不到比较好的翻译，就直接用英文吧），CAN Wakeup Validation如下：

EcuM_Mainfunction需要周期处理唤醒事件，在被CanTrcv唤醒并走前前面提到的流程后，会满足调度EcuM_StartWakeupSources的条件，EcuM_StartWakeupSources需要用户自己实现，如果传入的wakeupSource是配置的Can唤醒相关的唤醒，则调度CanSM如下图：示例的项目中有两路CAN能唤醒

在CanSM的官方文档中，调度CanSM_StartWakeupSources会触发CanSm发生CANSM_BSWM_S_NOCOM到CANSM_BSWM_WUVALIDTION的转变，如下图：

这个状态改变将会打开CanController和CanTrcv进入normal，此时trcv和controller具备了收发CAN报文的能力，但是CAN报文只能传递到CanIf，因为再往上需要打开相应的PDU组。此时，若收到报文，CanIf层的RxIndication函数会设置一个NewMessageRx的标志，此标志在EcuM_CheckValid会用到。
EcuM_CheckValidation与EcuM_StartWakeupSources一样，满足条件时会被周期调度，同样也需要用户自己实现：

EcuM_CheckValidation会调度CanIf_CheckValidation，在CanIf_CheckValidation函数中如果NewMessageRx标志如果被置位则调度EcuM_ValidateWakeupEvent。在EcuM_ValidateWakeupEvent函数中，通过一些检查，满足条件后会调度ComM_EcuM_WakeUpIndication函数里面做一些判断，满足条件之后调度Nm_PassiveStartUp。Nm_PassiveStartUp调度之后由网络管理接管。

网络管理

Nm_PassiveStartUp会调度CanNm_PassiveStartup，CanNm_PassiveStartup的调度将会使网络管理的状态由BusSleep模式跳转到RepeatMessage状态，这个状态的转换会调度CanSM_RequestComMode请求COMM_FULL_COMMUNICATION，这个请求会触发CanSM的状态由CANSM_BSWM_WUVALIDTION到CANSM_BSWM_S_PREFULLCOM的转变，之后进入到CANSM_BSWM_S_FULLCOM，同时ComM的状态进入到COMM_FULL_COMMUNICATION.

RepeatMessage的时间结束之后进入到ReadySleep状态（期间一直没有主动请求），如果总线上一直有NM报文的接收会一直停留在该状态,同时也使ComM的通信状态维持在COMM_FULL_COMMUNICATION。

应用报文的发送/接收的打开与关闭

Com层报文的发送和接收的开启需要同时满足的条件有2个[1].Com Stack的状态处在COMM_FULL_COMMUNICATION，[2].对应的PDU Group打开。以上我们完成了ComM的状态从COMM_NO_COMMUNICATION到COMM_FULL_COMMUNICATION的转变，Com Stack具备了通信能力，Com层接收报文和发送报文还需要打开对应的Group。在不具备PN功能的网络中，通常将一个Channel的Rx分为一组，Tx分为一组（分组在Com层的配置中完成），Rx Group的打开一般在ComM不处于COMM_NO_COMMUNICATION，否则关闭；Tx Group的打开一般在对应Channel进入COMM_FULL_COMMUNICATION时打开，否则保持关闭，一般这项工作是通过BswM中配置Rule完成的。
BswM如何实现PDU Group的控制下次有机会在详细写。