调试微处理器答案

【问题标题】：Debugging a micro-processor调试微处理器
【发布时间】：2012-12-22 22:41:35
【问题描述】：

我们的协处理器之一是 8 位微处理器。它的主要作用是控制处理闪存的硬件。我们怀疑它运行的代码效率非常低，因为我们在读取/写入闪存时测量了低速。问题是，我们只有一个连接到主 CPU 的 J-TAG 端口，因此无法调试它。我们所拥有的是一个可从 CPU 获得的寄存器，其中包含微处理器的程序计数器。坏消息是，微处理器的工作频率与 CPU 不同，因此在外部监控它的程序计数器也很困难。测量微处理器内部的时间也非常困难，因为它的寄存器只有 8 位长。不用说，代码是汇编代码并且非常复杂。您将如何解决这个问题？

【问题讨论】：

不完全确定你在这里问什么。有什么问题？您希望能够调试微处理器吗？
如果你只是想看看微机在做什么，连接逻辑分析仪？
@JasonD 我们使用了示波器并看到了延迟。我们只是无法确定谁应该负责——我们的 RAM 或代码，甚至可能是闪存。
写入 flash 很慢，期间。弄清楚是否有任何超出此范围的内容。根据您使用的命令组合，可以使某些闪存更快地运行（但在其他供应商的可比部分上，相同的组合可能会更慢）。软件速度与部件上块之间的缓慢有关，并且您的 8 位微可能无法比现在更快或更高效。最简单的闪存优化是不写入 0xFF，添加一些代码来检查写入周期的所有内容并跳过该周期。优化变得依赖于数据。
不知道为什么您需要一个仅用于闪存的协处理器，但您也可能会浪费大量时间用于主 CPU 和该 8 位协处理器之间的通信。

标签： debugging embedded microcontroller jtag

【解决方案1】：

不用说，代码是汇编代码并且非常复杂。您将如何解决这个问题？

我建议您从（或生成）这部分的需求规范开始，然后用 C 语言重新实现代码（甚至仔细使用 C++ 子集）。如果您认为“复杂性”只是代码而不是需求，那么设计出来是个好主意 - 它只会使将来的维护更加复杂、容易出错并且成本高昂。

使用汇编程序的一个常见参数是大小和性能，但更常见的是，大量的汇编程序代码远非最佳；为了保持一定水平的生产力和可维护性，通常会使用和重用“样板”代码，而不是针对特定情况量身定制，而编译器将分析代码更改并执行系统设计人员所需要的那种“微优化”真的不应该出汗。让您的算法和数据结构高效，并将目标指令集的详细信息留给编译器。

即使无法直接在目标设备上进行调试，使用高级语言也可以在 PC 上进行原型设计和模拟。

即使你保留了汇编代码，如果你的开发工具包括指令集模拟器，那可能是硬件调试的一个很好的替代方案；特别是如果它支持可用于模拟硬件设备行为的调试器脚本。

综上所述，将其视为“黑盒”并得出代码效率低下的结论是有点飞跃。例如，什么样的闪存看起来很慢？它如何与微控制器接口？你是如何衡量这种表现的？闪存本质上很慢——尤其是写入和页面擦除；在对软件性能做出任何结论之前，请检查 Flash 的性能规格。

【讨论】：