嵌入式系统的调试技巧

调试与设计一样是嵌入式系统不可或缺的一部分。两者都可以正确地称为同一枚硬币的两个面。考虑到物联网领域嵌入式系统的最新发展，工程师在调试和设计方面同样出色是一个优势。如今，嵌入式系统变得非常复杂，软件和硬件的界限正在融合。因此，当系统级别出现问题时，很难找出根本原因。作为从事嵌入式系统工作的工程师，我们必须快速了解问题并找到根本原因。

下面提到的一些技巧可以帮助开发一种逻辑方法和分析思维来解决嵌入式系统问题。本文不涉及用于调试的工具，而是向读者展示了一种经过验证的方法来解决问题。

嵌入式系统由硬件、固件和应用软件组成。有时，当报告问题时，不清楚系统中存在问题的位置。这可能是由于硬件、固件代码或应用软件造成的。下面是一个通用图，显示了嵌入式系统的基础知识以及从一个系统到另一个系统的数据流方向。

下面列出了有关如何继续调试问题的分步方法。为了说明该方法，我们考虑了在嵌入式系统上看到的视频显示问题的示例。

第 1 步 – 了解设置并正确重现问题

需要做的第一件事就是正确地重现问题。有时问题是在本地看到的，工程师能够轻松地重现问题。而有时问题出现在远程位置或客户站点，然后工程师必须完全依赖可用的日志来了解设置并重现问题。在第二种情况下，工程师正确理解设置非常重要，因为这将有助于成功重现问题。如果工程师没有这样做，那么问题可能会在未来在远程位置或客户站点再次发生。这主要是因为工程师可能没有正确理解问题，因此没有开发出正确的解决方案。因此，它将导致修复问题的多次迭代。

对于我们的示例，让我们考虑仅在某些监视器上看到噪声的视频显示器。由于设备安装在远程位置，因此只有视频日志可用于调试。从日志中很难找出噪音的根本原因。最初我们尝试播放不同的剪辑，但最终无法重现该问题。我们不确定为什么该问题无法重现。我们无法清楚地判断这是由于使用的视频文件还是由于设置。最后，我们能够通过获得与客户使用的完全相同的剪辑和其中一台显示器来重现该问题。

第 2 步 – 将问题分解为更小的问题

一旦问题被正确重现，下一步就是将整个问题分解为更小的问题。这非常重要，可以通过了解整个数据流来完成。第一步是在应用层与固件层以及固件层与硬件层的接口处中断数据流。这样，每一层都可以针对任何问题进行独立审查和测试。此外，我们不必止步于此，可以根据逻辑理解将整个数据流路径分解为更多的子层次。

对于我们的示例，我们将视频帧数据从应用程序到硬件层的整个路径进行了划分。我们了解了如何接收编码的视频数据然后解码的整个路径，然后将其传递到固件层。在这里，我们了解了如何为每个视频帧分配指针，以及固件如何给出它们以通过硬件层发送每个帧。在硬件层，我们了解了视频帧如何在物理线路上发送出去的协议。一旦我们了解了整个路径，我们就将其划分为逻辑块。一个块用于应用层，其中编码的视频数据被解码为原始视频并存储在视频缓冲区中。然后另一个块是固件层，我们检查视频缓冲区是如何分配给硬件的。

第 3 步 - 修复每个较小的问题

一旦我们将整个数据路径分解为每一层的逻辑块，我们需要单独测试每个块并以各自的方式对其进行验证。这将有助于找到问题的根本原因所在。有时系统问题可以通过仅更改一层来解决，而有时则需要更改不止一层。通过在逻辑上打破整条路径，我们可以正确地找出需要所有更改的地方，然后相应地修复它们。

对于我们的示例，在应用层，我们使用读取和写入文件来验证数据路径流。将解码后生成的视频数据缓冲区与预期值进行比较。在固件级别，使用固定模式作为数据输入，而不是来自应用层的数据。在这里，我们观察到视频数据以场而非帧的形式提供给固件层，但场信息（顶部或底部）未正确地从应用层提供给固件层。所以我们必须相应地修改代码，以便缓冲区包含正确的字段信息。

在硬件级别，这些固定模式和接口的相应控制信号使用逻辑分析仪按照规范进行了验证。对于我们的示例，我们使用的协议是 BT.1120，我们看到协议时序不符合规范。所以我们意识到这就是为什么有些显示器可以正常工作而其他显示器不能正常工作的原因。一旦我们按照规范制定了协议，我们就会看到所有监视器都正常工作。我们还意识到，整个噪声问题实际上是错误的字段信息和错误的协议时序的组合。这就是为什么一些显示器能够工作而其他显示器不能工作的原因。

第 4 步 - 负面测试

测试当然是解决问题的一个非常重要的方面，重要的是测试问题是否已正确修复并且不应该再次出现。因此，重要的是我们在解决问题后进行负面测试以及通常的测试。负面测试基本上意味着确保问题被强制进入系统，然后根据设计的解决方案验证系统的响应。这基本上意味着，如果我们通过提供正确的输入从系统中得到错误的输出并且我们想出了一个解决方案，那么我们应该能够生成错误的输入并馈送到系统，以便它生成正确的输出. 如果发生这种情况，则意味着正确识别了根本原因并验证了修复。

对于我们的示例，我们测试了以下方式。对于协议时序，我们看到在按照规范制作之后，所有的监视器都出现了噪音问题。即使对规范稍作修改，也会导致监视器的行为发生变化。这证实了硬件层错误的协议时序是监视器行为不同的根本原因。接下来，对于我们看到问题的监视器，我们有意交换了应用层的顶部和底部字段。然后我们看到问题没有发生。这证实了不正确的顶部和底部字段指针是噪声问题的根本原因。通过这种方式，我们测试了该解决方案实际上解决了根本原因，并且它在应用程序和硬件层都包含了一个修复程序。

通过使用上述步骤，可以以更好的方式解决任何问题。