跨越调试物联网设备时的软硬件鸿沟

嵌入式设计中很重要的一部分，并且必须跨越硬件 / 软件之间的鸿沟。在系统级别，嵌入式设计的功能越来越多地由固件定义，因此要避免漏洞，需要具有特定训练的工程师在项目的设计阶段紧密合作。这也意味着在漏洞不可避免地出现时需要抑制互相推诿的冲动。

也许正是由软件定义的硬件之特性，使现代嵌入式设计成为如此有意思的职业。每个新的微控制器（MCU）似乎都提供了更高的集成度和更先进的功能，但是在对其完成编程之前，它完全没有启用。尽管这种集成和配置显然是一个促进因素，并且在为产品设计带来巨大进步，但它有时可能会给工程师带来无法预料的问题。

诸如 MCU 之类的嵌入式元件所提供的功能和可配置特性也在不断提高，并且这些元件提供了许多并非在每个设计中都需要的功能。这些额外的功能可能会被忽略，也较少引起问题。

正如大多数工程师所理解的那样，这些功能通常由可通过软件修改的寄存器控制。因此，它们在开机时具有默认设置，并且如果保持不变，将继续在这些默认设置下运行。在很多情况下，这可能不会带来问题。但是，如果这些功能一直未使用，而且可能未经测试，则可能会以某种无法预料的方式产生影响。漏洞可能在系统中产生，由可能被忽略的常规功能所导致。

查找故障可能会很困难、耗时且成本高昂，即使在理想条件下。通常，我们通过其影响来识别故障，这些影响一般为工程师提供了足够的证据来追踪原因。导致故障的原因与硬件还是软件有关，在很大程度上是无关紧要的，不过这也许仍存在争论，重要的是找到并修复故障。

如果故障原因是未正确初始化的低级功能，那么发现它可能会变得更具挑战性。要了解硬件平台的初始状态如何影响整个设计，就需要对整个系统有更高的了解，而追踪这些难以捉摸的条件会消耗不少资源。

例如，MCU 上的 SPI 总线访问串行闪存，是许多嵌入式系统中使用的相对简单的功能。如果在存储的值中检测到错误，会提示存储（而不是 MCU）出现故障。这是一个客户的经历，当从闪存的状态寄存器连续读取时提示发现了读 / 写错误。自然而然，被认为存储器件发生了故障，这一理论由以下事实得出：如果在状态寄存器读取之间设置了短暂的延迟，则检测到的故障数量似乎会减少。此外，重新启动电源似乎可以清除故障一段时间。

客户工程师们认为，这些症状表明串行存储器发生故障，即使它仍在指定规格的周期极限之内，仅完成了约 60k 的写周期。当客户将串行闪存器件返回给我们进行进一步测试时，即使在执行了超过 300k 的写周期后，我们都没有发现任何故障。

为了找到真正的故障，我们的工程师调查了客户的应用，并探究了 SPI 信号。我们发现，这看起来是存储器件出现故障，实际上是系统噪声问题，可以很容易地纠正。尽管部分原因是由于 MCU 与闪存之间的 PCB 走线阻抗不匹配，但噪声并非完全是由于不良的 PCB 设计或信号完整性问题造成的。

尽管看上去似乎是 PCB 或电路设计问题，但实际上噪声是 SPI 信号的过冲和下冲，这是由于信号的驱动强度过大引起的。该过冲足以影响闪存器件的电荷泵，并导致读取和写入错误。在某些情况下，SPI 信号的过冲和下冲也可以解释为信号跃迁，也可能导致读取或写入错误。

跟踪图像显示了 SPI 线上的过冲和下冲

一种可能的解决方案是在信号走线上放置一个 RC 电路，以减慢信号跃迁的速度。不过，我们发现该设计基于一个相对较新的 MCU，允许在固件中修改 I/O 引脚的驱动强度。降低信号的驱动强度足以消除 SPI 信号线上的过冲和下冲，从而有效地消除系统级噪声源。

这里的重点并不是闪存器件如何努力应对大量的系统噪声，而是 MCU 上的可配置功能可能会引入一些影响，很容易让人误以为是设计中其他器件出现了故障。在这次事例中，我们通过有力的方法检测到了设计中的故障，并通过我们工程师们的努力解决了问题。

或许我们真正可以从中学到的是，看似硬件的故障也许可以通过软件轻松修复。看似某个元件的故障，也许可以追溯到另一个元件中的错误配置。硬件和软件工程师之间的合作关系，以及客户与供应商之间的合作关系应足够牢固，能够承受得住使用最新技术进行设计所面临的挑战。尽管默认设置的初衷是提供帮助，我们也应当对其进行验证，优化这些设置可以极大地改善系统性能和可靠性。