[参考译文] CCS/AM3356：[T=0x19f81955] xdc.runtime.Main:错误：&quot；src/tirtos/SemaphoreP_tirtos.c&quot；、第212行：断言失败

更多测试后的其他信息：

我在自定义错误提升挂钩(xdc.runtime.Error.raiseHook)中看到的是函数'BIOS_getThreadType ()'返回'BIOS_ThreadType_Main'、因此正确 触发了' ti.sysbios.KNL.semaphore：error：line 214'中的断言。 我不知道为什么函数返回'BIOS_ThreadType_Main'、因为'BIOS_start'函数已经被调用来启动调度程序、我的调试打印也显示任务已经在运行、一个是我自己的启动任务、另一个是 HSR 启动任务。 在我自己的启动任务中、我还打印当前线程类型、并在其中正确显示"BIOS_ThreadType_Task"。

在主函数中的'BIOS_start'调用之后、我还有一个'System_print'函数、说明 SYSBIOS 已终止、但我看不到控制台窗口中打印的文本。 因此调度程序仍应运行。

是否有人知道为什么'BIOS_getThreadType ()'可以返回'BIOS_ThreadType_Main'？

此致、

  韩文

Han、

>>当我禁用与 GPIO 中断相关的代码部分时，这意味着我不设置 GPIO 的回调函数，也不创建任务，我会遇到同样的问题， 但现在、在使用信号量从连接到 DMTIMERS 之一的函数触发的任务中

您是否可以正常运行默认的 HSR/PRP 应用程序？ 您使用的是哪种 DMTIMER？ 您是否启用了 DMTIMER？

您可能可以从 HSR 示例开始、并逐步添加应用程序、而不是将 HSR 示例添加到您的项目中、从而导致问题的根本原因？

确保在项目中添加了 HSR_APP CCS 项目中定义的所有符号(CCS Build->GNU compiler->Symbols)。

此致、

Garrett

您好、Garrett、

>>您是否有正常运行默认 HSR/PRP 应用程序的情况？
默认 HSR 应用程序不编译、在"uint8"、"Uint16"等未找到的内容上有很多错误。 我还无法找到声明或定义这些类型的头文件。 因此、我无法测试应用程序、我宁愿不花时间修复这些编译器问题、而是更愿意将时间放入我自己的应用程序中。
我已将 HSR 应用程序的构建日志文件附加到此消息供您参考、您可能可以告诉我错误的地方。

>>您使用的是哪个 DMTIMER？
我用于应用程序的 DMTIMER2、它是3、但这与 Timesync 模块冲突、因此我将其更改为2。 即使我启用了所有与 PRU 相关的内容、我的计时器似乎也能正常工作。 我知道这是因为计时器触发时调用的函数会切换其中一个 GPIO 引脚、我可以使用逻辑分析仪看到这一点。 在我的软件因断言错误而崩溃之前、它只会被调用两次。

>>您是否启用了 DMTIMER？
DMTIMER 已启用、否则我将看不到计时器触发我的函数。

>>您可能可以从 HSR 示例开始、逐步添加应用程序以找出问题的根本原因、而不是将 HSR 示例添加到您的项目中？
将代码添加到 HSR 应用程序的选项目前实际上并不是一个选项、因为 HSR 应用程序甚至不会进行编译。 此外、HSR 应用示例中缺少一个东西、那就是"Board_init"函数调用。 电路板设置是否像引脚多路复用等。在应用程序中完全手动完成，与 SYSBIOS 中的电路板模块没有任何关系？
在这方面我是否会有问题？ 当我通过使用以下标志调用'Board_init'来执行硬件初始化时：
BOARD_INIT_PLL | BOARD_INIT_DDR | BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOLOCK | BOARD_INIT_ETH_PHY | BOARD_INIT_ICSS_PINMUX | BOARD_INIT_ICSS_ETH_PHY；
我已经更改了从 ICE V2板定义中获取的'Board_init'函数、以在标志'Board_init_module_clock'上执行'Board_pinmuxConfig'、而对于'Board_init_ICSS_PINMUX'则不执行任何操作。 'Board_init'由于标志'Board_init_PINMUX_config'调用的函数'Board_pinmuxConfig'将始终调用'PINMUXModuleConfig (CHIPDB_MOD_ID_CPSW、0U、1U)；'和'PINMUXModuleConfig (CHIPDB_MOD_ID_CPSW、0U、1U)；'和'PINMUXModuleConfig (CHIPDB_ID_NULL、ICUNULL_ID_ID_UNULL'、ICSS、PRU)； 因为我需要 CPSW 和 ICSS 进行网络通信。

>>确保您的项目中添加了 HSR_APP CCS 项目中定义的所有符号(CCS Build->GNU compiler->Symbols)。
我已经在"CCS Build"项目下检查了整个项目配置、并确保它们尽可能匹配、因为我的配置更加复杂、因为我的应用程序具有更多的功能。
因此、这不应是问题的原因。

您是否有任何建议可供我尝试，无论是关于不编译的 HSR 应用程序，还是当我启用 PRU 相关代码时应用程序中的断言？

此致、
  韩文

e2e.ti.com/.../0474.2019_2D00_09_2D00_10-_2D00_-Build-errors-hst_5F00_app_5F00_AM335x_5F00_arm.txt

您好！

我一直在研究其他一些问题，因此我没有时间研究这个问题。 但今天我已经在这方面做了很多工作。

我所做的是安装旧版本的 SDK、并将 TI HSR 示例应用设置为使用旧 SDK。 我的配置如下：
EDMA       2.12.5
NDK        2.26.0.08
SYSBIOS    6.52.0.12
AM335x PDK 1.0.10
XDCTool    3.50.3.33_CORE

HSR 示例应用程序现在编译时没有错误、只出现一些警告、我希望这些警告是正确的。
我尝试在 TI ICE V2 EVM 上运行应用程序的 Release 和 Debug 构建、但两者都崩溃、并显示以下消息：
    CortxA8：未处理的 ADP_Stopped 异常0x20023

您是否有什么想法会导致这种情况？ 我已经为您附加了构建日志、这可能会让您了解问题可能是什么。

我们宁愿不降级到较旧的 SDK、因为这对我们来说意味着很多工作、因为我们已经使用当前的硬软件进行了初步类型测试。 返回 SDK 版本意味着我们必须首先启动软件并再次运行、然后重新应用我们在 SDK 中执行的修复。 然后、我们需要再次运行大量测试、以验证所有内容是否仍然正常工作。
此外、还存在运行到新 SDK 版本中已修复的问题的风险。
所以，对我们来说，这是一项重大的工作。
将 HSR/PRP 库更新为新 SDK 版本的计划是什么？

此致、
  Han Hoekstrae2e.ti.com/.../Build-HSR-test-app.log

Han、

您是否按照 HSR/PRP 用户指南中的说明应用了补丁？

http://software-dl.ti.com/processor-industrial-sw/esd/docs/indsw/hsr_prp/01_00_04/PRU_ICSS_HSR_PRP.html#system-requirements

"若要编译工程、请确保 [INSTALL-DIR]/protocols/pdk_patches/04.03.00 应用了中的 PDK 补丁。 这是一个必需的步骤、因为它依赖于基线处理器 SDK。"

我们计划对所有协议进行 SDK 版本更新、而 HSR/PRP 将是第一个要更新的协议。 升级将不会在本季度进行。

此致、
Garrett