by Ariel Hershkovitz｜CEVA’s Senior Manager of Customer Solutions

在嵌入式系统开发进入初次启动(Bring up)阶段，当一切似乎都不起作用时，偏执狂必然会猜测硬件存在设计缺陷。或许存在控制或定时问题，或者引导装入过程中的某些异常序列是罪魁祸首？项目节点的临近不断加剧精神压力，因为你似乎已成为产品发布的最后一道障碍。这不是应该很容易吗？其他人都认为所有真正的漏洞都在组件测试中被发现并解决了。你的工作应该只是简单的检查，即便发现简单的疏漏也能快速纠正。你为什么要花费这么长的时间来完成工作？

这张汽车“分解图”展示了将许多功能性小部件组装成完整系统时可能的复杂性（来源：CEVA）

我们都曾有过这样的经历。其他人都认为绝大多数漏洞均已被发现并修复，但那些简单的疏漏还是会在不经意间显露出来。也许这只是一次性问题；却已使您痛苦不堪，于是，您就制定程序来避免将来发生问题，对吗？然而，当您进行 SoC初次启动的 软件集成时，需要将新的软件构件装入系统中，并且在该链路中会存在多个链接。

首先，您必须在 PC 上创建构件，然后再将其装入系统闪存中。在闪存中，一个简单的控制器就可以（从专用存储器）装载其本身的简单程序，再通过该程序将引导数据解包并上传到主存储器。然后，控制器可触发主处理器（比如说一个DSP）中的某个特殊引导装入指令，发出信令指示该处理器对主存储器中的数据进行二级解包，并送入位于处理器附近的快速紧耦合存储器 (TCM) 中。

很多步骤和位置都有可能发生简单疏漏，然而，只要你察觉有疏漏时，就会怀疑芯片是否存在问题。

如果你连文件名的输入都不正确，那不就是你自己的错吗？但是微软的“长划线与短划线”问题呢？微软工具有时会在短划线和长划线号之间进行“有益的”自动更正，即使是在复制/粘贴时也是如此，这种情况下你可能会认为自己正在可靠地传送字符串；这是非常容易疏漏的，顺便说一下，这也是我们遇到过的真实问题（如下示例）。实际上传会需要很多文件；这个问题只发生在其中一个文件上，但是它完全断开了引导装入程序。最后，我们将其追溯到了更新控制器软件的程序员。他从固件编程人员那里收到的电子邮件中复制了文件名，而复制/粘贴就产生了这个错误。

仍然说控制器，谁没经历过这种情况？在紧张时刻进行软件更新，跳过了一个文件，恰好是控制器软件的文件。所以这个软件（即引导链路中的第一个链接）已经过期了，它断开了引导装入程序中的其余部分。本人亲自验证，需要花费一段时间才能找到那个问题文件。

或者，考虑使用可添加自定义指令的处理器的情形。这些指令可在设计期间进行调整。或者，设计团队决定在这条线路的某个位置切换到新版本或新型号的处理器。无论出于什么原因，这些更改并不总是完全反映在软件更新中。所以你上传的某些软会编译成操作码后，无法映射到预定的操作，所以无法按预期运行。由于您的软件开发与硬件有些不同步，在模拟中无法检测到这些问题。

根据本人经验，复杂的问题并不多见，即便是会发生，也很难造成基本的“不引导”问题。考虑到整个初次启动包括了从代码汇编、配置、复杂引导序列到最终运行的整个程序这样长的过程，则在某个位置发生一般错误就不足为奇了。在对硬件和软件理解的基础上，为最大限度降低该进程中的意外发生，需要进行严格的配置管理和调试。如果试图回避其中的任何一步 —‘我可以通过一些脚本来管理这个部件，我会弄清板子上的任何问题’— 都会后患无穷。欲深入了解 CEVA 用户如何管理这些问题，敬请阅读系列文章：硬件调试的复杂性。