[参考译文] TMDS570LS31HDK：CPU SelfTest 覆盖、SafeTI SRAM 中止集成、闪存故障计算问题。

您好！

Unknown 说：

CPU 自检/STC 测试的测试覆盖范围是多少？ [/报价]

器件数据表和 TRM 中列出了 CPU 自检和 STC 自检覆盖范围。 如果使用全部25个间隔、则覆盖率为90.21%。 CPU 自检使用 LBIST 控制器作为测试引擎来测试 ARM - CPU 内核逻辑。

Unknown 说：

SL_SelfTest_SRAM SRAM_ECC_error_forcing_2bit test

这是 SDL 的 SRAM 自检 API 选项。 如果使用 SDL、则不应使用 HALCOGen 生成的自检函数。 带有故障注入的自检将特意生成错误、应在错误处理程序中手动清除该错误。

Unknown 说：

SL_SelfTest_FEE FEE_ECC_SYN_REPORT_MODE 测试、[/报价]

计算出的故障应该是正确的。 我将检查测试用例。

[/quote]

您好、QJ：

Kelvin Tse 说：

Robin S 说:

CPU 自检/STC 测试的测试覆盖范围是多少？

器件数据表和 TRM 中列出了 CPU 自检和 STC 自检覆盖范围。 如果使用全部25个间隔、则覆盖率为90.21%。 CPU 自检使用 LBIST 控制器作为测试引擎来测试 ARM - CPU 内核逻辑。

[/报价]

我应该更清楚一些-我确实查阅了数据表、看到了涵盖这类内容的表格、但我不确定这实际上涵盖了什么内容？ CPU 上的 LBIST 正在运行哪些测试？ 实际测试的是 ARM-CPU 逻辑的哪些部分？ 延长间隔时间如何导致覆盖范围增加？

Kelvin Tse 说：

Robin S 说:

SL_SelfTest_SRAM SRAM_ECC_ERROR_CHRING_2bIT 测试

这是 SDL 的 SRAM 自检 API 选项。 如果使用 SDL、则不应使用 HALCOGen 生成的自检函数。 带有故障注入的自检将特意生成错误、应在错误处理程序中手动清除该错误。

[/报价]

在这种情况下、SDL 的预期用途是什么？ SDL 的示例项目始终集成在 HALCoGen 中，据我所知，HALCoGen 中内置的`checkRAMECC()`测试不能通过代码生成来禁用(使用`#if 0`对于我们的认证证明是不可接受的)。 即便如此、 如我的原始问题中所述、修改错误处理程序以清除错误会干扰其他启动测试。

终端用户应如何确定适当的外设自检覆盖范围？ 我已经浏览过 SDL 用户指南和 TI Hercules 安全手册、两者都没有使用一致的术语、我认为它们都没有提供足够的信息来实际确定这些测试的效果。 SDL 和 HALCoGen 测试的实施并不相同且相互排斥、所以用户应该如何知道哪一个测试的实施是"正确的"？ 正如许多 TI 成员在此论坛上所说、要让设计人员了解该规范的作用、但相关文档不足以提供相关支持。 对于认证申请、我们不能简单地说测试的最终结果证明了方法的合理性、我们必须证明包括 SDL 代码在内的特定实施的合理性。 除了选择两个测试中的一个之外、如果能够进行澄清、我将不胜感激。

Kelvin Tse 说：

Robin S 说:

SL_SelfTest_FEE_ECC_SYN_REPORT_MODE 测试、

计算出的故障应该是正确的。 我将检查测试用例。

[/报价]

有任何更新吗？

感谢您的答复 QJ。

[/quote]

[/quote][/quote]

LBIST 测试运行于 CPU (包括 MPU、FPU)的数字逻辑上。 它可用于检测 CPU 中晶体管级别的潜在故障。  LBIST 间隔不针对 CPU 内的任何一个元件、由运行周期确定。  这个时间分片测试特性使得 LBIST 能够被有效地用作一个运行时间诊断、 此诊断可以根据安全关键环路执行测试时间片、也可以作为一个在 MCU 初始化期间对 CPU 逻辑故障的综合性测试。

HALCoGen 是最低的软件层。 它包含能够直接访问 MCU 的软件模块、负责系统初始化。 SDL 集合了多种功能、用于访问各种安全机制的安全功能和响应处理程序。  SDL 支持与器件安全手册和 FMEDA 电子表格中描述的安全机制的一对一映射。  

FMEDA 列出了所有片上诊断和安全机制、您还可以查看启用/禁用任何诊断或安全机制对整体诊断覆盖率数字的影响。 通过电子表格、您还可以定制 FMEDA 每个引脚的使用情况、模块使用情况或安全机制使用情况。

Kelvin Tse 说：

它可用于检测 CPU 内晶体管级别的潜在故障。  LBIST 间隔不针对 CPU 中的任何一个元素、由操作周期决定。[/引号]

我明白了。 解释是否正确、那么此测试应涵盖 CPU 检测故障的能力？ 即、如果此测试通过、这是否能保证 CPU 始终能够检测到数据中止？  

此外，是否有任何关于 FEE 综合征计算的更新？ 谢谢！

Unknown 说：

是否正确解释此测试应涵盖 CPU 检测故障的能力？

是的、CPU LBIST +锁步(逐周期检查)提供了非常高的测试覆盖范围。

Unknown 说：

此外，是否有任何有关费用综合征计算的更新

您能告诉我您在哪里得到 计算出的综合征吗？

Kelvin Tse 说：

您能告诉我在哪里得到 计算出的综合征吗？

我将调用以下代码：

/* Run Flash EEPROM ECC Syndrome Reporting test. */
slRet = SL_SelfTest_FEE(FEE_ECC_SYN_REPORT_MODE, true, &failInfoFlash);
if ( (slRet != true) || (failInfoFlash != ST_PASS) ) {
    return false;
}

计算发生在 sl_selftest.c 第1598行：

syndrome = ecc ^ sl_flashWREG->FEMUECC;

计算出的故障为0x0 (右上角)。  

这与从 sl_flashWREG->FEMUECC (右上角)中计算出的0x45综合征不匹配


不确定我是否错过了设置步骤或类似步骤、以导致此差异。

请将行#1589更改为：

    ECC =(uint8)(sl_flashWREG->FEMUECC 和0xFF)；

您好、QJ：

Kelvin Tse 说：

请将行#1589更改为：

    ECC =(uint8)(sl_flashWREG->FEMUECC 和0xFF)；

[/报价]

我认为这没有影响。 通过单步执行该程序、我发现即使在调用测试之前 FEMUECC 寄存器的值也是0x45。 即使我们在1584-1587行加载 FEMU 寄存器、此值也不会更改

/*load FEMU_XX regs in order to generate ecc and use it for next operations*/
sl_flashWREG->FEMUADDR = (uint32)ADDR_DATA_MSW;
fdiagCtrl |= F021F_FDIAGCTRL_DMODE_SYN_RPT;
sl_flashWREG->FEMUDMSW = FEE_TEST_DATA;
sl_flashWREG->FEMUDLSW = FEE_TEST_DATA;

由于 FEMUECC 寄存器不会更改值、因此 ECC 存储为0x45。 因此、当`综合征时、综合征变为`0x45 ^ 0x45 μ s、结果变为0。

我对 FEE ECC 还不是很熟悉、还不知道这个寄存器是如何设置的。 在调用该函数之前、我是否错过了配置或清理步骤？ 该 ECC 寄存器值何时应更改？

Kelvin Tse 说：

Robin S 说:

解释是否正确、那么此测试应涵盖 CPU 检测故障的能力？

是的、CPU LBIST +锁步(逐周期检查)提供了非常高的测试覆盖范围。

[/报价]

谢谢您的讲解。 您能详细说明一下测试覆盖的含义吗？ 低覆盖率和高覆盖率之间的区别是什么？ 我知道 LBIST 不是软件、但是否有某种文档介绍 LBIST 实际执行什么来测试 CPU？  

[/quote]

我认为该语句会将  sl_flashWREG->FEMUECC 的高位字节、即0x0分配 给 ECC。

1.sl_flashWREG->FEMUADDR =(UINT32) ADDR_DATA_MSW；
  sl_flashWREG->FEMUDMSW = FEE_TEST_DATA；
  sl_flashWREG->FEMUDLSW = FEE_TEST_DATA；

  地址= 0xF020_0000、数据= 0x0000_0000_0000、ECC=0x45

2. sl_flashWREG->FEMUADDR =(UINT32) ADDR_DATA_MSW；
  sl_flashWREG->FEMUDMSW = FEE_TEST_DATA；
  sl_flashWREG->FEMUDLSW = FEE_TEST_DATA ^ BIT (FEE_ERROR_POS)；

  地址= 0xF020 _0000、数据= 0x0000_0000_0000_0004、ECC = 0xA3

综合征= 0x45 ^ 0xA3 = 0xE6

诊断覆盖是危险检测故障与危险故障总数的比率、以百分比表示。

请参阅 FMEDA 和 详细安全分析报告。

Kelvin Tse 说：

我认为该语句将  sl_flashWREG->FEMUECC 的高字节(0x0)分配 给 ECC。

如果这是该声明的目标、我认为它应该是  ECC =(uint8)(sl_flashWREG->FEMUECC & 0xFF00)；或其他。 FEMUECC 在启动时已经为0x45、因此0x45 & 0xFF = 0x45。 如果我们希望 FEMUECC 在函数输入时为0、那么就是这个问题、因为目前还不是这样：



是否需要对 SL FEE 功能进行清理？ 我目前正在连续调用几个:


至于逐步介绍函数：
1.sl_flashWREG->FEMUADDR =(UINT32) ADDR_DATA_MSW；
  sl_flashWREG->FEMUDMSW = FEE_TEST_DATA；
  sl_flashWREG->FEMUDLSW = FEE_TEST_DATA；
  ECC =(uint8)(sl_flashWREG->FEMUECC 和0xFF)；

地址= 0x0020_0000、数据= 0x0000_0000_0000、FEMUECC = ECC=0x45

2.  sl_flashWREG->FEMUADDR =(UINT32) ADDR_DATA_MSW；
  sl_flashWREG->FEMUDMSW = FEE_TEST_DATA；
  sl_flashWREG->FEMUDLSW = FEE_TEST_DATA ^ BIT (FEE_ERROR_POS)；
   综合征= ECC ^ sl_flashWREG->FEMUECC；

地址= 0x0020_0000、数据= 0x0000_0000_0004、FEMUECC = 0x45、ECC = 0x45、综合征= 0x45 ^ 0x45 = 0x0

在我看来，当我们更新 FEMUD*寄存器时 FEMUECC 似乎没有更新。 不过、不确定为什么会这样。

Kelvin Tse 说：

诊断覆盖是危险检测故障与危险故障总数的比率、以百分比表示。

[/报价]

如果它是检测到的危险特征的比率,就不会90.21%的覆盖率意味着90%可能发生的故障?   

Kelvin Tse 说：

请参阅 FMEDA 和 详细安全分析报告

它们位于何处？ 我在 MCU 或 HDK 页面上看不到它们： https://www.ti.com/product/TMS570LS3137?keyMatch=TMS570LS3137#all https://www.ti.com/tool/TMDS570LS31HDK 

[/quote]

Unknown 说：

这些地址在哪里？ [/报价]

这些文档受 NDA 控制。 贵公司是否就敏感信息与 TI 签订了 NDA？

Unknown 说：

在我看来，当我们更新 FEMUD*寄存器时，FEMUECC 似乎没有更新。 但不确定为什么会这样。

我几天前运行测试、 FEMUECC 每次都会更新。

Kelvin Tse 说：

这些文档受保密协议控制。 贵公司是否就敏感信息与 TI 签订了 NDA？

此时我们不做。 我们如何获得它？