[参考译文] AM2634：多核 FreeRTOS 空项目无法正常工作

尊敬的 Kier：

我尝试使用 dev 引导模式和09.01 SDK 版本在终端复制相同的内容。

分享我的观察结果：

在我的第一次跑步中：

1.我能够从所有4个内核中获得打印件

2.我停止内核组并看到函数调用堆栈：

我看到所有四个内核都处于空闲任务中。

但是、当我再次尝试时、在我的第二次迭代中：

1、我已从所有4个内核获得打印件

2.我看到 core0和 core1打开 Hwip_data_abort_handler_c ()。

我在内部提出了相同的错误。 我的理解是、它要么进入等待中断(WFI)状态、要么进入空闲任务、而不触发 Hwip_data_abort_handler_c ()。

此外、您能否确认您看到的行为在每次跑步中是否保持不变？

此致、

Shaunak

尊敬的 Kier：

Unknown 说：

我认为如果 DABT 问题得到解决，那么我们之间可能会获得更好的一致结果。

我同意这一点。 我会在今天或明天尝试寻找一些带宽、以便了解为什么我们会获得 DABT。  

同时、我在内部项目中提出了一个错误、因此、 当错误被接受时、您可以预期在将来的版本中会得到修复。 在进行一些调试后、我将很快返回有关 DABT 问题的响应。

此致、
Shaunak

尊敬的 Kier：

我仍然没时间对此进行调试。 但该错误已被接受、并且预计的修复版本为10.00 SDK。 如果我在本周或下周找到时间,我将直接在这里回复。

此致、

Shaunak

好的、谢谢 Shaunak。 非常感谢。

Kier、

同时、我想知道您的应用程序遇到的确切问题是什么、它是否与我们在 empty SDK 项目中观察到的此 HwIP_data_abort_handler 问题相关？ 由于错误的官方修复版本是10.00、我不确定 SDK 团队是否会花时间解决这个问题。

此致、

Shaunak  

尊敬的 Shaunak：

我们四核 FreeRTOS 应用程序的问题是、在启动调试会话后的 DevBoot 模式下第一次恢复时、 仅运行 Core 0。 我需要 Reset -> Restart -> Resume 至少一次以使所有四个内核正常运行。  我不记得该问题是否涉及 DABT、因此必须检查并报告。

Kier.

尊敬的 Shaunak：

我回到这个问题,并认为我的应用程序受到相同/非常类似的问题,所以我确实需要帮助,请解决这个问题之前的 bug 修复在10.00。

阅读以下文章： (+)[FAQ] TMS570LC4357：Hercules 器件上的中止异常故障排除-基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛

似乎我有一个写入异步 DABT。 FSR [10,3:0]= 10110和 rw[11]= 1。

 我认为这意味着 DFAR (或 DATA_FAULT_ADDRESS)= 0xFFFFF6DF 不是可靠的问题来源。 文章说：

" 10.3如何跟踪导致异步数据中止的指令

• R14_abt–8是导致异常的指令附近的位置。
• 找到 R14_abt–8附近的一个"存储"指令、该指令可能会导致异常。"

遗憾的是、R14_ABT = 0x1、因此这没有帮助：

请帮我跟踪原因吗？

尊敬的 Kier：

我会在10.00发布之前确定此调试的优先级、并在下周中间给您回复

此致、

Shaunak

谢谢 Shaunak、非常感谢。 同时我也会处理这件事。

尊敬的 Shaunak：

我在寻找问题根源方面取得了一些进展、但我还不知道原因。

我在 Hwip_data_abort_handler_c 中放一个 BP、然后启用板载"PC Trace"、以便跟踪缓冲区以 DABT 结束。

该问题似乎是从 portasm 中宏 portRESTORE_context 中的函数 vPortRestoreTaskContext 触发的。 与此相关的是 FreeRTOS 问题。 希望这个屏幕截图进一步说明了以下内容：

尊敬的 Kier：

今天、我和其他一些专家进行了调试会话。 调用 vTaskStartScheduler()时，它也会创建一个空闲任务。 执行 empty_maine()函数后，我们将删除该任务，预期的是空闲任务将会运行。

但在 vApplicationIdleHook ()中,我们会将内核放入 WFI (等待中断)。 这会导致问题。

当您将此文件注释掉时(C：\ti\mcu_plus_sdk_am263x_09_01_00_41\source\kernel\freertos\portable\TI_arm_clang\arm_CR5F\port.c、第444行)

在注释和重建 FreeRTOS 库和 CCS 项目后、我没有看到问题。 如果评论 WFI 是可行的权变措施或解决方案 、我现在建议这样做还为时过早、因为它可能会影响其他功能。

我将更加努力地了解该问题、并向您更新相同的

此致、
Shaunak

谢谢你。

Unknown 说：

在注释和重建 FreeRTOS 库后

请告诉我如何重新构建 FreeRTOS 库。

Unknown 说：

但是在 vApplicationIdleHook ()中,我们将内核放在 WFI 中(等待中断)。 这会导致问题。

我不相信。 在上电后第一次执行时、我仅命中第444行的断点。 点击 BP 并恢复后、它会再次点击 BP、但无法获得 DABT、等等。

在"Resume"、"Resume"、"Restart"之后、我从不命中 BP、但始终获得 DABT。

我认为 DABT 有多种原因。 您找到了一个(我无法复制)、并且我找到了一个或多个不相关的附加 DABT。

我会继续调查。

我找到了至少一个 DABTs 的原因。

在上电后首次执行时，函数 prvInitializeTaskLists()被正确调用，因为 uxCurrentNumberOfTasks =1。

但是，在 Reset，Restart，Resume 函数调用  prvInitializeTaskLists()被错误地跳过，因为 uxCurrentNumberOfTasks 尚未复位为0。 它意味着 pxReadyTasksLists 包含空指针，然后导致了 A/DABT。

在复位、恢复、重新启动之后：

这就引出了为什么要 使用 uxCurrentNumberOfTasks (和其他数据？)的问题 重新启动代码时、是否未在此项目中初始化？ 如果这是根本性的问题,难怪我得到 DABTs 遍布各地。

什么是"BYPASS_AUTO_INIT"？ 这看起来非常可疑！

项目被设置为使用 RAM 自动初始化模型、但这似乎与 FreeRTOS 代码不兼容、因为不能 复位  uxCurrentNumberOfTasks = 0。

这解释了为何该项目仅在 DevBoot 模式下加电后才运行、其中 RAM 默认为0。

如果我将 auto init 模型更改为 ROM：

现在、每次"Reset"、"Restart"、"Resume"都运行代码。 以下 是3个试用运行：

但是、现在我在 Core0和1的第一次运行(并且仅在第一次运行)中获得了 PABT。

Shaunak 先生、请您确认我的发现吗？

尊敬的 Kier：

我是因为生病了,所以不能上班了。"

感谢您的进一步分析。  

Unknown 说：

请告诉我如何重新构建 FreeRTOS 库。

您可以运行 mcu_plus_SDK 文件夹中的以下命令来清理和构建 FreeRTOS：

# To clean
gmake -sj -f makefile.am263x freertos_r5f.ti-arm-clang_clean PROFILE=debug

# To build
gmake -sj -f makefile.am263x freertos_r5f.ti-arm-clang PROFILE=debug

我将对您在上面分享的信息进行分析、并提供一些回复。

此致、
Shaunak

Unknown 说：

但是在 vApplicationIdleHook ()中,我们将内核放在 WFI 中(等待中断)。 这会导致问题。

在进一步尝试后、我确实发现移除 WFI 对于我的申请有很大改善。 谢谢您的讲解。

注意之前关于示例项目中 init 模型的注释仍然有效。 如上所述、我认为 DABT 有多种不同的原因。

另一个 DABT 仅在 Core 2中出现(奇怪地)、每5次运行一次、大约为：

prvTimerTask()中的内容看起来像原因。 我会进一步调查。

尊敬的 Kier：

感谢您的反馈和分享观察结果。 我还将尝试进一步调试并复制以上观察结果。

此致、

Shaunak

尊敬的 Shaunak：

请提供有关这方面的更新吗？

在 Port.c 中使用 WFI 指令会有什么问题？ 为什么去除它会改善问题？

谢谢你。

尊敬的 Kier：

我找不到调试时间、Im 被严重占用、无法提交可以花时间开始的任何日期。 如果您愿意、可以通过您的 TI 代表或 FAE 上报此问题并更多地关注此问题。

我明白这对您来说是一个非常重要的问题、对于我尚未找到修复程序的问题深表歉意。

Unknown 说：

在 Port.c 中使用 WFI 指令会有什么问题？ 为什么去除它会改善问题？

[/报价]

问题是不是把核心放在"WFI "。 问题是将多个内核放入"WFI"。 这是不可预料的情况、会导致意外的行为。 Im 猜测当所有内核都在 WFI 中运行时,他说:"我无法指出确切的问题。

它可以是：

1、共享资源分配,可能在每个内核的内存上设置防火墙,导致其他内核无法访问,如果是这种情况,可能会有所帮助。 我想4个内核之间唯一共享的存储器是 RAM。

2.将所有4个内核全部放入 WFI 时，如果发生中断，则没有正确处理(可能是由于再次进行非法的内存访问)，这导致了 PABT。

我尝试了您分享的设置、并在 WFI 中进行了注释。 (ROM 执行)。 我能够复制您的错误。 我会在这方面投入一些精力、但我对 FreeRTOS 的了解非常有限。

此致、

Shaunak

尊敬的 Kier：

最后、我得到的最新更新是 Im 无法在 port.c 中针对 ROM 运行时环境进行注释的 WFI 重现问题。 (通过 MCU_PLUS_SDK 09.02)。

我尝试了10次运行该示例、

这是10个周期(Run -> Halt 并检查 Aborts -> Reset -> Restart -> Resume)后所有内核的调用堆栈

此致、

Shaunak

尊敬的 Shaunak：

感谢您的回复。

无论原因和机制如何、您是否仍建议从 Port.c 中的应用空闲挂钩删除 WFI 指令？