[参考译文] RM46L430：安全手册指出 RAM7A & amp；RAM7B 被 SL_SelfTest_PBIST 覆盖、但是 sl_SelfTest_PBIST 无法运行 TCRAM、因为运行测试会破坏#39；C#39；运行时系统

Mark、您好！

PBIST 通常在器件启动时运行、因为它是一个破坏性测试、并且测试期间被测试的 SRAM 模块的所有内容被覆盖。 SRAM 分为多个组、您可以将数据和指令放在一个 SRAM 组中、并测试其他 SRAM 组。 另一种方法是将数据复制到未使用的外设(例如 CAN1 RAM)的 RAM 中、并在 PBIST 之后将这些重要数据恢复到 SRAM 中。

Mark、

为了添加到 QJ 的注释中、RAM7A 和7B 指示 PBIST 的引导时间和周期性执行。 如您所注意到的那样、在 SRAM 上运行 PBIST 是破坏性的、并且应该只在引导时完成、这是因为在定期执行 PBIST 期间、您不太可能在器件中找到另一个可用于备份数据/运行时信息的 RAM。 对于某些器件、SRAM 分为不同的部分、因此理论上 PBIST 可以在一个上运行、而在另一个上运行则用于备份、但由于软件与 RAM 访问的依赖关系超出了用户控制、因此即使这种情况也难以管理。 为了解决这一问题、我建议在引导期间将代码实施为内联代码、以便不需要/使用栈。

此外、如果应用的导通时间相对较短(例如、汽车应用)、ECC 就足以防止单点故障、并且在运行时不太可能发生潜在故障。 但是、如果您的应用是工业应用或其他应用、因此在不进行循环通电的情况下导通时间非常长(天、周、甚至年)、则潜在故障会成为一个问题、因为按需故障的可能性会增加。 在这些情况下、可能需要包括维护周期的概念、在此周期中、设备会在指定的固定时间间隔(一次/一次、每年一次...)下进行功率循环或软复位。 具体取决于应用需求)。 可以说，这一间隔也可被视为定期测试。 同样的概念也适用于 LBIST 执行。

您好！

通过 SafeTI 诊断库测试 TC RAM 的步骤有多个、所有步骤都用"C"语言编写。

您可以调用'C' fcntion 来启动测试(sl_SelfTest_PBIST)、该测试使用堆栈并启动硬件机制。 sl_SelfTest_PBIST 功能概述如下：

1. 在堆栈上保存返回值(链路寄存器)。
2. 初始化 PBIST 机制。
3. 启动 PBIST。
4. 使用栈中的链接寄存器返回到调用方。

sl_SelfTest_PBIST 的开始、请注意将 R14 (链接寄存器)保存到 R13 (堆栈指针)的 STMBD：

/*SAFETYMCUSW 61 D 先生:8.10,8.11. 注释_15*/*SAFETYMCUSW
7 C MR：14.7 备注_3*/*SAFETYMCUSW
62 D MR：16.7 comment_17*/
#if defined (_TMS570LC43x_)|| defined (_RM57Lx_)
boolean SL_SelfTest_PBIST (寄存器 SL_SelfTestType testType、寄存器 uint64 ramGroup、寄存器 UINT32 algoInfo)
#else
sl_SelfTest_PBIST (寄存器 SL_SelfTestType testType、寄存

器 Uint32 ramGroup、#int32 Uturbolean D32 ramInfo
stmdb R13！、｛R2-R8、R14｝
> 0x0000ADB8：E1A04000 MOV R4、R0
> 0x0000ADBC：E1A07001 MOV R7、R1
> 0x0000ADC0：E1A06002 MOV R6、R2

sl_SelfTest_PBIST 的末尾、请注意 LDMIA、将链接寄存器从 R13 (堆栈指针)直接恢复到 R15 (程序计数器)以返回给调用方：

/*启动 PBIST */
/*注意：如果在 TCM RAM 上执行、堆栈内容会损坏、因此请小心处理返回数据*/
/*SAFETYMCUSW 440 S MR :11.3. 注释_18*/
SL_pbistREG->DLR =(PBIST_DLL_DLR4 | PBIST_DLL_DLR2)；
0x0000AED4：E3A0C014 MOV R12、#0x14
0x0000AED8：E585C000 结构 R12、[R5、#0x0]
0x0000AEDC：E8BD81FC LDMIA R13！，{R2-R8, R15}...

RetVal = true；
中断；
默认值：
/*此处无-请注意避免 Misra-c 警告*/
中断；
｝
#if (FUNC_RESULT_LOG_ENABLED = 1)
SL_Log_Result (FUNC_ID_ST_PBIST、testType、(sl_SelfTest_Result) RetVal、0U)；
#endif
返回(返回值)；
｝ 

这清楚地表明在硬件测试启动后正在使用堆栈。 现在、我确信您会认为测试在堆栈返回之前只有很小的可能性损坏了堆栈、这是最相似的(尽管设计很差)、 但还有另一个"C"函数需要轮询以获取结果、sl_SelfTest_Status_PBIST、它也使用堆栈。

再说一次、 sl_SelfTest_Status_PBIST 的开始、请注意将 R14 (链接寄存器)保存到 R13 (堆栈指针)以返回给调用方的 STMBD：

/*SAFETYMCUSW 61 D 先生:8.10,8.11. 注释_15*/*SAFETYMCUSW
7 C MR：14.7 Commone_3*/
布尔 SL_SelfTest_Status_PBIST (SL_PBIST_FailInfo* param1)
｛
0x0000A594：E92D4038 stmdb R13！、｛R3-R5、R14｝
0x0000A598：E1A04000 MOV R4、R0
布尔值 RetVal = false；
布尔值 tmp；
#ifdef function_param_check_enabled
/*LDRA_INSPECTWINDOW 50 */
/*SAFETYMCUSW 439 S MR：11.3 注释_4*/
/*SAFETYMCUSW 439 S MR：11.3 注释_4*/ 

sl_SelfTest_Status_PBIST 的末尾、请注意 LDMIA、 将链接寄存器直接恢复到 R15 (程序计数器)以返回给调用方：

#if (FUNC_RESULT_LOG_ENABLED = 1)
/*SAFETYMCUSW 440 S MR :11.3. 注释_18*/
SL_Log_Result (FUNC_ID_ST_PBIST_STATUS、(SL_SelfTestType) 0、param1->stResult、0U)；
#endif
｝
RetVal = true；
返回 RetVal；
0x0000A660：E3A00001 MOV R0、#0x1
0x0000A664：E8BD8038 LDMIA R13！，{R3-R5,R15}...}

因此，再次澄清我对这一机制的关切：

在测试运行时、测试状态由"C"函数轮询、该函数使用的堆栈被正在运行的硬件测试损坏。

我不理解您的评论"另一种方法、您可以将数据复制到未使用外设的 RAM 中"。 这是"C"运行时系统正在使用的堆栈、如何将其保存到外设存储器中、堆栈用于每个函数调用！

在安全手册中、通过调用 sl_SelfTest_PBIST 来覆盖 RAM7A 和 RAM7B 的饱和情况并非正确。

SafeTI 诊断库中的演示应用甚至不会使用任何 ESRAM 枚举字面量调用 sl_SelfTest_PBIST、我猜这是因为它只是崩溃！

如果我对整个"C"运行时机制以及 sl_SelfTest_PBIST 和 SL_SelfTest_Status_PBIST 的实现感到不满意、请向我提供一个示例、说明如何使用安全手册中描述的机制在 TCRAM 上运行测试。

Mark、您好！

堆栈问题是已知问题。 代码中甚至有一条注释、表示必须注意函数的返回值。 尽管如此、将其作为函数调用实际上并不是一种可取的情况、因为它仍将使用栈、正如您所指出的、对日志记录函数的调用会在有问题的实现之外增加更多的问题。 为此、我们提出了一个 CQ TT、以便在下一个版本中解决问题。

我之前的评论是、被调用的函数可能被声明为内联函数、这将消除栈使用、并且器件上的其他 RAM 可能用于备份数据。 我还指出，对于任何运行时相关信息来说，这是很难实现的。 对于在引导时调用此函数的情况、您当然可以在实例化 PBIST 之前将堆栈备份到其中一个 RAM 位置、然后在返回之前将其恢复(在确保 PBIST 执行不在进行之后)。

请注意、您的第二个示例不是栈问题、因为此函数 sl_SelfTest_Status_PBIST 仅访问寄存器并返回状态。 在调用此函数期间、PBIST 将/不应处于活动状态、否则它将不会返回正确的状态更新。

关于安全手册、我知道您现在参考的是 SafeTI 诊断库安全手册、而不一定是器件安全手册。 我认为其目的是使该函数满足 PBIST 的引导或定期执行。 当然、引导时间执行可能需要一定的注意。 除非您计划启动热复位或其他一些定期启动的"重新启动"、否则定期执行将会非常困难。 对于长期需要使用 RAM 的情况、我们依赖于 ECC 和它的辅助诊断以及 RAM 位复用实现来保护存储器内容。 即、RAM 中的几乎所有错误都是一位错误、ECC 将即时纠正这些错误、而不会对应用程序产生影响。

Mark、您好！

显然、您感到沮丧、我知道这也花了一些时间来查看代码。 是的、代码是一个问题、需要维修。 这就是为什么我说它有一个待在下一个版本中修复的未决 TT 的原因。

在没有对软件进行任何进一步解释或解释的情况下、我相信您选择像您所做的那样实施引导时间 PBIST 是实现它的最佳方法、并且与我们在将它确定为安全机制时所拥有的愿景非常吻合。

我对安全诊断库中 PBIST 实施过程中的混乱和任何不好的思考可能会给您造成的不便深表歉意。