This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RTOS/DM3725:针对现场崩溃问题进行 ERROR_raiseX 调试

Guru**** 2590540 points
Other Parts Discussed in Thread: SYSBIOS, DM3725

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/587980/rtos-dm3725-error_raisex-debugging-for-field-crash-issue

器件型号:DM3725
Thread 中讨论的其他器件:SYSBIOS

工具/软件:TI-RTOS

XDC 版本:xdctools_3_30_06_67_core

SYSBIOS 版本: BIOS_6_42_03_35

编译器版本: TI-CGT-C6000_8.0.1

硬件:DM3725  

我的代码正在生成 一个 Error_raiseX、它根据 Error.c 文件调用 Error_policyFxn。。。 我想知道 哪个模块引发了错误? EB 块将为空... 我还需要所有登记册信息和 NRP、IRP 以及其他详细信息、例如例外情况。 该数据将打印在我的记录工具中、以便我可以离线分析此问题、而不必依赖 CCS 和 ROV... 是否有任何关于如何在没有 CCS 和 ROV...的情况下顺利进行调试的输入??

此致

John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    John、
    默认 Error_policyFxn 会记录每个引发的错误,并且记录的数据包括模块的 ID。 如果您在 CCS 外部进行调试而不使用 ROV、则必须从为您的应用生成的配置 C 文件中解码模块 ID。 该文件通常位于构建目录中的 package/cfg 目录中。 如果您搜索 Module_id__C、您将能够看到所有模块的 ID。
    是否使用默认 Error_PolicyFxn? 您使用的是哪种记录器?

    错误模块不会记录任何寄存器信息、因此我不知道您如何将该模块用作捕获 CPU 状态的工具。 您可以确定错误的来源、然后更改该代码以引发异常、但您似乎正在寻找更通用的解决方案、而无需更改代码。 是这样吗?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Sasha、

    感谢您的快速响应...我可以在 app_pe64P.c 中看到以下内容您所指的是...?? 。  MODULE__id_C =(XDC_Bits16) 0x2a  

    /* Module_id__C */
    #pragma DATA_SECTION (ti_SYSBIOS_hal_Timer_Module_id__C、".const:ti_SYSBIOS_hal_Timer_Module_id__C_");
    __far__ const CT_ti_SysBIOS_hal_Timer_Module_id ti_SysBIOS_hal_Timer_Module_Module_id_C =(XDC_Bits16) 0x2a;

    ERROR_raiseX 函数具有 Error_Block *EB、Types_ModuleId MOD CString 文件内部行 Error_ID IArgarg1 、IArg2  

    修改代码以及 XDC 文件或 SYSBIOS 文件没有问题,我可以重新编译... 但我只想确保我的调试没有 CCS 和 ROV、我不必依赖这一点、因为我需要解决日志信息中归档的问题(我有自己的日志框架)

    我可以使用此数据并重新编译 Error.c 文件 ,并使用我的日志记录 API 来记录某些信息,如 MOD id Cstring 文件 Error ID... 请问错误 ID 是什么? 我们能否将其转换为可读格式的字符串。 即使 CCS 中的 Cstring 文件是使用-Dxdc_file=_file__进行自定义编译、也会提供空值

    此致

    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您最初遇到的一个问题是如何使用日志内容找出哪个模块引起了错误。 我还不知道您是否正在使用默认 Error_policyFxn 以及您使用的记录器、但您的日志可能包含默认 Error_policyFxn 通常记录的信息。 这意味着、您有可用的模块 ID 和行号。 您可以在此处将模块 ID 与配置 C 文件中的一个 Module_id_C 值进行匹配。 现在、您知道了模块和文件行号、因此您应该能够检测生成错误的确切代码段。

    ERROR_ID 也是在配置 C 文件中生成的常量。 在日志的和 Error_ID 中、您可以通过斩波较低的16位、然后在配置 C 文件中搜索较高16位的十进制值来找到相应的 Error。 所有错误 ID 均为 XDC_Runtime_Error_ID 类型。 这一切听起来都很复杂、因为您正在尝试复制 CCS 和 ROV 将为您完成的工作、但如果您计划调试错误、则应该能够自动执行此查找。

    通常情况下、Error_ID 连接到错误消息、但这些错误消息不是标准 C 字符串、您可以使用 Error_ID 在存储器中查找这些字符串。 这些字符串由模块文本管理、模块文本会保留和排列这些字符串、并在其他模块发出请求时检索它们。 例如、请查看 XDC/RAuntime/Log.c 中的 Log_doPrint 但是、我会将该部分留待稍后处理。 在开始部分、只需验证您可以从配置 C 文件的 Error_ID 中找到错误。 该文件中的错误如下所示:
    RUNTIME_ERROR_ERROR_PARAMETER_C =(((XDC_RUNTIME_Error_ID) 640)<< 16 | 0);
    您将要搜索640、找到此行后、您会知道模块 runtime.errors.Errors 中的错误参数640是 Error_ID、然后您可以在该模块的 XDCspec 文件中查找有关该错误的更多信息。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Sasha、

    我不使用 Error_policyFxn、而是使用我自己的 API 将详细信息记录到我的日志记录工具/框架中... 现在、当出现错误时、我看到以下内容

    线路=124

    ERRORID=276955136

    MODID = 41

    现在我去检查了41与十六进制中的0x29对应的内容... 它指向 hal_Hwi_Module

    TI_SYSBIOS_hal_Hwi_Module_id ti_SYSBIOS_hal_Hwi_Module_id_C =(XDC_Bits16) 0x29;

    现在、我如何确定哪个条件提高了它... 我 交叉检查了此文件 (C:\ti\BIOS_6_42_03_35\packages/ti\SYSBIOS\family\c64p)和相应的第124行,我看不到任何 Error_Raise。 相对于 ErrorID 的 wInt、您是否能够解码具有高16位数据的任何内容? 即0x1082

    此致

    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    错误 ID 是特定于应用程序的。 尝试搜索0x1082的十进制表示法、有时我们不能仅使用十六进制数。
    hal.Error 引发错误的唯一位置是栈溢出。 在配置 C 文件中查找 E_stackOverflow、并查看其错误代码是否匹配。