[参考译文] RM44L520：STC 自检- FAULT_INS = 0时不能进行正极测试、同时也不能出现超时问题

admin

Other Parts Discussed in Thread: SEGGER, HALCOGEN

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/578950/rm44l520-stc-self-check---positive-test-is-not-possible-with-fault_ins-0-and-also-timeout-issue

器件型号：RM44L520
主题中讨论的其他器件：SEGGER、 HALCOGEN

您好！

TRM 第8.4.10章的说明和寄存器内容似乎相互冲突。

说明：测试将始终失败：

如果签名比较逻辑正常运行、则 STC 运行将失败以进行签名缺失比较。

但是说明希望通过将第4位(FAULT_INS)设置为值0来提供无故障运行检查的选项。但根据我的经验、尽管 FAULT_INS 位值、STC 自检将始终失败、这种行为是否应该发生？ SafeTI-library 状态检查器 sl_SelfTest_Status_STC ()-fucntion 返回 true 并标记 ST_FAIL、即使 FAULT_INS=0至"ST_Result"、"CPU1Failure"和"CPU2Failure"变量、因此"TimeoutFailure"是 ST_PASS、因此不会发生。

第二个问题是自检期间 STCTPR 寄存器中的超时值。当运行自检(STCSCSCR 位 selfcheck_key == 0xA)时、最大值0xFFFFFFFF 会在某个位置挂起 CPU、而如果"STC_run"作为 sl_SelfTest_STC ()函数的参数给出、则相同的值有效。在自检/相位中、值0x1000挂起 CPU、至少值0x100和更小的值起作用...

这里是代码、其中启动测试的行为取决于所选的超时值

      stcSelfTestConfig.stcClockDiv      = 0；         /* STC 时钟分频器= 1 */
      stcSelfTestConfig.intervalCount   = 1；         /*仅一个时间间隔*/
      stcSelfTestConfig.restartInterval0   = true；      //从间隔0开始*/
      stcSelfTestConfig.timeoutCounter   = 0x100U；// 0x1000 ---不起作用，挂起 CPU；          //超时计数器*/
      _sl_HoldNClear_nError()；

      SL_SelfTest_STC (STC_COMPARE_SELFCHECK，TRUE，&stcSelfTestConfig)；

这里是实际工作的 STC 测试示例、其中 STC_MAX_TIMEOUT 为0xFFFFFFFF、这起作用
      stcSelfTestConfig.stcClockDiv      = 0；         /* STC 时钟分频器= 1 */
      stcSelfTestConfig.intervalCount   = 24；         /*仅一个时间间隔*/
      stcSelfTestConfig.restartInterval0   = true；      //从间隔0开始*/
      stcSelfTestConfig.timeoutCounter   = STC_MAX_TIMEOUT；          /*超时计数器*/

      sl_SelfTest_STC (STC_run、true、&stcSelfTestConfig)；

8 年多前

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好、Jarkko、

我已将您的问题转交给我们的 SafeTI 库专家。他们很快就会回来。

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好、Jarkko、

1) 1)我不确定您的时钟设置、但 STC 时钟应最大为90MHz。在您的用例中、我看到 stcclockDiv = 0、这意味着 CPU 时钟= STC 时钟。如果您已将 PLL 配置为大于90MHz、STC 的运行方式可能不正确。

2) 2)我执行了一个简单测试、在该测试中我使 self_check_key = 0xA 且 fault_ins=0、测试在没有错误标志设置的情况下完成。我尝试提供超时最大值、它没有挂起。

请检查 STC 时钟设置、重新进行测试并告知我们。

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好！

1) 1)您对时钟设置正确无误、但对其进行固定(使用 stcClockDiv！= 0)没有帮助。我使用了与 SafeTI 示例相同的代码、但没有进一步思考...

我以最大速度运行 CPU、因此 HCLK 为180MHz。因此、使用 stcSelfTestConfig.stcClockDiv = 1应该足够了

顺便说一下、TRM 没有提到任何限制、但现在当我从数据表中找到提示时、我发现："自检的最大时钟速率为 HCLKmax/2。"

如果将分频器设置为1、则此"固定"代码不起作用、有效分频器应为2

/*确保 CPU 自检控制器能够实际检测到 CPU 内部的故障*/

stcSelfTestConfig.stcClockDiv = 1；/* STC 时钟分频器= xxxx */

stcSelfTestConfig.intervalCount = 1；/*仅一个时间间隔*/

stcSelfTestConfig.restartInterval0 = true；//从间隔0开始*/

stcSelfTestConfig.timeoutCounter = 0x1000U； //超时计数器*///*超时0x100有效，但0x1000无效-挂起 CPU */

vClearAndWait_nError()；

SL_SelfTest_STC (STC_COMPARE_SELFCHECK，TRUE，&stcSelfTestConfig)；

如果我将超时更改为0x100、那么它将再次起作用(.stcClockDiv 仍为1)

stcSelfTestConfig.timeoutCounter = 0x100U；

调试也很困难、如果不是几乎不可能的话、我正在使用 IAR 和 SEGGER J-link、并且没有找到一种方法来真正连接到目标、而不会重置目标。PC 始终指向0x0、我尝试过的情况总是丢失... 尝试从调试器下载表中仅启用"攻击运行目标"、然后尝试从"Project->Download and Debug"和"Project->Debug Without Download"两个选项... 还尝试了调试器下载表中的每种"勾选框"组合...

顺便说一下、"挂起 CPU "是我说的错误术语、我在每个 STC 预期故障分支中都有 while (1)循环、因此 CPU "挂起"、因为 STC 测试结果不是预期的...

我现在对它进行调试，以便在 STC 测试启动失败或导致它不符合预期的情况下，跳转至 fterSTC()函数，然后我将结果传输到 NO_INIT_variable，后者也可以承受 RAM PBIST (在 CPU RAM 中执行 PBIST 时，我将数据备份到外设 RAM) 它还可以在 main 之前耐受 c 标准变量初始化(由于 "no_init"关键字)。然后在 main 中、我将结果打印到 UART、这样我就可以在没有调试器的情况下看到发生了什么...

以下是自检中使用以下值时的结果。stcClockDiv = 1；和.timeoutCounter = 0x1000U；...

1.调用 sl_SelfTest_STC ()==成功(代码不返回)

2.如果((sl_stcREG->STCSCSCR & 0xFU)=STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCSCSCR_SELF CHECK_KEY)== STC 自检确实运行，则发生 CPU 复位并进入此分支

3.sl_SelfTest_Status_STC ()返回 true =寄存器也表示它确实运行

4.返回的状态.stResult = ST_FAIL 和.TimeOutFailure = ST_FAIL -->不正常，不应发生超时

我有这种代码可以跟踪(在 fterSTC()中)启动期间发生的情况

[代码]

if (u32StcStartFlail== 2)

｛

initSTFailCount |= 0x80000000；

｝

if (u32StcStartFlail=1)

｛

initSTFailCount |= 0x40000000；

｝

if (u32SelfCheckFail == 2)

｛

initSTFailCount |= 0x20000000；

｝

if (u32SelfCheckFail = 1)

｛

initSTFailCount |= 0x10000000；

｝

if (u32SelfCheckFail == 3)

｛

initSTFailCount |= 0x08000000；

｝

if (u32SelfCheckFail == 4)

｛

initSTFailCount |= 0x04000000；

｝

if (failInfostc.stResult！= ST_PASS)

｛

initSTFailCount |= 0x00100000；

｝

if (failInfostc.CPU1Failure！= ST_Pass)

｛

initSTFailCount |= 0x00200000；

｝

if (failInfostc.CPU2Failure！= ST_Pass)

｛

initSTFailCount |= 0x00400000；

｝

if (failInfostc.TimeOutFailure！= ST_Pass)

｛

initSTFailCount |= 0x00800000；

｝
[/代码]

结果为0x10900001
其中 lsb 1是错误计数(引导序列中的每次失败都会递增此变量)

因此我们有 u32SelfCheckFail == 1和 failInfostc.stResult != ST_PASS 和 failInfostc.TimeOutFailure != ST_PASS

这里是该部分的代码，它显示了它是 failInfostc.TimeOutFailure != ST_Pass，它会导致跳转到 vAfterSTC()，因此值0x1000U 是 STC 模块中的超时触发超时故障，其中值0x100或1不是。这听起来很疯狂、因为值越大、超时应该越大...
[代码]
void vCpuResetCheckerforSTC( void )
｛
   u32SelfCheckFail = 0；
   //检查是否运行自检
   if ((sl_stcREG->STCSCSCR & 0xFU)== STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCR_SELF CHECK_KEY)
   ｛
       //检查是否启用了故障插入位---如果未启用位，测试也会失败
       //sl_SelfTest_Result eExpected=((sl_stcREG->STCSCSCR & STC_STCSCSCSCSCSCSCSCSCSCSCSCSC_FAULT_INS/*bit_n( 4U )*/)？ ST_FAIL：ST_PASS)；
       SL_SelfTest_Result eExpected = ST_FAIL；
       //清除自检模式
       sl_stcREG->STCSCSCR = 0x05U；
       //检查测试状态
       if (sl_SelfTest_Status_STC (&failInfostc))
       ｛
           u32 SelfCheckFail = 1；
           /*清除 STC 全局完成状态标志-状态函数不执行此操作*/
           sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE；

           if ( failInfostc.stResult == eExpected )
           ｛
               if (failInfostc.TimeOutFailure！= ST_FAIL)
               ｛
                   //故障插入：CPU1和 CPU2应该在 CPU 和 NORMAL 同时通过时都失败
                   if ((failInfostc.CPU1Failure == eExpected)&&(failInfostc.CPU2Failure == eExpected))
                   ｛
                       esmREG->SR1[0U]= bit_n (27U)；//0x08000000U；//清除 ESM 组1通道27状态标志

                       initSTPassCount++；
                       /*启动 CPU 自检*/
                       vStartSTC( STC_run )；
                   ｝
               ｝
           ｝
       ｝
       其他
       ｛
           u32 SelfCheckFail = 2；
       ｝

       initSTFailCount++；

       fterSTC()；//调试

       while (1)｛｝// TODO：可以安全地继续或仅终止、如果继续必须设置错误
   ｝
[/代码]

SafeTI 示例代码还具有从160MHz 到220MHz 的 PLL 以及 HCLK 和 GCLK

#define HCLK_FREQ 160.000F

#define HCLK_FREQ 180.000F

#define HCLK_FREQ 220.000F

它在每个位置使用完全相同的线

stcSelfTestConfig.stcClockDiv = 0；/* STC 时钟分频器= 1 */

那么、SafeTI 示例中存在一个错误？

SL_SelfTest_STC ()中的这一检查也是错误的、根据数据表、STCCLK 必须始终为 HCLK/2、因此不能接受值0、但这仅检查上限...

if (config->stcClockDiv>STC_MAX_Cock_DIV)｛

SL_Log_Error (FUNC_ID_ST_STC、ERR_TYPE_Param、0U)；

RetVal = false；

retval；

｝

除非 TRM 中的这条语句表示在某些情况下、HCLK 可能不遵循 GCLK 或其他内容...

•使用 CDDISx 寄存器 GCLKOFF 位0与 HCLK 分别被禁用

2) 2)很高兴听到它在我们的桌子上工作、因此应该可以进行积极的测试、但我想、至少只要我在案例1中遇到了超时问题、我不会对结果产生负面影响、因此案例1应该先解决、之后这很可能也会起作用...

0 admin 8 年多前

TI__Guru**** 2328340 points

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

只是更新

因此、它的工作方式是使分频器大于2、超时相对较小
stcSelfTestConfig.stcClockDiv= 7；/* STC 时钟分频器= xxxx */
stcSelfTestConfig.intervalCount= 1；/*仅一个时间间隔*/
stcSelfTestConfig.restartInterval0= true；//从间隔0开始*/
stcSelfTestConfig.timeoutCounter= 0x1000U；/*超时计数器*/*超时0x100起作用，但0x1000不起作用-挂起 CPU */

现在、我的调试跟踪器显示为14680064dec = 0x00E00000、这意味着未激活任何群集、而 failInfostc 显示除超时之外的所有其他群集失败...

但是、如果我现在将超时增加到0xFFFFFFU、它将不再工作、并且行为与以前一样、调试跟踪显示的277872641解码= 0x10900001与以前相同...

因此.stcClockDiv 在系统中不会产生某些影响、但不会修复根本原因-我假设自检强制故障应使内核发生故障、而不会生成超时、如果超时足够小、则会发生内核故障...

我认为必须检查.TimeOutFailure、以确保由于 CPU1和 CPU2故障而不是由于超时故障而导致的测试故障、如果最远的故障到此超时故障、则它不能提供任何证据证明 STC 确实能够检查 CPU (如果(stcREG->STCGSTAT & 0x3U)!= 0x3U)...

0 admin 8 年多前

TI__Guru**** 2328340 points

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

只是为了再次纠正自己、我还发现了行为原因2

1)
我在上一篇文章中说过这是成功运行的结果(分频器7和超时0x1000：

"现在、我的调试跟踪器显示为14680064dec =0x00E00000、这意味着未激活任何群集、而 failInfostc 显示除超时之外的所有其他群集失败。。。"

我在上面的句子中有错误，解释了这种“E”背后的历史。成功运行时、CPU 逻辑将 STCGSTAT 故障位设置为0、但 SafeTI-function 还会检查 STCFSTAT 寄存器、并且每个位始终处于活动状态、因此在成功测试中(这现在是实际的 STC 测试而不是自检)、您只能检查"if (failInfostc.stResult = ST_Pass)"。由于我始终打印最新的结构内容、我们将看到0xE、表示只有.stResult 为 ST_Pass

我有这种代码来检查实际的 STC 测试结果、并且有与 STCFSTAT 内容相关的评论

[代码]
   否则 if ((sl_stcREG->STCGSTAT 和 STC_STCGSTAT_TEST_DONE)！= 0U)
   ｛
       if (sl_SelfTest_Status_STC (&failInfostc))
       ｛
           /*清除 STC 全局完成状态标志-状态函数不执行此操作*/
           sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE；

           //希望在成功时设置 sl_stcREG->STCFSTAT 中的所有故障位，因此只选中"stResult"
           if (failInfostc.stResult = ST_Pass)
           ｛
               initSTPassCount++；
               /*在 CPU STC 完成后继续启动序列*/
               fterSTC()；
           ｝
       initSTFailCount++；

       u32 SelfCheckFail = 3；
       用于调试的后 STC()；//

       while (1)｛｝// TODO：可以安全地继续或仅终止、如果继续必须设置错误
｝
[/代码]

您是否知道为什么 STCFSTAT 会在 STCGSTAT 不显示故障的情况下将位置为有效？

2)、STCGSTAT 内容正常的原因也是正测试失败的原因、如之前自检阶段的帖子所示。I 也检查 SafeTI 返回的 CPUxFailure、而当前在实际 STC 测试中、我不检查它...

现在、我在负一个测试后添加了正极自检、并添加了多个陷阱(u32SelfCheckFail = 5和 u32SelfCheckFail = 6)、并手动执行与 SafeTI 提供的相同的正测试启动例程(只是不要设置 FAULT_INS 位)

[代码]
   if ((sl_stcREG->STCSCSCR & 0xFU)== STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCR_SELF CHECK_KEY)
   ｛
       //检查是否启用了故障插入位---如果未启用位，测试也会失败
       sl_SelfTest_Result eExpected =((sl_stcREG->STCSCSCR & STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCSCR_FAULT_INS/*bit_n( 4U )*/)？ ST_FAIL：ST_PASS)；
       //sl_SelfTest_Result eExpected = ST_FAIL；
       //清除自检模式
       sl_stcREG->STCSCSCR = 0x05U；
       //检查测试状态
       if (sl_SelfTest_Status_STC (&failInfostc))
       ｛
           u32 SelfCheckFail = 1；
           /*清除 STC 全局完成状态标志-状态函数不执行此操作*/
           sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE；

           if ( failInfostc.stResult == eExpected )
           ｛
               if (eExpected == ST_FAIL)
               ｛
                   if (failInfostc.TimeOutFailure！= ST_FAIL)
                   ｛
                       //故障插入：CPU1和 CPU2应该在 CPU 和 NORMAL 同时通过时都失败
                       if ((failInfostc.CPU1Failure == eExpected)&&(failInfostc.CPU2Failure == eExpected))
                       ｛
                           esmREG->SR1[0U]= bit_n (27U)；//0x08000000U；//清除 ESM 组1通道27状态标志

                           stcSelfTestConfig.stcClockDiv      = 1；         /* STC 时钟分频器= xxxx */
                          stcSelfTestConfig.intervalCount   = 1；         /*仅一个时间间隔*/
                          stcSelfTestConfig.restartInterval0   = true；      //从间隔0开始*/
                          stcSelfTestConfig.timeoutCounter   = 0x1000U；      //超时计数器*///*超时0x100有效，但0x1000无效-挂起 CPU */

                          寄存器 SL_STC_Config* config =&stcSelfTestConfig；

                           #include "sl_reg_system.h"
                           SL_systemREG2->STCCLKDIV =((uint32)(config->stcClockDiv &(uint32) 0x07u)<< 24U)；

                           uint32 tempVal = 0U；
                           tempVal |=((uint32) config->intervalCount << STC_STCGCR0_INTCOUNT_START)；
                           tempVal |= STC_STCGCR0_RS_CNT；
                           sl_stcREG->STCGCR0 = tempVal；

                           sl_stcREG->STCSCSCR =(uint32)(STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCR_SELF CHECK_KEY)；

                               /*设置超时值*/
                           sl_stcREG->STCTPR = CONFIG->timeoutCounter；

                           /*启用 STC 运行*/
                           SL_stcREG->STCGCR1 = STC_STCGCR1_STC_ENA；

                           对于(tempVal = 0U；tempVal < 32U；tempV++)｛｝

                           /*启动 STC 执行*/
                           _sl_Kickoff_STC_execution()；

                           u32 SelfCheckFail = 5；
                       ｝
                   ｝
               ｝
               其他
               ｛
                   initSTPassCount++；
                   /*启动 CPU 自检*/
                   vStartSTC( STC_run )；
               ｝
           ｝
           其他
           ｛
               if ( eExpected == ST_Pass)
               ｛
                   u32 SelfCheckFail = 6；
               ｝
           ｝
       ｝
       其他
       ｛
           u32 SelfCheckFail = 2；
       ｝

       initSTFailCount++；

       fterSTC()；//调试

       while (1)｛｝// TODO：可以安全地继续或仅终止、如果继续必须设置错误
   ｝
[/代码]

结果是相同的、这表示在引导期间没有发生实际错误、因为变量的 LSB 部分为0
14680064解码= 0x00E00000

但是、如果我现在将分频器增加到7 (实数为8)、同时将超时保持为0x1000、并且错误陷阱显示24117249 = 0x0170001、这意味着 u32SelfCheckFail = 6、这意味着此行失败
if ( failInfostc.stResult == eExpected )
eExpected 为 ST_PASS (因此我们正在进行积极的自检...

除了超时、STC 时钟速度如何影响内核测试之外、所有其他故障位都处于活动状态、如果不会产生超时错误、那么错误 ...

我添加了类似这样的新故障陷阱代码
   if (u32SelfCheckFail == 5)
   ｛
       initSTFailCount |= 0x02000000；
   ｝
   if (u32SelfCheckFail == 6)
   ｛
       initSTFailCount |= 0x01000000；
   ｝

如果我现在将超时提高到0x10000、同时将分频器保持为7 (8)、则测试将再次通过、并且陷阱显示相同的14680064 = 0x00E00000、表示除.stResult 以外的其他字段出现故障、就像在每个成功的情况下...

在这种情况下、即使 STCGSTAT 未显示故障也会设置 STCFSTAT、这对于我来说是一个错误、无论是在 CPU 中还是在 SafeTI... 如果 STCFSTAT 中的该位设置是预期功能、则 SafeTI 不应在成功时检查它们、而应手动将结构值设置为 ST_PASS。。。。

TRM 没有说太多、只是当 ENA 被置位时、STCFSTAT 应该复位为0、这表明成功的测试真的会将这些故障位提升为激活状态...

0 admin 8 年多前

TI__Guru**** 2328340 points

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

Jarkko、

我忘了告诉一个发现、我几天前做过。 STCFSTAT CPU1和 CPU2故障状态位清零功能被交换。也就是说、当您写入1以清除 CPU1失败状态位时、它会清除 CPU2失败状态位。因此、必须重新访问/解决 SL_SelfTest_Status_STC ()、它会清除 CPU1或 CPU2故障逻辑。

我已将此问题提交给应用团队和设计团队以确认我的发现。如果已确认、将更新勘误表。

权变措施可以是同时清除 CPU1和 CPU2故障状态、或交换这些位以进行写清零。

附加一个简单代码(针对 RM46x 系列使用 HALCoGen)来测试这个。 /cfs-file/__key/communityserver-discussions-components-files/312/3884.sys_5F00_startup.c

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好！

如果该错误为 true、则我的器件(当前使用 RM44系列 L520PGE)上不存在(在该特定形式下)... 因为我在故障插入情况下检查 SafeTI 为两个内核返回 ST_Fails、并且该检查已通过、并且 SafeTI 逐个清除这些位。

顺便说一下、为什么您希望使用"halcogen"生成的代码进行操作、并且在这些论坛中、建议使用 SafeTI 代码、而不是 HalCoGen 代码、以便更轻松地进行调试？现在、我已经相当成功地从引导中删除了几乎所有与 selftest.c 相关的内容、并且如果 SafeTI-functions 具有 sulport、那么这确实是一种耗时的做法吗？

我认为、如果 TRM 正确、没有必要手动清除 STCFSTAT、因为新的测试开始(STC_ENA)应该会将其清除、所以为什么还要手动隐藏该信息...
- SafeTI 不应执行此清除操作、这也会修复可能的错误、当然、如果 STC_ENA 不像描述的那样工作、则需要其他一些改进程序

我的问题目前主要是超时值
-如果超时值相当大0x1000或更大、但在像0x100或更小的超时值时、为什么自检故障插入测试不起作用-这对我没有任何意义...
-如果超时不够大、为什么不插入故障的自检失败、那么这会直接运行1个周期、数据表显示1个周期需要1365 STCCLK、即0x555 (这也意味着 STC 分频器不重要、因为周期是 STCCLK)。 STCTPR 的 TRM 部分表示超时是 VBUS 周期、而这个 VBUS 项不在 TRM 中打开是否是 VCLK、但有 VCLK1、VCLK2和 VCLK4、VBUS 通常只是 HCLK 或 GCLK/2、因此 CPU 速度/2？

因此、如果 VBUS = HLKC/2且 STCCLK 分频器作为参数(1)给出、即1：2、当 VBUS = STCCLK 时、0x556作为超时应该足够-但这不是正的、自检失败(但现在超时：)、对于0x1000，它可以工作，它也可以与0xAAF 一起工作，即0x555*2+5.... 那么、VBUS 实际上= HCLK 吗？ 0xAA9也可以工作、0xA00、这两个值都小于0x555 * 2...

STCCLKDIV 的 TRM 部件是否真的正确？值0 = 0分频器、值1 = 1：1分频器、值7 = 1：7分频器？
"26-24 CLKDIV 0逻辑 BIST 期间 CPU 时钟的时钟分频器/预分频器"
-在这种情况下，值0和值1都是非法的
TRM 8.5.1中的 Bute 示例。表示 STCCLKDIV 是常规分频器寄存器、其中值0表示1：1分频器
"STCCLKDIV[26：24]= 1"

我注释掉了 SafeTI 的所有 STCFSTAT 插孔、与 TimeOutValue 相关的问题仍然显示相同、例如、如果值为0x556、则正自检(无 FAULT_INS)会显示 ST_FAIL 至除超时之外的其他每一个、但如果值在0xAA0范围内、则会通过...

因此、当 STCCLKDIV：CLKDIV = 1时
-如果超时低于0x100、自检负极有效、如果超过0x1000 (尚未测试二者之间的范围)、则失败。如果发生故障，此标志将会显示超时故障，而不是核心故障:)(禁用 SafeTI STCFSTAT ACK 不会改变行为)。
-如果超时0xAA0但不起作用是0x556 (之间尚未测试范围)、则自检正极有效。如果出现故障标志，则内核故障不会超时：)(禁用 SafeTI STCFSTAT ACK 不会改变行为)
-如果超时、实际 STC 工作/通过0xFFFFFFFF (未测试其他值)

因此、如果值"不正确"、超时会起作用奇怪(值应该可以、例如 FAULT_INS 不关心值是0x100还是0x1000、SafeTI 示例使用"出于某种原因"值1而不是0xFFFFFFFF、默认情况下、该值在实际 STC 测试中提供) 从 STCFSTAT 接收到的反馈是怪异的...

如果您的错误正确、它只能涉及某些器件、但我很确定我的器件中 CPU 中存在其他问题...

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好、Jarkko、

-我提到的错误不适用于 RM44和 TMS570LS07x/09x 系列器件。

-要评论您的 STCFSTAT CLEAR、从 TI 的角度来看、我们无法预测客户希望如何清除 STC_ENA、但在实际故障的情况下、客户可能会希望处理。那么、这由用户决定。

您所面临的问题。以下是使用 RM44器件上的 STC 自检执行的测试 I。

超时 (测试周期)	FAULT_INS	self_check_key	GSTATUS	FStatus	时间间隔	测试状态	注释
最大	1	0xA	3.	3.	1	测试成功
0x1000	1	0xA	3.	3.	1	测试成功
最大	0	0xA	1	0	1	测试成功
14:00	0	0xA	1	0	1	测试成功	根据数据表中的 CPU 自检覆盖范围表、对于间隔1、62.13%的覆盖范围、大约需要1365个周期、Hence I 配置了值1400以实现超时。
1300	0	0xA	3.	4.	1	测试成功	生成超时错误

我推测输出 FAULT_INS 的自检(0xA)等于 STC 运行(0x5)、因此它按照数据表中提到的表运行1个间隔。

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好！

非常感谢您的测试...

我想我现在弄清楚了主要问题是什么...

在 SafeTI 中、.stResult 极性与其他极性不同。对于 stResult ST_PASS ==自检无错误、对于该位的其他 ST_PASS ==错误。我多次读取源代码、但可以发现、在实施原因检查时、可能是因为 ST_PASS 名称(PASS)非常强烈、表明它"当然"意味着正常而不是失败...

此外、启用故障插入的自检将执行常规自检、因此、如果您像在 SafeTI 示例中一样将超时设置为1、则不会实际测试内核->测试失败超时、示例代码不会像我那样检查错误原因...

因此、在我为除.stResults 之外的其他器件修复了检查极性后、它看起来能够正常运行。

那么、这里是一个校正函数、用于测试从 CPU 内核中发现的故障(需要适当的超时、以便不会发生超时)、同样的检查还可以检查 FAULT_INS = 0时是否未发现故障...

if ((sl_stcREG->STCSCSCR & 0xFU)== STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCR_SELF CHECK_KEY)
｛
//检查是否启用了故障插入位
sl_SelfTest_Result eExpected =((sl_stcREG->STCSCSCR & STC_STCSCSCSCSCSCSCSCSCSCSCSCSCSCSCR_FAULT_INS/*bit_n( 4U )*/)？ ST_FAIL：ST_PASS)；

//清除自检模式
sl_stcREG->STCSCSCR = 0x05U；
//检查测试状态
if (sl_SelfTest_Status_STC (&failInfostc))
｛
if (eExpected == ST_FAIL)
｛
failInfostc_selftest_FAULT = failInfostc；
｝
/*清除 STC 全局完成状态标志-状态函数不执行此操作*/
sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE；

if ( failInfostc.stResult == eExpected )
｛
if (failInfostc.TimeOutFailure == ST_FAIL)//无超时
｛
//故障插入：CPU1和 CPU2应该在 CPU 和 NORMAL 同时通过时都失败
if ((failInfostc.CPU1Failure！= eExpected)&&(failInfostc.CPU2Failure！= eExpected))// ST_PASS == test failed
｛
// STC 自检正常...

我还问过 VBUS、这是否意味着分频器0 (1：1)可以使用、至少它看起来工作正常、示例也可以使用该分频器、或者它只能幸运地工作、SafeTI 接口应该在给定.stcClockDiv！= 0的情况下检查它？

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好！

实际上、我刚刚意识到我在11月提交了一个文档增强请求：SDOCM00122802

详细说明：
"这个结构中三个详细故障字段的含义对我来说是不直观的、请改进文档以使其更清晰。
以下是所有四个字段含义的简短说明：
在 STC 通过案例(stResult=ST_Pass)中、CPU1Failure、CPU2Failure 和 TimeOutFailure 应全部为 ST_FAIL。
在 STC 故障情况下(stResult=ST_FAIL)、一个或多个 CPU1Failure、CPU2Failure、TimeOutFailure 将指示 ST_PASS、以指示该故障原因。"

因此、在下一个版本中应注意这一点。

此致、
Christian

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好、再说一次、

我们切换至 RM48 CPU、而我的 STC 停止工作、立即记住了这一点、并在 SafeTI CPU1错误原因行上添加了注释

#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
/*SAFETYMCUSW 134 S MR：12.2 备注_5*/
if (STC_STCFSTAT_CPU1_FAIL =(STC_STCFSTAT_CPU1_FAIL 和 SL_STcREG->STCFSTAT))｛
//sl_stcREG->STCFSTAT = STC_STCFSTAT_CPU1_FAIL；
failInfostc->CPU1Failure = ST_PASS；
｝
#endif

之后、STC 开始工作(在我的应用中检查了 HalCoGen 返回的所有结构字段的负、正和实际自检)。

您能否验证您的错误确认器也是 RM48、而不仅仅是 RM46？ RM48的勘误表未提及它
www.ti.com/.../spnz223b.pdf

0 admin 8 年多前

TI__Guru**** 2328340 points

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

您好、Jarkko、

在 STC CPU 失败状态下、我在 RM48、RM46、RM42和 RM41的旧版本上尝试的操作都显示相同的行为。 (TMS570LS31x、21x、1x、04x、03x 的较早版本、 02x 也应该有此问题)。

RM44不存在此问题、它是 Hercules 系列中发布的最新器件。 (TMS570LS09x、07x 不应出现此问题)。

的行为应相同

我已将此问题提交给应用团队、他们负责在对方确认后更新勘误表。

上述器件的最新版本中的 STC 硬件 IP 版本相同、因此我预计最新版本的器件中不会出现此问题。

基于 Arm 的微控制器（参考译文帖）

基于 Arm 的微控制器（参考译文帖）(Read Only)

[参考译文] RM44L520：STC 自检- FAULT_INS = 0时不能进行正极测试、同时也不能出现超时问题