最近遇到一个神奇的现象，在调试一个单KL15的项目，发现接着劳特巴赫调试器，然后拔掉KL15，软件进入了重启Reset函数，没有进入期望的下电SwitchOff函数。

而不接劳特巴赫，拔掉KL15，观测电流，ECU是可以正常下电。

图片

在当前的状态管理中，监测到KL15断开后，SWC会清除唤醒事件POWER，并调用RTE接口将状态切换到POST_RUN，选择的Shutdown Target为ECU_SHUTDOWN_TARGRT_OFF，而不是ECU_SHUTDOWN_TARGRT_RESET。而到了OffPostOS流程的时候，Shutdown Target却变成了RESET。

所以Shutdown Target是在下电流程过程中，被改掉了。给Target变量打写断点，观测什么时候被修改。分析代码后，发现是由于EcuM判断唤醒事件没有被清除，EcuM就把Shutdown Target改成了RESET。而我们在状态管理的SWC明明清除了POWER，这又是咋回事？

那么接下来就要分析什么时候设置的唤醒事件，在EcuM_SetWakeupEvent处打断点，发现在EcuM_Init中，有两次进入EcuM_SetWakeupEvent。

一次是在DriverInitOne里面，手动写死设置了唤醒源事件为POWER。

另一次是根据上一次复位原因，设置本次唤醒源事件。

结合上图，目前项目中第二种这种通过读取复位原因设置本次唤醒事件源的方法是AUTOSAR设计的。那么看来就是在这里设置了不是POWER的源，而状态管理的SWC只清除了POWER源，下电流程中判断到还有唤醒源事件没有清除，就将Shutdown Target改成了RESET。

代码中获取reset reason是直接调用的MCAL的接口，MCAL是读取的SCU_RSTSTAT寄存器，我们直接将寄存器的值发到CAN上做对比。

接劳巴时，寄存器置位 PORST 和 LBTERM，MCAL接口返回MULTIPLE。

不接劳巴时，寄存器置位 LBTERM，MCAL接口返回 LBIST。

再检查BSW工程的EcuM配置，发现目前MULTIPLE原因（MCAL接口返回值）与RESET唤醒源事件（EcuMWakeSources）map，LBIST原因没有与唤醒源事件map。

所以不接劳巴的时候，由于reset reason和wakeup source没有map，第二次EcuM_SetWakeupEvent没有起作用，第一次EcuM_SetWakeupEvent设置了唤醒源事件为POWER。

接劳巴的时候，reset reason和wakeup source有map，第一次设置了POWER，第二次设置了RESET。所以下电的时候，RESET源没有被清除，就走了重启的流程。

那么LBTERM什么？

手册里解释 LBIST was terminated properly，LBTERM位会设置为1。再看手册 3.1.1.7.5 LBIST execution 解释：LBIST是SSW触发执行的逻辑自检，自检完成后，会发生重启，然后进入用户代码。

更改方式：

可以看出，英飞凌LBIST自检完成正常的话，会设置LBTERM，所以按照现在的MCAL接口返回值，要么只有LBTERM，要么就是MULTIPLE。那么在EcuM的配置中MULTIPLE原因不去map唤醒源即可。也就是不使用AUTOSAR设计的根据复位原因设置唤醒源的逻辑，在EcuM_Init中的DriverInitOne完成设置唤醒源事件就好。