[参考译文] RTOS：对6416单核处理器的异常处理支持。

Hanumanth、

在这里的重复主题中 、您提到了2个不同的器件型号。 我认为 C6416是正确的、但请澄清一下、在我们继续这么做之前、我们会做得太远。

在从 C6416中的 C64x 内核升级到 C6455中的 C64x+内核(以及更高版本的内核、例如 C674x 和 C66x)之前、我们的 DSP 系列不包含 CPU 异常处理、例如针对无效程序/数据访问或无效指令代码的 CPU 异常处理。 因此、C6416器件不能进行异常处理。

如果没有额外的帮助、则很难对主要异常事件进行故障排除和调试、即使通过异常处理也很难做到。 调试方法因故障的性质、发生频率、可重复性、一致性等而异。

请描述这种情况、以便我们为您提供最适合您的故障情况的调试建议。

一些想法是：

1.在发生故障并控制仿真控制下的器件后、找到堆栈指针的值并查看堆栈末尾附近的存储器位置(地址稍高)、以查看是否有任何值看起来像程序空间地址。 其中一个可能是最近函数调用中保存的返回地址。 您可以查看堆栈上的其他位置、看看它们如何与堆栈框如何组成应用中的各种函数进行比较、从而了解程序可能崩溃的位置。

我最喜欢的工具是创建循环缓冲区、在应用程序运行期间定期将信息保存到其中。 在输入10个不同函数时、可以使用1-10之间的简单数字来表示其中一个函数。 然后、一些其他值可能与这些值一起存储、以形成显示历史记录的值的"结构"。 发生故障并控制仿真控制下的器件后、找到循环缓冲区中的指针位置、并确定故障发生前执行的最新函数。 这可能有助于找到适合测试断点的位置。

3.最后，您将尝试缩小故障位置，并将断点设置为尽可能靠近该位置。 如果您可以执行此操作、然后单步执行、直至发生不良情况(例如分支到无效的程序空间)、那么您将更接近查找故障源。

此致、
RandyP

您好 RandyP、

感谢您的详细解释和建议、
是的，我的器件型号是 C6416，感谢您明确确认 C6416中此 C64x 内核上的异常处理不可用性。
是的、我们将研究调试可能的想法、
至于您的指示、我们在6416上部署的应用的想法1和3是完全自定义的、紧密集成在盒子中、我们无法连接 JTAG、无法控制受仿真控制的器件、我们无法使用断点方法进行调试、

想法2： 我想说的是、由于我们无法连接 JTAG 并且无法在仿真控制下控制器件、但我们可以在每个时间间隔内将缓冲器(具有函数级或任务级信息)从系统模块中拉出并使用 SRIO 或以太网、 获取最后一个数据包并检查每个阶段的值，将有助于我们指出系统模块中最后一个任务或功能，因此我们可以通过某种方式指出软件崩溃的根本原因。

请让我再了解一下建议、


再次感谢、
Hanumanth