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.

[参考译文] TMS570LC4357:SL_SelfTest_STC (STC1_COMPARE_SELFCHECK、true、&stcSelfTestConfig)

Guru**** 2466550 points
Other Parts Discussed in Thread: RM48L952

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/659349/tms570lc4357-sl_selftest_stc-stc1_compare_selfcheck-true-stcselftestconfig

器件型号:TMS570LC4357
主题中讨论的其他器件:RM48L952

您好!

TI 安全库中的函数"sl_SelfTest_STC (STC1_COMPARE_SELFCHECK、TRUE、&stcSelfTestConfig)"无法复位 CPU。 它返回 true、这意味着参数良好、但它不会复位 CPU、这是运行 CPU 自检所必需的。

ESM 没有错误。  

有人会告诉我这个问题的原因吗?

非常感谢

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

    在执行间隔0后、应该有一个相应的 CPU 复位。 要执行自检、您必须配置 STC、以便仅执行间隔0、您是否可以发送自检配置结构的内容以便我可以进行检查。 这本身不应阻止间隔执行、但我想回顾一下。

    "true"的返回值实际上毫无意义、因为它实际上只是一个默认的返回值。 在 STC 的正常执行中、永远不会达到此函数的返回值、因为 CPU 将复位、然后代码应在 STC 运行后采用的路径。

    您能否上传启动文件和启动 STC 自检的代码、以便我了解一下。 此外、您正在使用哪个版本的 SafeTI 诊断库、因此我可以确保对齐。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、Davenport、

    我正在使用 TI 安全库2.3.1

    我在此帖子中附加了我的启动文件。

    感谢你的帮助。

    此致。

    e2e.ti.com/.../4478.TI_5F00_Startup.c.txt

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

    我对迟迟不能回复你表示歉意。 我一直在浏览您的启动代码和 SL 函数、没有发现任何会导致 STC 不像它应该那样起步的问题。 我将把这个问题转交给我们的软件主管、看看他是否对可能的问题有任何建议。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Rabie、

    您必须将 SafeTI 诊断库更新到版本2.4.0。 它与2.3.1兼容、无需更改应用软件。  

    原因:

    1) 1)理想情况下、SL_Selftest_STC 不会返回、因为一旦测试在 CPU 空闲"WFI"后启动、CPU 复位是完成测试后通过 STC 或外部复位恢复的唯一方法。

    2) 2)由于 WFI 指令(_sl_Kickoff_STC_execution 汇编函数的一部分)未成功执行、因此返回 true、主要原因可能是如果有任何中断挂起、CPU 不会进入空闲状态。 这里的 WFI 与任何其他 NOP 一样工作。

    3)在版本2.4.0中、我们将此 _sl_Kickoff_STC_execution 函数固定为在环路中运行、直到达到 WFI。 请参阅下面的快照...  

    我不知道为什么您仍然使用版本2.3.1、请访问 http://www.ti.com/tool/SAFETI_DIAG_LIB 并下载最新的 SafeTI 诊断库。  

    希望这对您有所帮助!!  

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

    我们在 RM48L952芯片上遇到了同样的问题。 在我们的情况下、当尝试在温度室内多次重新启动时、STC 测试不会被启动(1%的时间)。

    我们将 IAR 编译器与安全库2.3.1结合使用。

    如果 STC 测试由于挂起中断而未被启动、则2.4.0的代码更改似乎会永久阻止。 我们缺少什么吗?

    您还知道在开始测试之前安全清除任何挂起中断的方法吗?

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

    您好、Shazan、

    • STC 是否仅在启动期间触发(电源循环/系统复位)? 如果是、在启用系统中的任何中断之前、可以触发 STC、这将确保没有暂挂的中断。 一个异常,其 ID 为 ESN High (非屏蔽)中断。 确保在 开始 STC 测试之前清除 ESMSR1、ESMSR2寄存器(有一个勘误器件#56、有时可以设置此位)。
    • 如果 STC 测试定期运行、但系统重启后、我们必须小心谨慎、因为许多中断通道已启用、可能会触发。 这里处理所有挂起的 VIM 中断(检查 VIM 中断状态寄存器)并在开始 STC 测试之前禁用所有 VIM 通道(使用 VIM 模块寄存器)并将其与常规 CPU 上下文保存和恢复一起恢复。  

    因此、在进入 STC 测试时、处理挂起的中断并在 VIM 中将其禁用(不仅仅是使用 CPSR 在 CPU 中禁用中断)至关重要。

    最坏的情况我认为系统代码可以通过看门狗进行保护、以帮助摆脱这种卡在代码中的现象?   

    根据我在启动开始时执行 STC 的经验、操作更加简单、不需要过多的系统激励注意事项。