[参考译文] RM48L952：SafeTI：闪存错误强制测试不会生成错误或返回设置

admin

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/602739/rm48l952-safeti-flash-error-forcing-tests-does-not-generate-errors-nor-return-settings

器件型号：RM48L952

您好！

也试图通过 emai 23.5问这个问题，没有答案。

测试类型 FLASH_ADDRESS_ECC_FAULT_INject：

应生成 ESM_G3ERR_FMC_Uncorr 错误

-这确实会产生任何故障、请参阅代码行1240-1246如果不包括故障注入测试、实际故障生成就会滞后

#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)

if ((flash_ecc_test_mode_2BIT_FAULT_Inject！= testType)&&(flash_address_ecc_fault_inject！= testType))

#endif

#if defined (_TMS570LC43x_)|| defined (_RM57Lx_)

if (flash_ecc_test_mode_2BIT =testType)

#endif

｛

因此最终结果是、某些寄存器会被反向更新和更改、但不会返回(因为返回的 IF 后面是相同的 IF)。

regBkupFPUVr = sl_flashWREG->FPAROVR；

sl_flashWREG->FPAROVR |= F021F_FPAROVR_SYN_ADDRE_ECC；

à if 语句应排除以恢复该反向值

DATA_ABORT 或 ERROR 引脚操作不会生成 μ… 那么、该测试不会测试任何东西？？？

因此、基本上通过运行此测试、您的 sl_flashWREG->FPAROVR 寄存器值已损坏、就是这样–这不能是此测试的点…

===================================

测试类型 FLASH_ADDRESS_奇偶校验_FAULT_INject：

代码无法从 ESM_HIGH 中断 SL_ESM_HIGH_intr_handler ()返回、问题与 FLASH_ADDRESS_奇偶校验_self_test 中的问题相同
https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/602737

看起来像 SafeTI ESM 处理程序代码设置 sl_flashWREG->FPAROVR = 0x5400U；在 if regular test (FLASH_ADDRESS_奇偶校验_自检)中

尝试在 ESM_application_callback 中设置该值、但这不起作用–是否应该设置该值、如果是、那么为什么 SafeTI ESM 处理程序也没有为此测试类型设置该值？如果返回 SafeTI-test 代码将起作用、则会恢复备份(实际上不会、请参阅下面的内容) 但对于非故障注入测试、它所做的就是魔法编号0x5400实际上完全需要中断、或者它是否应该以某种方式消除错误生成、从而必须在 ISR…中执行

此外、这些也位于 if (flash_address_parity、fault_inject！= testType)后面

/*清除诊断模式设置*/

sl_flashWREG->FPAROVR = regBkupFPUVr；

sl_flashWREG->FDIAGCTRL = regBckupFdiagctrl；

因此、如果测试不起作用、则返回 SafeTI 后寄存器会损坏…

if 语句现在应排除这些值、寄存器值在从 SafeTI 代码返回后损坏

===================================

测试类型 FLASH_ECC_TEST_MODE_2BIT_FAULT_Inject：

由于存在相同的防护装置、因此问题与 FLASH_ADDRESS_ECC_FAULT_INject 中的问题完全相似

===================================

因此、设法在运行时运行以下测试(当未启用 FIQ 时、所有5个正常的非故障注入测试在启动阶段工作)
FLASH_ECC_TEST_MODE_1位

FLASH_ECC_TEST_MODE_2BIT

FLASH_ECC_ADDR_TAG_REG_MODE

FLASH_ADDRESS_ECC_SELF 测试

但无法运行：

FLASH_ADDRESS_奇偶校验_self_test

FLASH_ADDRESS_ECC_FAULT_INject

FLASH_ADDRESS_奇偶校验 FAULT_INject

FLASH_ECC_TEST_MODE_2BIT_FAULT_INject

===========================================

8 年多前

0 admin 8 年多前

TI__Guru**** 2337880 points

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

在我首次为其修复实际测试后、设法获得 FLASH_ADDRESS_奇偶校验_FAULT_INject 测试运行
e2e.ti.com/.../602737

这需要修改 sl_ESM.c、这个 FPAROVR 本来也可以在 ESM-callback 中完成、但是由于它是操作值的 SafeTI 测试、所以它也应该对其进行操作。此外、如果此处删除了 DIAGNOSTICS 密钥、则不会再次弹出 SR[1]位、如注释中所述。
案例 ESM_G2ERR_FMC_Uncorr：
if (true = sl_FLAG_GET (FLASH_ADDRESS_奇偶校验_自_测试))｛
sl_flashWREG->FPAROVR = 0x5400U；
callbackCancelCount++；
CancelCallback = true；
｝

if (true = sl_FLAG_GET (FLASH_ADDRESS_奇偶校验_FAULT_INject))｛
SL_flashWREG->FPAROVR = 0x5400U；//注意：JSI：如果没有此错误、则会不断生成-如果此处不需要针对 SR[1]的手动 CH ack
｝

此外、这个闭合支架应该在寄存器备份恢复之前、这样、尽管存在故障注入测试、设置仍然被恢复(在链接线程中、在故障注入检查之前、FPAROVR 在错误生成后立即被恢复、所以基本上这个变化是装饰的...
/*始终清除闪存和 ESM 状态寄存器*/
SL_flashWREG->FEDACSTATUS = F021F_FEDACSTATUS_ADD_PAR_ERR；
sl_esmREG->SR1[1]= GET_ESM_bit_NUM (ESM_G2ERR_FMC_Uncorr)；
sl_esmREG->SSR2 = GET_ESM_BIT_NUM (ESM_G2ERR_FMC_Uncorr)；
flashread = sl_flashWREG->FUNCHERRADD；
｝

/*清除诊断模式设置*/
sl_flashWREG->FPAROVR = regBkupFPUVr；
sl_flashWREG->FDIAGCTRL = regBckupFdiagctrl；

===========================

此外、还注意到 TRM 中的另一个文档错误、在表5-43中、对于 PAR_OVR_KEY 而言、这是一个说法
“当此值为“101”时，选定的 Add_INV_PAR 和 DAT_INV_PAR 字段将变为活动状态。”

这是否意味着启用密钥没有任何其他影响、当然不会因为在 PAR_OVR_KEY 中所述的内容在 BNK_INV_PAR 中立即解出、因为对于该位、这是说的
'当该值为1且 PAR_OVR_KEY 为‘101’时，在进行组奇偶校验计算时，当前系统奇偶校验信号 SYS_OD_奇偶校验被反转。'

因此、看起来 PAR_OVR_KEY 会激活全部3个(ADD_INV_PAR、DAT_INV_PAR 和 BNK_INV_PAR)、而不是字段说明中所述的2个...
===========================

还注意到 FLASH_ADDRC_SECC_SECC_SELF 永远不会被置为活动状态，在该测试期间，FLASH_ECC_TEST_MODE_2BIT 被标记为活动状态：)。

这是 SafeTI 代码、如在 RM48分支中所示、如果测试不是故障注入、则会进入该分支(void) SL_FLAG_SET (FLASH_ECC_TEST_MODE_2BIT)；尽管测试、但仍会调用...

/*flag 被设置为指示正在进行的当前测试和
这些标志被用在 sl_ESM.c 中以屏蔽 ESM 回调*/
#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
if ((flash_ecc_test_mode_2BIT_FAULT_Inject！= testType)&&(flash_address_ecc_fault_inject！= testType))
#endif
#if defined (_TMS570LC43x_)|| defined (_RM57Lx_)
if (flash_ecc_test_mode_2BIT =testType)
#endif
｛
#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
(空) sl_FLAG_SET (FLASH_ECC_TEST_MODE_2BIT)；
#endif

演示应用是什么？它从不检查 FLASH_ADDRC_SECC_SECC_SEퟔ_测试是否处于活动状态它仅检查 FLASH_ECC_TEST_MODE_2BIT、如果您在 SafeTI 端修复该活动标志、则此中止处理程序会立即中断... 如果您添加了当前正在运行的测试的辅助应用侧标签、并且您在异常处理程序中检查了 SL_FLAG_GET、因为错误的测试被设置为活动状态、则这也不起作用...

#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
/*由于闪存包装程序测试而导致的 DAbort？ *
if (((TRUE =sl_FLAG_GET (FLASH_ECC_TEST_MODE_2BIT))))||(TRUE =SL_FLAG_GET (FLASH_ECC_ADDR_TAG_REG_MODE))))
｛
#if !optimization_enabled/*由于优化行为错误而需要*/
sl_flashWREG->FDIAGCTRL &= 0xFFF0FFF8；//清除诊断使能键*/
#endif

maskDAbort = true；
｝

===========================

进行其他故障注入测试
FLASH_ECC_TEST_MODE_2BIT_FAULT_INject
FLASH_ADDRESS_ECC_FAULT_INject

如果阻止故障注入、甚至会产生第一个 POST 中所述的错误、则情况也是如此
#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
if ((flash_ecc_test_mode_2BIT_FAULT_Inject！= testType)&&(flash_address_ecc_fault_inject！= testType))
#endif
#if defined (_TMS570LC43x_)|| defined (_RM57Lx_)
if (flash_ecc_test_mode_2BIT =testType)
#endif
｛

因此、在考虑运行这2个测试之前、您需要立即再次修改 SafeTI 代码、以便它生成这些错误。这意味着基本上会将这些 IF 在代码中的值降低得多

===========================

演示应用中也存在奇怪的情况
#if optimization_enabled =0U /*由于优化行为错误而需要*/
SL_flashWREG->FDIAGCTRL &= 0xFFF0FFF8U；//清除诊断使能键
#endif

在优化启用仅在 TI_Compiler 不用于 IAR 的情况下产生影响的代码的其他部分中、该错误处理代码部分在使用 IAR 时如何根据该优化标志运行、因为该标志对任何其他内容都没有任何影响、因此、基本上、基于 IAR 代码、尽管诊断密钥将被清除或不被清除、系统仍能正常工作。。

在演示应用的其他部分、有人说在这种特定情况下、可以清除密钥或让其看起来像、Crazy 这不应该是可选选项、另一个肯定比其他更好、应该选择它...
/*尽管没有必要，但关闭诊断模式*/
SL_flashWREG->FDIAGCTRL &= 0xFFF0FFF8U；//清除诊断使能键

不应尽快删除诊断密钥、以防止出现类似 FLASH_ADDRESS_奇偶校验_FAULT_INject 测试(此消息的第一部分)中出现的错误、如果您在第一个 FIQ 处理程序中删除类似的密钥、则错误不会再次引起、这将需要额外的手动处理、并且可能会屏蔽一些同时发生的实际错误...

=====

挖掘和修复后的当前状态：这些测试看起来正常：
FLASH_ECC_TEST_MODE_1位
FLASH_ECC_TEST_MODE_2BIT
FLASH_ECC_ADDR_TAG_REG_MODE
FLASH_ADDRESS_ECC_SELF 测试

FLASH_ADDRESS_奇偶校验_self_test
FLASH_ADDRESS_奇偶校验 FAULT_INject

但无法运行(可能是明天在经过修改后)：
FLASH_ADDRESS_ECC_FAULT_INject
FLASH_ECC_TEST_MODE_2BIT_FAULT_INject

0 admin 8 年多前

TI__Guru**** 2337880 points

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

运行其余2个故障注入测试、仅需移动 if 语句、以便 DIAG_TRIG 和标志由测试类型设置、而不是固定 FLASH_ECC_TEST_MODE_2BIT、导致错误的地址读取在故障注入检查之前进行 (还添加了诊断恢复、因为实际测试再次将这些设置为第二轮...

/*flag 被设置为指示正在进行的当前测试和
这些标志被用在 sl_ESM.c 中以屏蔽 ESM 回调*/
#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
(void) sl_FLAG_SET (testType)；
#endif
#if defined (_TMS570LC43x_)|| defined (_RM57Lx_)
/*必须从 RAM 运行测试-无法执行函数 sl_FLAG_SET
*从闪存复制功能。 *
extern 布尔 sl_priv_flag_set[]；
sl_priv_flag_set[testType-TESTTYPE_MIN]= true；
#endif

#if function_profiling_enabled
sl_Record_Errorcreationtick (testType)；
#endif

sl_flashWREG->FDIAGCTRL |= F021F_FDIAGCTRL_DIAG_TRIG；

/*SAFETYMCUSW 58 S MR:14.3. 注释_16*/
flashread =*(volatile UINT32 *) flashBadECC2；

SL_flashWREG->FDIAGCTRL &=~F021F_FDIAGCTRL_DIAG_TRIG；//立即删除以防万一

#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
if ((flash_ecc_test_mode_2BIT_FAULT_Inject！= testType)&&(flash_address_ecc_fault_inject！= testType))
#endif
#if defined (_TMS570LC43x_)|| defined (_RM57Lx_)
if (flash_ecc_test_mode_2BIT =testType)
#endif
｛

在本例的末尾、修改代码以使标志按测试类型清除、而不是固定 FLASH_ECC_TEST_MODE_2BIT 并移动"｝"、以便在发生故障注入时也恢复寄存器备份

｝
/*清除诊断模式设置*/
#if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
sl_flashWREG->FPAROVR = regBkupFPUVr；
#endif
sl_flashWREG->FDIAGCTRL = regBckupFdiagctrl；

/*清除指示测试正在进行的标志*/
sl_FLAG_CLEAR (testType)；

================================================================
感谢您的支持：)！
================================================================

还想知道用户手册为什么说：
注意：对于 FLASH_ECC_TEST_MODE_2BIT_FAULT_INject、故障将在应用程序随后对损坏的闪存区域的读取中注入。应用程序必须注意恢复闪存诊断控制寄存器。

由于在原始代码中未设置 TRIG 位、因此无论应用程序读取什么内容以及读取多少内容、都不会出现任何类型的错误... 基于原始代码、FLASH_ECC_TEST_MODE_2BIT_FAULT_INP注入和 FLASH_ADDRC_FAULT_INPIT 完全相同、但 FPADROVR 设置不同。为什么注释中仅提到其他测试？？？

为什么在这种情况下、一个测试应用程序应该恢复闪存诊断控制寄存器、应该在数据中止处理程序中恢复闪存诊断控制寄存器？如果是、那么为什么实际测试不清除它(在演示应用中也不是用户手册中所要求的)。实数测试会重新启用该寄存器、这在某种程度上表明它可能在某个位置应始终关闭(在数据中止处理程序中？)

这是重新启用
/*对不同的地址重复测试以确保 FCORERRADD 寄存器已正确更新*/
/*SAFETYMCUSW 58 S MR:14.3. 注释_16*/
sl_flashWREG->FDIAGCTRL = fdiagCtrl；
sl_flashWREG->FDIAGCTRL |= F021F_FDIAGCTRL_DIAG_TRIG；
flashread =*(volatile UINT32 *) flashBadECC1；

这里是演示应用程序的异常处理程序(仅当此条件编译标志具有特定值时才调整诊断控制寄存器...
if (((TRUE =sl_FLAG_GET (FLASH_ECC_TEST_MODE_2BIT))))||(TRUE =SL_FLAG_GET (FLASH_ECC_ADDR_TAG_REG_MODE))))
｛
#if !optimization_enabled/*由于优化行为错误而需要*/
sl_flashWREG->FDIAGCTRL &= 0xFFF0FFF8；//清除诊断使能键*/
#endif

maskDAbort = true；
｝

请教育我、因为我显然错过了一些东西(最可能是关键的)... 我假设应该始终关闭此诊断控制键(在数据中止中)、以防但在演示应用中未完成...

=====

现在每次闪存测试都在运行、缺点是我需要修改几行 SafeTI 代码(好吧、这不是第一次)...

0 admin 8 年多前

TI__Guru**** 2337880 points

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

在 DATA_ABORT 处理程序中对所有闪存执行了两个寄存器内容检查(FDIAGCTRL 和 FPAROVR)。我认为这些检查应该到位、以便在只有部分设置完成时发生一些实际错误时、任何中止都不会被错误屏蔽。

出于同样的原因、应调整 SafeTI、以便在错误生成行后尽快恢复这些寄存器的内容、这样集成商就可以真正确保错误屏蔽的时隙尽可能小。

此外、当发现呼叫最有可能源自 SafeTI 并被屏蔽时、可能应在数据中止中操作寄存器内容、以防止在内容恢复到 SafeTI 之前发生实际错误时屏蔽多个呼叫。 SafeTI 的用户和安全手册中未提及此类行为或需求。

根据演示应用和 SafeTI 手册、似乎根本没有想到实际错误可能会被意外屏蔽、这肯定会在演示应用中发生。

实际上、这种尽快检查和修改寄存器内容的操作应该由 SafeTI 代码提供、而不是让集成商需要确定这些测试的实际功能...
e2e.ti.com/.../603064

基本上、现在已经检查了在 FDIAGCTRL 中"模式"和"键"是否符合预期(三位具有自动清除功能、因此无法检查该功能)、并且在除 ADD_TAG_MODE 之外的其他测试中、FPAROVR 也具有适当的内容 (请注意、FLASH_ADDRESS_奇偶校验_self_test 会在"错误生成中止"之前手动清除 FIQ 处理程序中的内容、因此当输入中止时、该测试必须具有0x5400 (e2e.ti.com/.../602737)))

===================================
还注意到(再次)在进行测试时、在查找准确设置的寄存器时、一些有趣的变量命名、为什么在地球上，有些人的名字中有“FDIAGCTRL”和一些“FDICTRL”，而所有的值都要用在寄存器 FDIAGCTRL 中的同一个字段中：)，则进行了审核？
#define F021F_FDCTRL_DMODE_DATA_COR (uint32) 0x00000001U
#define F021F_FDIAGCTRL_DMODE_SYN_RPT (uint32) 0x00000002U
/*宏名称已更改，以符合 MISRA 规则 MISRA-C：2004 5.1 */
#define F021F_FDIAGCTRL_DMODE_MALFUNF1(uint32) 0x00000003U
/*宏名称已更改，以符合 MISRA 规则 MISRA-C：2004 5.1 */
#define F021F_FDIAGCTRL_DMODE_MALFUNT2(uint32) 0x00000004U
#define F021F_FDIAGCTRL_DMODE_ADDR_TAG (uint32) 0x00000005U
#define F021F_FDCTRL_DMODE_P_BUF_PAR (uint32) 0x00000006U

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

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

[参考译文] RM48L952：SafeTI：闪存错误强制测试不会生成错误或返回设置