Application跳转Bootloader，如何处理外狗？

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

提到“看门狗”（WatchDog），我们自然就和功能安全挂上钩。或者说，看门狗属于功能安全的范围，当系统因故障（eg：程序死循环、硬件异常等）导致“卡死”时，看门狗主动触发复位（Reset）或安全响应机制，强制系统恢复至可控状态。如果细分看门狗，又可分为内狗和外狗，示意如下：

对于一块芯片，在软件设计之初，会考虑不同进程之间的内存划分。这里的进程包括：信息安全的Bootloader（如果需求要求）、信息安全的Application（如果需求要求）、用户Bootloader、用户Application等进程。假设：仅考虑用户Bootloader、用户Application进程，在上电（PowerOn）或者复位（Reset）过程中，会涉及到两个进程间的跳转问题，示意如下：

如此，会引伸出一个工程关注的问题：在软件升级的过程中，即：Application跳转Bootloader的过程中，外部看门狗应该如何处理？为什么需要关心这个问题？由于外部看门狗独立于uC，在Application和Bootloader中均需要独立操作，如果处理不当，可能会引发Bug问题，比如：软件升级过程中，Application跳转Bootloader，没有及时“喂狗”，导致程序复位，软件更新失败。

Application跳转Bootloader过程中，该如何处理外狗呢？或者说，怎样操作外狗，避免复位等异常工况呢？

这里，以小伙伴的问题为起点：“需要通过SPI喂外狗，在boot中，使用异步SPI喂狗还是使用同步SPI喂狗，如何使用同步方式，是否会引起诊断报文的中断处理与喂狗操作的相互干扰？如果使用异步SPI喂狗，是否需要通过Polling（轮询）或者中断方式确认喂狗成功？”

Q1：在boot中，使用异步SPI喂狗还是同步SPI喂狗？

A1：个人理解，不管使用异步还是使用同步处理，区别在于获取请求结果的快慢。同步就是请求发送以后，“死等”请求的状态。异步不是死等请求的结果，可以注册一个回调函数（callback），当请求处理完成后，请求的结果由注册的回调函数通知。如果没有注册回调函数，可以通过模块的主函数，Polling请求的结果。所以，使用同步还是异步，没有优劣之分，具体使用哪种方式，需要结合实际的项目评估，因为每个项目的背景和特点不同，不能一概而论。

Q2：使用同步方式，是否会引起诊断报文的中断处理与喂狗操作的相互干扰？

A2：细化一下问题，在Boot中，诊断报文的接收采用中断模式，且使用同步SPI方式喂狗，是否会引发潜在问题？这里的诊断报文（假设为CAN报文），按照描述，可以理解为：诊断报文采用中断模式接收。所以，CAN和SPI本就属于两种不同的硬件单元，不管使用中断、轮询或者同步、异步。两者之间不应产生干扰，当然，特定的工程场景，问题千变万化，不能一概而论。进一步理解，使用SPI同步喂狗的过程中，是否会被CAN的中断打断。如果SPI同步喂狗过程中被中断打断会带来什么影响？

假设SPI在发送喂狗指令的过程中，被中断打断，可能导致喂狗失败。所以，引伸注意点就是，SPI同步喂狗的过程中，可以使用临界区保护，避免SPI同步喂狗的过程被打断。

Q3：如果使用异步SPI喂狗，是否需要通过Polling（轮询）或者中断方式确认喂狗成功？

A3：使用异步SPI喂狗，如果没有注册callback中断通知请求结果。那么，通过Polling获取喂狗请求结果是必要的。

Q4：Application跳转Bootloader过程中，Boot怎么知道什么时间喂狗，跳转Bootloader前，必须先关闭外狗吗？

A4：在软件升级的过程中，eg：进入拓展会话。程序需要从Application跳转Bootloader。这个过程会涉及外狗处理的问题，即：如何喂狗。策略有如下几种：

1. 如果喂狗周期（假设是窗口看门狗）在Application下，可以延长喂狗周期，即：增大喂狗窗口。可以在进入Bootloader程序前，增大喂狗窗口，避免程序跳转时间过长导致外狗触发复位；

2. 如果功能安全不强制约束，可以在进入Bootloader程序前关闭外部看门狗，进入Bootloader后，重新使能外部看门狗。如果功能安全不允许关闭外部看门狗，此方案不可行。

3. ......

Q5：Flash操作与喂狗操作

A5：在Boot中，尤其Flash操作过程中，喂狗是一个需要格外注意的问题。怎么理解呢？在刷写的过程中，会涉及到Flash的擦除和写入动作。Flash的最小擦除单位是Logical Sector，擦除和写入（最小写操作单位Page）需要一定的时间。所以，临近喂狗时间，如果Flash占用时间长，没有及时喂狗就会导致复位。