[参考译文] TMS570LS3137：中止/预取中止调试

您好！

与寄存器的值不同、每个数据中止的状态和故障地址不同。  在启用 SECDED 之前、所有 ATCM 程序存储器空间(闪存组0和组1)的 ECC 值必须被编程到闪存中。 此 CAB 通过使用链接器脚本来完成。

https://software-dl.ti.com/hercules/hercules_docs/latest/hercules/How_to_Guides/index.html

以下是使用链接器脚本生成 ECC 的示例：

e2e.ti.com/.../5543.sys_5F00_link.cmd

我已根据示例更改了 sys_link.cmd 文件、但它没有帮助-我有另外两个预取和数据中止示例。 有趣的是、有时 MCU 会进入_c_int00几次、然后会发生数据中止。 请查找随附的 sys_link.cmd 和两个寄存器转储。

e2e.ti.com/.../Ozone_5F00_Registers_5F00_1_5F00_220819_5F00_Dabort.csve2e.ti.com/.../Ozone_5F00_Registers_5F00_1_5F00_220819_5F00_PrefetchAbort.csve2e.ti.com/.../sys_5F00_link.txt

我忘了提到应该打开 ECC 生成。 否则不会生成 ECC。

CCS 工程属性-->编译--> ARM 链接器-->高级选项-->链接器输出  

在链接器输出面板中、为"控制 ECC 生成是打开还是关闭"选择"打开"

加载代码时、请取消选中"Auto ECC Generation"

您好！

我不使用 CCS 进行开发、但我已为链接器添加了--ecc=on 标志、现在我可以看到 ECC 区域确实已刷写。问题仍然存在、 但行为完全不同-程序运行34秒、然后复位(调试器在_c_int00上停止)、从断点释放后、它运行34秒并复位、等等。 我是否可以与您分享任何信息来帮助我解决此问题？

STC 在 CPU 自检或 STC 自检完成后生成一个 CPU 复位。 您是否正在执行 CPU 自检和 STC 自检？

是否 启用 看门狗？ PLL 跳周或振荡器故障也会触发器件复位。

您好！

目前我没有使用看门狗、请找到已启用的所有测试。 不过、我不知道 CPU 自检和描述的行为之间的连接在哪里？ 当我注释掉我的周期性任务时、没有复位、应用程序正常工作。

您的配置中未启用 CPU 自检和 STC 自检。  

周期性任务有什么作用？

首先、它在 FreeRTOS 定时器任务(TMR 服务)环境中工作、其优先级设置为31 (最大优先级为32)。 它每500ms 触发一次、以检查最近是否有任何计划的操作-让我们将其称为软件看门狗。

在启动该计时器之前、在微秒计时器(基于 RTI)初始化时、会调用回调方法、该方法会向事件调度器添加具有相同回调的另一个操作、该方法每200ms 调用一次、从而满足看门狗的要求。 调度程序是根据链接列表编写的。

因此、假设有一个从中断上下文(RTI 比较)触发的循环回调和一个从 FreeRTOS 计时器任务上下文触发的软件看门狗。 如果我禁用这些功能、一切都像一种魅力。

您可以使用两个计时器：一个用于 FreeRTOS 计时器、另一个用于应用任务。 要启用第二个 RTI 比较、您需要手动修改 functin prvSetupTimerInterrupt (void)的代码：

静态空 prvSetupTimerInterrupt (void)位于 OS_port.c 中

我已经这么做了、我的 RTI 比较接口工作正常。 问题是、在这~30秒后、可能会导致系统崩溃、但我看不到原因。 我的源代码摘录是否有用？

摘录会有所帮助。  

好的、那么从一开始：

e2e.ti.com/.../sys_5F00_main.cpp

这是主例程、没有什么特别之处、生成 HAL 初始化、然后生成日志任务(优先级22)和用户空闲任务(优先级1)。 日志记录任务只执行写入缓冲区和通过 SCI 初始化 DMA 传输。

用户空闲任务初始化(主循环目前不执行任何操作)：

e2e.ti.com/.../user_5F00_idle_5F00_task.cpp

逐行初始化微秒计时器(稍后会进行更多详细信息、因为这是"失败"计时器)、 然后从 FEE 读取引擎配置、生成 ADC 周期性任务(优先级为30、它在500Hz 频率下工作、除了轮询内部 ADC 以获取转换结果并将值转换为电压之外什么都不做)并启动、然后初始化两个传感器。

微秒计时器：

e2e.ti.com/.../microsecond_5F00_timer.cpp

这里有所有有趣的东西。 在定时器初始化(第58行)上执行了低级初始化(除了 RTI 设置)、然后硬件定时器在它确实正常工作时进行验证(一个事件被安排在将来、任务被暂停一段时间、然后一个测试操作被执行标志被检查)。 接下来的两行是导致故障的行、如果我将其注释掉、则一切都正常(第66-68行)。 首先、执行回调-此回调将安排未来的另一个事件、可以在此文件底部找到调度程序的框架。 这种定期执行的事件会满足第68行中产生的看门狗要求-如果1200ms 内没有发生任何事件、则表示出现了严重错误。

就是这样、如果您需要其他东西、请告诉我。

谢谢。 我将学习您的代码、下周回来。