前言
经常调试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的上下及休眠唤醒问题可以参考以下文章:
ECU系统休眠后通过诊断报文唤醒ECU且唤醒网络后快发NM报文
ECU系统休眠后通过诊断报文唤醒ECU且唤醒网络
AUTOSAR架构下CanTrcv休眠唤醒问题再探
AUTOSAR 架构下EcuM唤醒源事件详解
注意:本文假设ECU通过Cantrcv的polling模式来设置唤醒事件。
注:本文章引用了一些第三方工具和文档,若有侵权,请联系作者删除!
正文
ECU被唤醒后,Cantrcv检测到有效的Can唤醒事件会调用EcuM_SetWakeupEvent()设置唤醒事件。
关于唤醒事件的详细介绍,可以参数《AUTOSAR架构下CanTrcv休眠唤醒问题再探》一文。
ECUM发现有Pending的唤醒事件后就会调用EcuM_StartWakeupSources(), 这是一个Callout函数,需要用户自定义,一般在这个函数里面判断是否是Can唤醒源,如果是就调用CanSM_StartWakeupSources(). 同时EcuM在Timer Expired内检验是否收到了有效的唤醒报文(一般判断是否收到了有效的Can NM报文),如果收到了有效的Can NM报文,则认为唤醒校验通过,就会将唤醒源状态切换到ECUM_WKSTATUS_VALIDATED状态,同时调用ComM_EcuM_WakeUpIndication()通知ComM收到了正常的唤醒事件。
如果其他条件(CommunicationAllowed == True .e.g.)都满足ComM状态会从COMM_NO_COMUNICATION切换到COMM_FULL_COMUNICATION. 同时会调用CanSM_RequestComMode(COMM_FULL_COMMUNICATION)通知到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.
在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.
在CANSM_BSM_S_PRE_FULLCOM状态中就会:
1)调用CanIf_SetControllerMode()将Can Controller设置到Stopped状态后再设置到Normal状态。
2)调用CanIf_SetTrcvMode()将Cantrcv设置到Normal。
通过以上模块的分析可以知道,在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
「汽车电子嵌入式在CSDN上同步推出AUTOSAR精进之路专栏,本专栏每个模块完全按实际项目中开发及维护过程来详细介绍。模块核心概念介绍、实际需求描述、实际工程配置、特殊需求介绍及背后原理、实际工程使用经验总结。目的是让读者看完每一个章节后能理解原理后根据需求完成一个模块的配置或者解决一个问题。」
点击文章最后左下角的阅读原文可以获取更多信息
或者复制如下链接到浏览器获取更多信息
https://blog.csdn.net/qq_36056498/article/details/132125693
文末福利
2.为便于技术交流,创建了汽车电子嵌入式技术交流群,可尽情探讨AP,CP,DDS,SOME/IP等前沿热点话题,后台回复“加群”即可加入;
注:本文引用了一些第三方工具和文档,若有侵权,请联系作者删除!
推荐阅读
汽车电子嵌入式精彩文章汇总第一期:20210530-20230703
汽车电子嵌入式精彩文章汇总第2期
TC3xx芯片GTM模块-CMU,CCM,TBU详解
TC3xx芯片GTM模块-TOM详解
AUTOSAR架构下PWM模块配置实践
TC3xx芯片GTM模块-TIM详解
AUTOSAR架构下ICU模块配置实践
TC3xx芯片电源管理系统PMS详解
TC3xx DMA模块详解
TC3xx芯片SMU模块详解
如何监控TC3xx芯片PFlash的ECC错误
TC3xx芯片RAM的错误检测
TC3xx芯片的总线内存保护
AUTOSAR架构下MCAL Modules软件分区问题分析
AUTOSAR架构下内部看门狗复位检测
TC3xx芯片时钟监控
TC3xx芯片电压监控和温度监控
嵌入式基础:环形缓冲区ring buffer
AUTOSAR架构下ECU休眠唤醒Wakeup Time详解
【OS】AUTOSAR架构下的中断和异常向量表
【OS】AUTOSAR Os是如何启动第一个Task的
【OS】AUTOSAR OS如何实现Task抢占
【OS】AUTOSAR OS系统调用产生Trap的过程详解
【OS】AUTOSAR OS调度器实现原理
【OS】AUTOSAR OS Resource实现原理
编译链接专题第1篇-make和makefile介绍
编译链接专题第2篇-初识makefile结构
编译链接专题第3篇-初识makefile中的伪目标
编译链接专题第4篇-变量和变量的不同赋值方式
编译链接专题第5篇-预定义变量的使用
编译链接专题第6篇-变量的高级主题(上)
编译链接专题第7篇-变量的高级主题(下)
编译链接专题第8篇-条件判断语句
End
欢迎点赞,关注,转发,在看,您的每一次鼓励,都是我最大的动力!
汽车电子嵌入式
微信扫描二维码,关注我的公众号