跨越调试物联网设备时的软硬件鸿沟
扫描二维码
随时随地手机看文章
不要忽略默认MCU设置
调试是嵌入式设计中很重要的一部分,并且必须跨越硬件/软件之间的鸿沟。在系统级别,嵌入式设计的功能越来越多地由固件定义,因此要避免漏洞,需要具有特定训练的工程师在项目的设计阶段紧密合作。这也意味着在漏洞不可避免地出现时需要抑制互相推诿的冲动。
也许正是由软件定义的硬件之特性,使现代嵌入式设计成为如此有意思的职业。每个新的微控制器(MCU)似乎都提供了更高的集成度和更先进的功能,但是在对其完成编程之前,它完全没有启用。尽管这种集成和配置显然是一个促进因素,并且在为产品设计带来巨大进步,但它有时可能会给工程师带来无法预料的问题。
诸如MCU之类的嵌入式元件所提供的功能和可配置特性也在不断提高,并且这些元件提供了许多并非在每个设计中都需要的功能。这些额外的功能可能会被忽略,也较少引起问题。
正如大多数工程师所理解的那样,这些功能通常由可通过软件修改的寄存器控制。因此,它们在开机时具有默认设置,并且如果保持不变,将继续在这些默认设置下运行。在很多情况下,这可能不会带来问题。但是,如果这些功能一直未使用,而且可能未经测试,则可能会以某种无法预料的方式产生影响。漏洞可能在系统中产生,由可能被忽略的常规功能所导致。
查找故障可能会很困难、耗时且成本高昂,即使在理想条件下。通常,我们通过其影响来识别故障,这些影响一般为工程师提供了足够的证据来追踪原因。导致故障的原因与硬件还是软件有关,在很大程度上是无关紧要的,不过这也许仍存在争论,重要的是找到并修复故障。
如果故障原因是未正确初始化的低级功能,那么发现它可能会变得更具挑战性。要了解硬件平台的初始状态如何影响整个设计,就需要对整个系统有更高的了解,而追踪这些难以捉摸的条件会消耗不少资源。
例如,MCU上的SPI总线访问串行闪存,是许多嵌入式系统中使用的相对简单的功能。如果在存储的值中检测到错误,会提示存储(而不是MCU)出现故障。这是一个客户的经历,当从闪存的状态寄存器连续读取时提示发现了读/写错误。自然而然,被认为存储器件发生了故障,这一理论由以下事实得出:如果在状态寄存器读取之间设置了短暂的延迟,则检测到的故障数量似乎会减少。此外,重新启动电源似乎可以清除故障一段时间。
客户工程师们认为,这些症状表明串行存储器发生故障,即使它仍在指定规格的周期极限之内,仅完成了约60k的写周期。当客户将串行闪存器件返回给我们进行进一步测试时,即使在执行了超过300k的写周期后,我们都没有发现任何故障。
为了找到真正的故障,我们的工程师调查了客户的应用,并探究了SPI信号。我们发现,这看起来是存储器件出现故障,实际上是系统噪声问题,可以很容易地纠正。尽管部分原因是由于MCU与闪存之间的PCB走线阻抗不匹配,但噪声并非完全是由于不良的PCB设计或信号完整性问题造成的。
尽管看上去似乎是PCB或电路设计问题,但实际上噪声是SPI信号的过冲和下冲,这是由于信号的驱动强度过大引起的。该过冲足以影响闪存器件的电荷泵,并导致读取和写入错误。在某些情况下,SPI信号的过冲和下冲也可以解释为信号跃迁,也可能导致读取或写入错误。
跟踪图像显示了SPI线上的过冲和下冲
一种可能的解决方案是在信号走线上放置一个RC电路,以减慢信号跃迁的速度。不过,我们发现该设计基于一个相对较新的MCU,允许在固件中修改I/O引脚的驱动强度。降低信号的驱动强度足以消除SPI信号线上的过冲和下冲,从而有效地消除系统级噪声源。
这里的重点并不是闪存器件如何努力应对大量的系统噪声,而是MCU上的可配置功能可能会引入一些影响,很容易让人误以为是设计中其他器件出现了故障。在这次事例中,我们通过有力的方法检测到了设计中的故障,并通过我们工程师们的努力解决了问题。
或许我们真正可以从中学到的是,看似硬件的故障也许可以通过软件轻松修复。看似某个元件的故障,也许可以追溯到另一个元件中的错误配置。硬件和软件工程师之间的合作关系,以及客户与供应商之间的合作关系应足够牢固,能够承受得住使用最新技术进行设计所面临的挑战。尽管默认设置的初衷是提供帮助,我们也应当对其进行验证,优化这些设置可以极大地改善系统性能和可靠性。