[参考译文] RM48L952：SafeTI：根据 TRM 使用说明处理错误引脚复位

您好、Jarkko、

我对迟迟不答复这一问题表示歉意。 我目前正在研究软件实施和 TRM 中注释的来源、以确定差异的影响。 我将在今天晚些时候或在科技委明天上午作出初步答复/更新我的调查结果。

您好！

首先、在继续之前：我认为您混合了2个不同的测试(CCMR4F_ERROR_UARGET_TEST 和 CCMR4F_SELF TEST_ERROR_PRUAR强制)、在最初检查此结果时、我也多次混合了这些测试(在进行其他测试时、许多测试名称彼此非常接近)。 第一个是组2测试、第二个是组1测试。 组2测试正常。

从 SafeTI 代码：
案例 CCMR4F_self_test_error_强 励：
(笑声)
if (get_ESM_bit_NUM (ESM_G1ERR_CCMR4_selftest)==(sl_esmREG->SR1[0]和 get_ESM_bit_NUM (ESM_G1ERR_CCMR4_selftest)))(
                config->stResult = ST_PASS；
            ｝

看到它是 G1ERR、您能确认吗？


[引用 user="Chuck Davenport"]i'v 查看了相关代码。 我不认为此代码违反了 TRM 中的注释。 TRM 中的注释适用于在错误被置为有效之前清除 nERROR 引脚、如以下摘录中所述。
由于这是组1测试(其中 nERROR 操作被屏蔽掉)、而不是您上面所针对的组2测试、我仍然认为它违反了(请参阅文章的底部、 我制作了测试代码来证明 TRM 文本是正确的、您必须非常小心地使用此功能。
-在最初的帖子中、我提到这是我发现的唯一组1测试确认 nERROR、其他组1测试不运行错误引脚所有组1 "正常"测试(非故障插入)屏蔽 ISR 和 nERROR 操作 (与其他代码的这种偏差是突然出现在我眼中的"东西"、只有在这之后、我才开始读取 TRM 并找到该示例5)。


[引用 user="Chuck Davenport">另请注意、ESM 和中断寄存器在测试开始时保存(上下文保存)、并在测试结束时恢复 因此、测试完成后、目标是保留客户寄存器配置/状态。
-是的、这是在每次测试中完成的、当然是预期的行为(除了某些故障插入(很可能是由于某些复制和粘贴错误或拼写错误)、 我认为内容应始终返回、因为我在 SafeTI 下进行了所有 FI 测试、但对"｛"和"｝"位置的修改很少)。

[引用 user="Chuck Davenport">我不是100%确定您在这里讨论的内容，但如果标记了错误条件，系统应处理该错误。 从安全角度来看、Hercules 认证基于 HFT = 0、因此不保证处理一个故障或冗余故障堆叠。 了解这可能是一个系统问题、应该对其进行评估/表征、以便在发生单个故障时、系统会响应、将包括 RM48在内的系统置于安全状态。[/引述]
抱歉、我的英语不是母语、您可以随时询问"您的意思"、我会尝试更好地描述它。 正如本文底部所证明的那样、示例5的 TRM 是正确的、因此我开始想知道它是否以某种方式影响到像#4这样的示例、但不像#4那样是1：1。

在某些 SafeTI 测试(例如 RAM 或闪存(FLASH_ECC_TEST_MODE_2BIT))中、测试测试测试会连续测试多个故障(两组)、在测试之间使用_sl_HoldNClear_nError ()。 因此错误引脚升高(在未修改的代码中、无法使用、因为这实际上会阻止 while 应用程序~150us)、然后生成下一个错误。 但测试中的错误生成不会检查错误引脚的状态(仅在函数条目中检查引脚状态)、因此在错误生成之间清除(和忙等待)是"无用的时间浪费"-这只是导致未修改代码中出现额外延迟、可以跳过。

由于~150us 忙等待时间、我不得不用原始(用于启动)或仅设置 EKR = 5 (用于运行时间)的代码替换"_sl_HoldNClear_nError（)"的内容 为了防止忙时等待、以便我们的应用可以在测试结束后等待错误引脚升高时执行其他操作。
-现在根据我的修改、这将产生一种情况、在两次故障生成之间写入 EKR=5 -因此示例4中给出了这两次故障之间的第一次复位和两次故障后的第二次复位。 现在、您已获得我所说的重置模式(故障- ACK (nERROR 在下一次故障发生之前没有时间上升)-故障- ACK？
-由于示例5是真实的、我开始想知道提供这2个复位是否"安全"(因为我不等待引脚在这两个引脚之间上升)、或者我是否应该修改 SafeTI 代码、以便在每次测试中只有一个复位 (因为我必须修改 orinigal 重置函数)-我尝试尽可能避免修改 SafeTI 代码、因为如果有一天发布新版本、如果重新进行可能仍需要的更改、将会非常痛苦 (当然、希望无需任何修改)。
-我假设第二次复位不是"分组/存储供以后使用"、但由于#4仅显示"将重置低电平时间计数器"、我无法确定它是否继续运行、或者它实际上是"重置并停止"、并且需要新的 EKR=5确认才能释放 引脚。 基本上是在两次故障之间给出错误引脚复位的缺失情况示例。

问题：如果在两次故障之间提供了一次复位、则最新故障中的 t_err_low 后的 nERROR 引脚状态是什么？ (我知道即使在 ESM 通道中、也可以应答 nERROR 为活动错误)


我已经执行了故障注入测试、以检查是否存在活动 ESM 错误、以及相关测试是否已配置为控制 nERROR、只有在这种情况下才会确认 ERROR 引脚 (因此、即使在一个 FI 测试已确认其 ESM 通道但忘记 ACK NERROR 的情况下、这也会阻止确认)。 我确实尝试防止我自己代码中的#5出现"意外"攻击... 我们还提供了硬件"锁定"(LATCH)、以防 nERROR 已关闭、如果 nERROR 恢复正常、则不会立即删除安全状态、您需要在 nERROR 恢复后手动释放该锁存器 (但在 nERROR 上升后、我们没有太多时间释放闩锁(因为 nERROR 停机时间至少达到150us (是的、 这在我们的环境中很重要)、为了快速释放锁存器、我们将 nError-pin 连接到 GPIO、以便接收中断(因为 ESM 模块不提供这种 IRQ？) 因此、我们可以在之后立即释放闩锁)。 因此、nERROR 不会自我升高非常重要... 如果可能发生这种情况、我将猜测我需要对锁存器释放实施另一个 SW 防护(例如、检查是否 存在任何 ESM 通道错误处于活动状态或其他情况。 SafeTI 代码的工作方式略有不同、通常(如果不是始终如此) 首先、ACK nERROR 引脚、然后将 ACK ESM 通道错误、因此我无法将"sanity checked nERROR reset"置于 SafeTI 的错误引脚释放函数中、除非我还修改了代码以便首先清除通道错误。

因此、了解 nERROR 的每种情况都非常重要、即 nERROR 会如何提高自身以及它的实际行为、您是否同意？ 我们可能有仅具有 ISR 或仅具有 nERROR 操作(或可能没有任何操作)的通道、具体取决于应用、例如、在我们的案例中、可纠正的 RAM 错误是很好的记录、但由于代码/CPU 仍然按设计工作、我们不希望触发 nError... 可能还有一些其他错误、可能是只有 nERROR 操作的错误(无法立即找出用例、 但这可能是配置)、根据系统中的其他机制、如果 nERROR 以"自身"的方式恢复运行(在 SW las 中的错误跟踪中、其本身=错误、请按照示例5#)、这可能会导致严重问题。

问题：如果 t_err_low 计数停止(&寄存器值已重置) 当发生故障时、我们不必担心连续错误、但如果 t_err_low 值仅重置 nERROR 引脚、则会升高、以防它曾被攻击一次、之后在 t_err_low 窗口期间出现一些实际错误 (这不是示例5、因为5中给出了复位时的引脚为向上计数)。
-在最终的情况下，第二个确认是“被偷”的，即使是 这样，系统的运行就像示例5中一样(但我怀疑是这样)


===此处是经证实为实例5#===

代码和调试日志证明 TRM 示例#5是正确的、并且它很可能直接影响 CCMR4F_self_test_error_强 压测试
-时间是来自 RTI 模块的 us 计数器
-测试之间用于从缓冲区获取所有打印的操作系统延迟
- LOAD_GET_ESM_BIT_NUM 实际上与 GET_ESM_BIT_NUM 相同

测试进行3轮测试：
第一次：就像 TRM 建议的那样
第二次：反对 TRM
第三次：正如 TRM 所建议的
#if 1.
        #include "sl_api.h"
        #include "macros.h"
        #include "ESM_application_callback.h"

        uint32 u32Rounds = 0U；
        for (u32Rounds = 0U；u32Rounds < 3U；u32Rounds++)
        ｛
            布尔型 bAgainsTRM = false；
            if (u32Rounds=1)
            ｛
                bAgainsTRM = true；
                DBG_PRINT ("=测试 TRM CLEAR 上的 ESM 错误==\r\n")；
            ｝
            其他
            ｛
                bAgainsTRM = false；
                DBG_PRINT ("=测试 ESM 错误建议清除==\r\n")；
            ｝

            DBG_PRINT ("nERROR：ACTIVE %u、%u us\r\n"、SL_ESM_NError_Active()、HAL_u32TimeGet ())；
            if (bAgainsTRM)
            ｛
                dbg_print ("清除 TRM\r\n)；
                sl_esmREG->EKR = 0x5u；
            ｝
            其他
            ｛
                DBG_PRINT ("跳过销钉清除，因为它已经打开了\r\n)；
            ｝

            uint32 u32通道= ESM_G1ERR_B0TCM_CORRERR；

            易失性 uint32* pu32RegErrPin =((u32Channel < 32U)？ &SL_esmREG->EEPAPR1：&SL_esmREG->IEPSR4)；
            易失性 uint32* pu32RegIsr =((u32Channel < 32U)？ &SL_esmREG->IESR1：&SL_esmREG->IESR4)；

            *pu32RegErrPin = own GET_ESM_bit_NUM (u32Channel)；
            //*pu32RegIsr = ue_get_ESM_bit_NUM (u32Channel)；

            DBG_PRINT ("测试前，nERROR：ACTIVE %u，%u us\r\n"，SL_ESM_nError_Active()，HAL_u32TimeGet ())；
            sl_SelfTest_Result failInfo；
            布尔型 bOwnRet = sl_SelfTest_SRAM (SRAM_ECC_1bit_FAULT_INMODING_TRUE，&failInfo)；

            DBG_PRINT ("bOwnRet：%s\r\n，BOOL2ASCII (bOwnRet))；
            uint32 u32Time = HAL_u32TimeGet ()；
            DBG_PRINT ("测试后，nERROR：ACTIVE %u，%u us\r\n"，SL_ESM_nError_Active()，HAL_u32TimeGet ())；

            DBG_PRINT ("起始引脚活动等待循环：%u us\r\n"、u32Time)；
            while (sl_ESM_nError_Active())
            ｛
                if ((HAL_u32TimeGet ()- u32Time)> 500U)
                ｛
                    DBG_PRINT ("超时中断\r\n")；
                    中断；
                ｝
            ｝
            DBG_PRINT ("从循环%u us 中退出，循环已过%u us\r\n"，HAL_u32TimeGet ()，HAL_u32TimeGet ()-u32Time)；
            易失性 uint32* pu32Reg =((u32Channel < 32U)？ &SL_esmREG->SR1[0]：&SL_esmREG->SR4[0])；
            *pu32Reg =(UINT32) OULL_GET_ESM_bit_NUM ( u32Channel )；
            * pu32Reg =(uint32) own _get_ESM_bit_NUM (ESM_G1ERR_B1TCM_CORRERR)；// test 也会激活此功能

            DBG_PRINT ("nERROR：ACTIVE %u，%u us\r\n"，SL_ESM_NError_Active()，HAL_u32TimeGet ())；
            if (sl_ESM_nError_Active())
            ｛
                dbg_print (“清除错误\r\n”)；
                sl_esmREG->EKR = 0x5u；
            ｝

            while (sl_ESM_nError_Active())
            ｛
            ｝
            DBG_PRINT ("nERROR：ACTIVE %u、%u us\r\n"、SL_ESM_NError_Active()、HAL_u32TimeGet ())；

            //需要在测试后清除这些错误，以便对新错误进行分类
            sl_tcram1REG->RAMERRSTATUS = TCRAM_RAMERRSTATUS_ADDR_SERR；/*lint !e9033 */
            sl_tcram2REG->RAMERRSTATUS = TCRAM_RAMERRSTATUS_ADDR_SERR；/*lint !e9033 */

            DBG_PRINT ("==测试结束==\r\n")；

            WOS_vDelayMs( 100U )；//清空打印缓冲区的时间
        ｝
#endif

结果如下：
===测试 ESM 错误建议清除===
nERROR：有效0、299122us          ////错误引脚已打开
跳过清除引脚、因为它已经打开       ////未给出复位
在测试之前、nERROR：ACTIVE 0、299173us    ////仍在运行
bOwnRet：对                ////执行测试
测试后、nERROR：ACTIVE 1、299225us        ////错误引脚已关闭
起始引脚有效等待环路：299225us        ////等待...
超时中断                ////超时
从299736us 的循环流出、循环经历511us    ////查看已用时间
nERROR：ACTIVE 1、299770us                    ////错误引脚仍处于关闭状态(如预期)
清除错误                ////确定引脚
nERROR：有效0、299806us           ////错误引脚已打开
===测试结束===

===测试 TRM 清除的 ESM 错误==
nERROR：有效0、299897us          ////错误引脚已打开
明确反对 TRM             ////针对 TRM 复位
在测试之前、nERROR：ACTIVE 0、299938us    ////仍在运行
bOwnRet：对                ////执行测试
测试后、nERROR：ACTIVE 0、299989us    ////错误引脚已关闭
起始引脚有效等待环路：299989us    ////等待... 但没有超时
从循环300108us 流出、循环经历119us    ////查看已用时间
nERROR：有效0、300143us          ////错误引脚已启动(不是预期的，Works =示例5说明)
nERROR：有效0、300169us
===测试结束===


===测试 ESM 错误建议清除===
nERROR：有效0、299020us          ////错误引脚已打开
跳过清除引脚、因为它已经打开       ////未给出复位
在测试之前、nERROR：ACTIVE 0、299071 us    ////仍在运行
bOwnRet：对                ////测试执行正常
测试完成后、nERROR：ACTIVE 1、299122us        ////错误引脚已关闭
起始引脚有效等待环路：299122us        ////等待...
超时中断                ////超时
从循环299633us 流出、循环经历511us    ////查看经过的时间(与超时匹配)
nERROR：ACTIVE 1、299667us                    ////错误引脚仍处于关闭状态(如预期)
清除错误                                     ////确定引脚
ISR：错误引脚打开                               ////我们的 IO 中断注意到引脚上升
nERROR：ACTIVE 0、299702 us                    ////错误引脚已打开
===测试结束===

===测试 TRM 清除的 ESM 错误==
nERROR：有效0、400019us                    ////错误引脚已打开
明确反对 TRM                           ////针对 TRM 复位
测试前、nERROR：ACTIVE 0、400062us       ////仍在运行
bOwnRet：对                                   ////测试执行正常
测试后、nERROR：ACTIVE 1、400114us        ////错误引脚已关闭
起始引脚有效等待环路：400114us        ////等待... 但没有超时
ISR：错误引脚打开                               ////我们的 IO 中断注意到引脚会上升！！！！！！！
从循环400286us 流出、循环经历171us    ////查看已用时间
nERROR：有效0、400320us                    ////错误引脚已启动(不是预期的，Works =示例5说明)
nERROR：ACTIVE 0、400346 us
===测试结束===

===测试 ESM 错误建议清除===       
nERROR：有效0、501018us                    ////错误引脚已打开
跳过清除引脚、因为它已经打开           ////未给出复位
在测试之前、nERROR：ACTIVE 0、501069us       ////仍在运行
bOwnRet：对                                   //////////////// 从第一轮开始、遵循相同的模式
测试后、nERROR：ACTIVE 1、501120 us
起始引脚有效等待环路：501120us
超时中断
从环路501631us 流出、环路经历511us
nERROR：ACTIVE 1、501665us
清除错误
ISR：错误引脚打开
nERROR：有效0、501700us
===测试结束===


因此、如果我们按原样运行 SafeTI 代码、并且在 CCMR4F_self_test_error_empling 测试之后将变为实际、假设在示例组1中没有配置 ISR、只有错误引脚操作 nERROR 引脚将变为低电平、然后"自己"弹出

我添加了"我的测试代码"、该代码将在 CCMR4F_self_test_error_强 压之后执行、但在任何其他测试之前执行(这会模拟可能随时发生的"实际错误")、结果如下：
-基本上删除了测试的循环并添加了测试周围的关键部分，以保证其它 IRQ 不会在测试后立即阻止 nERROR 读取状态
#if 1.
if (ptTest->eTest == CCMR4F_self_test_error_emiting)
｛
        #include "sl_api.h"
        #include "macros.h"
        #include "ESM_application_callback.h"
        ｛

            DBG_PRINT ("=测试 CCMR4F_self_test_error_强 励=\r\n")；

            uint32 u32通道= ESM_G1ERR_B0TCM_CORRERR；

            易失性 uint32* pu32RegErrPin =((u32Channel < 32U)？ &SL_esmREG->EEPAPR1：&SL_esmREG->IEPSR4)；
            易失性 uint32* pu32RegIsr =((u32Channel < 32U)？ &SL_esmREG->IESR1：&SL_esmREG->IESR4)；

            *pu32RegErrPin = own GET_ESM_bit_NUM (u32Channel)；
            //*pu32RegIsr = ue_get_ESM_bit_NUM (u32Channel)；

            DBG_PRINT ("测试前，nERROR：ACTIVE %u，%u us\r\n"，SL_ESM_nError_Active()，HAL_u32TimeGet ())；
            sl_SelfTest_Result failInfo；
            WOS_vCSEnter()；
            布尔型 bOwnRet = sl_SelfTest_SRAM (SRAM_ECC_1bit_FAULT_INMODING_TRUE，&failInfo)；

            DBG_PRINT ("bOwnRet：%s\r\n，BOOL2ASCII (bOwnRet))；
            uint32 u32Time = HAL_u32TimeGet ()；
            DBG_PRINT ("测试后，nERROR：ACTIVE %u，%u us\r\n"，SL_ESM_nError_Active()，HAL_u32TimeGet ())；
            WOS_vCSExit()；

            DBG_PRINT ("起始引脚活动等待循环：%u us\r\n"、u32Time)；
            while (sl_ESM_nError_Active())
            ｛
                if ((HAL_u32TimeGet ()- u32Time)> 300U)
                ｛
                    DBG_PRINT ("超时中断\r\n")；
                    中断；
                ｝
            ｝
            DBG_PRINT ("从循环%u us 中退出，循环已过%u us\r\n"，HAL_u32TimeGet ()，HAL_u32TimeGet ()-u32Time)；
            易失性 uint32* pu32Reg =((u32Channel < 32U)？ &SL_esmREG->SR1[0]：&SL_esmREG->SR4[0])；
            *pu32Reg =(UINT32) OULL_GET_ESM_bit_NUM ( u32Channel )；
            * pu32Reg =(uint32) own _get_ESM_bit_NUM (ESM_G1ERR_B1TCM_CORRERR)；// test 也会激活此功能

            DBG_PRINT ("nERROR：ACTIVE %u，%u us\r\n"，SL_ESM_NError_Active()，HAL_u32TimeGet ())；
            if (sl_ESM_nError_Active())
            ｛
                dbg_print (“清除错误\r\n”)；
                sl_esmREG->EKR = 0x5u；
            ｝

            while (sl_ESM_nError_Active())
            ｛
            ｝

            DBG_PRINT ("nERROR：ACTIVE %u、%u us\r\n"、SL_ESM_NError_Active()、HAL_u32TimeGet ())；

            //需要在测试后清除这些错误，以便对新错误进行分类
            sl_tcram1REG->RAMERRSTATUS = TCRAM_RAMERRSTATUS_ADDR_SERR；/*lint !e9033 */
            sl_tcram2REG->RAMERRSTATUS = TCRAM_RAMERRSTATUS_ADDR_SERR；/*lint !e9033 */

            DBG_PRINT ("==测试结束==\r\n")；
        ｝
｝
#endif


===在 CCMR4F_self_test_error_forc 之后进行测试...
在测试之前、nERROR：ACTIVE 0、293464us
bOwnRet：对
测试完成后、nERROR：ACTIVE 1、293518us
起始引脚有效等待环路：293518us
ISR：错误引脚打开
从循环293653us 流出、循环经历135us
nERROR：ACTIVE 0、293710us
nERROR：ACTIVE 0、293735us
===测试结束===



然后、如果我注释 SafeTI 代码 nERROR 清除、现在 nERROR 正确保持低电平：
            /*清除 nERROR */
            //_sl_HoldNClear_nError ()；
            /*清除中断*/


===在 CCMR4F_self_test_error_forc 之后进行测试...
测试前、nERROR：ACTIVE 0、293282 us
bOwnRet：对
测试完成后、nERROR：ACTIVE 1、293338us
起始引脚有效等待环路：293338us
超时中断
从循环293650us 流出、循环经历313us
nERROR：ACTIVE 1、29368us
清除错误
ISR：错误引脚打开
nERROR：ACTIVE 0、293719us
===测试结束===


我认为这证明了_sl_HoldNClear_nError()不应该存在，因为它是不控制 nERROR 的测试？

我不小心将一些错误的日志留在了开头(测试代码有错误、根本没有生成第二次错误)、应该删除前2个日志 (当时没有这些行、因此不会产生错误、因为在第二次测试后、尽管我的注释中说了错误状态、但可以从错误状态中看到错误)：
//需要在测试后清除这些错误，以便对新错误进行分类
sl_tcram1REG->RAMERRSTATUS = TCRAM_RAMERRSTATUS_ADDR_SERR；/*lint !e9033 */
sl_tcram2REG->RAMERRSTATUS = TCRAM_RAMERRSTATUS_ADDR_SERR；/*lint !e9033 */

在"下面是结果："文本之后应删除前2个"测试"(该文本没有 ISR：错误引脚向上-文本)。 ("轮次测试"下总共有5个测试日志)

下面是帖子中应该包含的最下面3个选项(没有预览选项？ 因此、验证内容是您想要的内容有点棘手)...

===测试 ESM 错误建议清除===
nERROR：有效0、299020us ////错误引脚已打开
跳过清除引脚、因为它已经打开 ////未给出复位
在测试之前、nERROR：ACTIVE 0、299071 us ////仍在运行
bOwnRet：对 ////测试执行正常
测试完成后、nERROR：ACTIVE 1、299122us ////错误引脚已关闭
起始引脚有效等待环路：299122us ////等待...
超时中断 ////超时
从循环299633us 流出、循环经历511us ////查看经过的时间(与超时匹配)
nERROR：ACTIVE 1、299667us ////错误引脚仍处于关闭状态(如预期)
清除错误 ////确定引脚
ISR：错误引脚打开 ////我们的 IO 中断注意到引脚上升
nERROR：ACTIVE 0、299702 us ////错误引脚已打开
===测试结束===

===测试 TRM 清除的 ESM 错误==
nERROR：有效0、400019us ////错误引脚已打开
明确反对 TRM ////针对 TRM 复位
测试前、nERROR：ACTIVE 0、400062us ////仍在运行
bOwnRet：对 ////测试执行正常
测试后、nERROR：ACTIVE 1、400114us ////错误引脚已关闭
起始引脚有效等待环路：400114us ////等待... 但没有超时
ISR：错误引脚打开 ////我们的 IO 中断注意到引脚会上升！！！！！！！
从循环400286us 流出、循环经历171us ////查看已用时间
nERROR：有效0、400320us ////错误引脚已启动(不是预期的，Works =示例5说明)
nERROR：ACTIVE 0、400346 us
===测试结束===

===测试 ESM 错误建议清除===
nERROR：有效0、501018us ////错误引脚已打开
跳过清除引脚、因为它已经打开 ////未给出复位
在测试之前、nERROR：ACTIVE 0、501069us ////仍在运行
bOwnRet：对 //////////////// 从第一轮开始、遵循相同的模式
测试后、nERROR：ACTIVE 1、501120 us
起始引脚有效等待环路：501120us
超时中断
从环路501631us 流出、环路经历511us
nERROR：ACTIVE 1、501665us
清除错误
ISR：错误引脚打开
nERROR：有效0、501700us
===测试结束=== <LF

Jarkko、

感谢您的详细回答。 我正在审查所有信息、以便能够提供您所需的答案、并根据您的系统要求/应用需求提供一些指导。

您好、Jarkko、

首先、"差"英语不需要道歉。 您的英语非常好、令人钦佩、您可以用多种语言就这些技术问题进行交流。 了解问题在 E2E 上很常见、因为有时可能会以不同的方式解释问题、而且通过 E2E 交流技术问题总是很困难。

很抱歉、我看到了错误的测试模式。 正确的是、自检错误强制测试会导致设置 Grp1 CH31标志。 组1错误通常是较低优先级的问题、因此可在其响应中配置中断和 nERROR 操作。 我还观察到您的观察结果、即测试完成后 ESM nERROR 信号被清除/复位、因此对 Grp1误差的处理方式与其他误差不同。 我需要查询代码的原始开发人员、以了解这是简单的剪切和粘贴问题、还是有特定的原因。 至于是否是错误，我现在不能判断。 由于 CCMR4操作仍在进行中、因此它确实有可能屏蔽一个真正的 CCMR4F 误差。 我想就这个问题提出一个 CQ TT、以便 SW 团队可以对其进行进一步评估、并根据风险做出决定是否需要进行纠正。

相对于您的特定用例、我发现您对 nERROR 断言的看法是一个问题。 我们的芯片架构和故障报告的基础是将 nERROR 引脚置为有效、以便通知外部系统并采取适当的操作。 在许多情况下、我们假设将进行复位以校正可能导致故障的任何瞬态故障、因此 nERROR 的置位旨在为此向外部发出信号(因此 HFT = 0)。 在函数的软件测试和错误路径测试中、这代表了处理 nERROR 引脚的一些挑战、如您所述。 在使用配套器件的情况下、可以对 nERROR 监控进行编程、以便在引脚上延长时间；因此、短断言不会影响进入安全状态。

您还提到了将 nERROR 引脚绑定到 GPIO 引脚、以便在 nERROR 置为有效时触发中断。 ESM 中断的产生是否有原因不足以实现此目的？ 即、我相信任何导致 nERROR 置为有效的错误也有一个与之相关的 ESM 中断(NMI 或 FIQ)、或者可被配置为具有一个与之相关的中断。 延迟是否是这里的问题？

您还提到/强调了有关 nERROR 引脚和计数器行为的几个具体问题。 我需要更深入地研究这些问题、因为这不仅涉及 nERROR 引脚/计数器背后的逻辑设计、还涉及特定用例/ SW 交互。 我将再次提供有关这方面的更多信息。

[引用 USER="Chuck Davenport">当然、由于 CCMR4操作仍在进行、它确实有可能屏蔽一个真正的 CCMR4F 错误。 我想提出有关此问题的 CQ 票证、以便软件团队可以进一步评估该问题、并根据风险做出是否需要更正的决定。我不担心任何特定测试(例如 CCMR4)、 正如我的示例所示、如果任何 ESM 错误使 nERROR 下降-由于#5示例、nERROR 由自身升高、您基本上不能采取任何措施来防止它 (唯一不同的是、如果 ESM 错误为您提供了 NMI/FIQ/可 配置的 IRQ 并且您决定系统需要保持在安全状态、则可以通过将0xA 写入 EKR 来强制 nERROR 降压)。 这种"自动"上升的影响当然取决于应用的其他保护措施(例如，我们有硬件锁存器，但如果您只是在 nERROR 上升后对锁存器进行哑弹，在这种情况下根本没有帮助：)。

但我正在等待第一次确认示例5是正确的 TRM、并且在尝试测试它时没有犯错。

[引用 user="Chuck Davenport">您还提到了将 nERROR 引脚绑定到 GPIO 引脚、以便在 nERROR 被置为有效时触发中断。 ESM 中断的产生是否有原因不足以实现此目的？ 即、我相信任何导致 nERROR 置为有效的错误也有一个与之相关的 ESM 中断(NMI 或 FIQ)、或者可被配置为具有一个与之相关的中断。 延迟是否是这里的问题？[/quot]我们使用此 GPIO 获取 nERROR 上升沿的通知、因为我们在 nERROR 引脚之后有 HW "LATCH"(floop -名称是什么)、直到引脚向上时才能释放该引脚 (如果在输出保持下降之前释放它)。 由于我们的时间范围相当短、在外部器件开始跳闸之前锁存器可以关闭多长时间、因此我们需要基于 IRQ 的 nERROR 响应(或其他相当快的响应)返回到正常状态以防止假脱机跳闸 (ESM 模块不提供它-这就是为什么也将 nERROR 连接到 GPIO 的原因)。

例如、在我的当前代码所在的系统中、 上升沿 GPIO IRQ 会"笨重"、只需夹住闩锁即可删除安全状态、具体取决于其他控制和保护措施、因为目前我不检查闩锁释放中的任何内容-我相信 nERROR 不会因意外而升高->您需要慎重考虑 提出问题的措施-现在我非常确信、在这一点上的"信任"可能不是理想的方法、因为例如、当引脚处于上升状态时、额外确认等微小错误很可能会导致 nERROR 在这种情况下自行升高 下降一个真正的错误-我已经签入了自己的代码、在 nERROR 上升的情况下根本不会给出 ACK、这本身应该已经很好地防止了示例#5、以防你在每个地方使用该函数 (SafeTI 代码中的类似函数会阻止该测试中的额外调用产生任何副作用)。 我仍在计划为锁存释放设置某种 SW 防护、目前还不知道是什么类型、也许一些需要处于适当值和/或 SW 模式的标志是合适 的和/或没有任何具有 nERROR 控制功能的 ESM 通道处于活动状态...

我仍然不是说、释放闩锁"笨重"会自动导致安全状态因事故而被清除、但如果我能够消除 这种事故(或至少大大降低了可能性) 这是值得做的、但这当然需要首先了解这种情况可能会发生、并且需要对 TRM 进行非常仔细的检查。 假设我在自己的实际 ESM 错误处理中有一个错误、这会导致错误未正确地发送给应用(但此处仍然没有 nERROR) 我所做的最新诊断测试是 CCMR4F_self_test_error_Forcing 测试->"改进的锁存器释放"将获得这一结果、而我们的当前解决方案则无法获得这一结果。 例如、飞机从不会因为单一错误/缺陷而停机、它总是需要一系列不太可能发生的事件和设计失败(有人一直在 电视上观看"混乱日"/空中碰撞调查)、如果您设法解决甚至一个问题、最终结果会有所不同。

===========================
当然、如果"failure-ack-failure"- pattern 结果仍然释放 nERROR (我不希望出现这种情况)、情况会更加棘手 但在这种情况下，我认为，如果软件由于错误处理中的其他一些错误而错过了该错误，那么锁定释放中的 ESM 通道活动检查就会启动....

尝试现在使用 FLASH_ECC_TEST_MODE_2BIT 测试对其进行测试、因为它包含2个创建错误的阶段、 然后我在这里注释掉了第二个错误确认(记住、出于运行时的目的、我已经修改了确认函数、在本例中、它只写入 EKR=0x5、不等待 nERROR 上升)

因此、测试的第一部分是原样

           if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
                   &&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x8u)
                   &&(位(ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和位(ESM_G3ERR_FMC_Uncorr)))｛
               _sl_HoldNClear_nError()；//清除 nError */

从第二部分开始、我删除了 nERROR ACK
               if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
                       &&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x0u)&&(bit (ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和 bit (ESM_G3ERR_FMC_Uncorr))))｛
                   //_sl_HoldNClear_nError ()；
                   *FLASH_stResult = ST_PASS；
               ｝否则｛
                   *FLASH_stResult = ST_FAIL；
               ｝

这应该给出"失败-失败"模式、如果我没有犯错、结果是 nERROR 也在上升、因此有关"重置"的 TRM 文本很可能是正确的、读者需要了解计数器的后果 (基本而言、当您进行需要 nERROR ACK (组2或3或 FI 至 G1、已启用操作)的诊断测试时、该测试后的情况与#5有点相似、但该测试具有有限的时间范围、即 nERROR 配置的关闭时间) 因为没有图示例。

但是、当然仍在等待您对此进行确认... 如果这是真实的、那么 TRM 中的图片示例将非常受欢迎。

如果这是"已确认"的、则只需通过方法"不确认 nERROR ISF 引脚已启动"来处理示例#5是不够的、因为"实际错误处理中的实际错误+错误处理中的错误"可能会导致"错误"的影响。  当然、在 nERROR 停机窗口期间发生实际错误的可能性很小、比在发生#5违反时小得多、因为错误具有"无限"时间范围... 但是、如果这将是"已确认的功能"、并且当我现在知道它可以做些什么来避免这种情况时、我就不能像现在那样让锁存器解锁...

===========

还尝试在该 FLASH_ECC_TEST_MODE_2BIT 闪存测试的帮助下进行测试以下模式： "failure-ack-failure (-ack)--- Let error pin go up --在 nError 出现后运行相同的 SRAM fi 测试-- nError 保持正常状态。 因此、在 nerror 关闭时进行的连续 ACK 不会"分组"等待示例5、因为根据 TRM 示例、最有可能是可以预料的(&G)。

=====

您好、Jarkko、

首先、让我从几个帖子中回答您的具体问题。

第一：
"问题：如果在两次故障之间提供了一次复位、则最新故障中的 t_err_low 后的 nERROR 引脚状态是什么？ (我知道即使在 ESM 通道中、您也可以应答错误)"

我相信第二个故障将启动第二个故障通知、从而使 nERROR 引脚在 t_err_low 时间段内驱动为低电平、直到在给出第二个回位/复位时该引脚再次上升。 即、第二个故障将抵消第一个故障的"恢复/复位"。

问题：如果 t_err_low 计数停止(&寄存器值已重置) 当发生故障时、我们不必担心连续错误、但如果 t_err_low 值仅重置 nERROR 引脚、则会升高、以防它曾被攻击一次、之后在 t_err_low 窗口期间出现一些实际错误 (这不是示例5、因为5中给出了复位时的引脚为向上计数)。
-在最终的情况下，第二个确认是“被偷”的，即使是这样，系统的运行就像示例5中一样(但我怀疑是这样)

第二个问题似乎与您的第一个问题相同、但如果我理解正确、则会更多地讨论 t_err_low 计数器。 因此、我认为对于 nERROR 信号、答案是相同的。 本质上、如果存在导致 nERROR 变为低电平且随后发生"ack/reset"的故障、计数器会继续在上升之前完成计数、因此您将拥有最短的 t_err_low 低电平时间。 如果在第一个故障的"ack/reset"之后出现第二个故障、计数器会在收到第二个故障时重新启动、并将保持低电平、直到给出下一个"ack/reset"。 本质上、第二个故障应取消来自第一个故障的'ack/reset'请求。 这种情况与示例5不同、因为示例5中 nERROR 引脚的状态和 FAULT 置为未进行。 如果您确实看到了不同的行为、请告诉我、并将与我们的设计团队和 ESM 模块专家一起仔细检查、看看这是芯片错误还是应该记录的预期行为。

在执行上述测试用例期间、您是否能够使用示波器监视 nERROR 引脚？ 最好能够以这种方式捕获此引脚操作、因为打印语句中的代码执行/延迟可能会错过引脚状态、而发生的速度比代码执行和串行通信快。

您好！

[引用用户="Chuck Davenport"]
第二个问题似乎与您的第一个问题相同、但如果我理解正确、则讨论更多 t_err_low 计数器。我也认为如此。

[引用用户="Chuck Davenport"]
在执行上述测试用例期间、您是否能够使用示波器监视 nERROR 引脚？ 最好能够以这种方式捕获此引脚操作、因为打印语句中的代码执行/延迟可能会错过引脚状态、而这种情况比代码执行和串行通信快。是的、我也能够通过示波器进行监控。 是否与我之前的测试结果相同、如果连续故障在线路上升前、EKR=5 ACK、则 nERROR 会上升。

这次是如何测试的？ 在 startup.c 中(禁用 FIQ&IRQ 等，操作系统不运行，因此甚至不能远程运行环境切换等)。 我使用与上一个测试中类似的修改运行 FLASH_ECC_TEST_MODE_2BIT 测试 (并通过调试器步进验证这些修改后的代码行在该测试期间执行)。

第1个错误、修改了它、以便根本不调用函数、只向 EKR 写入5个(这实际上与使用我们修改的函数"运行时周期"相同、但至少现在它确实清楚了所做的是什么。
           if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
                   &&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x8u)
                   &&(位(ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和位(ESM_G3ERR_FMC_Uncorr)))｛
               //_sl_HoldNClear_nError ()；//清除 nError */
               sl_esmREG->EKR = 0x5u；

第二个错误、注释为确认、因此我们应该具有"fail-ack-fail"-pattern
               if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
                       &&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x0u)&&(bit (ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和 bit (ESM_G3ERR_FMC_Uncorr))))｛
                   //_sl_HoldNClear_nError ()；
                   *FLASH_stResult = ST_PASS；
               ｝否则｛
                   *FLASH_stResult = ST_FAIL；
               ｝

结果是 nERROR 为156us 低电平、这与以下事实非常匹配：在2个故障之间、在给定 ACK 之前还将执行数据中止矢量代码(failure-data_abort-ack-clear_se_register_ack-failure)。 但是、让我们不要在这里停止、因为我想确定测量的是什么、所以我在 这样的 ACK 之后的第1次和第2次故障之间添加了 ASM NOP 环路(因此总共执行了1000轮、共10000 nops)。

           if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
                   &&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x8u)
                   &&(位(ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和位(ESM_G3ERR_FMC_Uncorr)))｛
               //_sl_HoldNClear_nError ()；//清除 nError */
               sl_esmREG->EKR = 0x5u；

               uint32 u32Temp = 1000U；
               while (u32Temp---)
               ｛
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
                   _asm ("nop")；
               ｝

               /*清除闪存和 ESM 状态寄存器*/
               SL_flashWREG->FEDACSTATUS = F021F_FEDACSTATUS_B1_UNC_ERR；
               sl_esmREG->SR1[2]=位(ESM_G3ERR_FMC_Uncorr)；

结果是 nERROR 关闭时间从156us 延长到244us、因此 NOP 会产生影响、从而使第二个误差稍后出现。 如果我在某个时间点增加了 nops 数量、则 nERROR 在测试结束时会保持较低值、因为 nERROR 在这两代故障之间有时间上升。

我现在非常确信、我的测试会测试"失败-失败"模式、 当然、最终调试器连接等可能会影响测试、因此、我无法100%仅为99.9%确定这种影响是真实的连续故障、只需重置计数器而不会停止它。
[引用用户="Chuck Davenport"]
如果您确实看到了不同的行为、请告诉我、并将与我们的设计团队和 ESM 模块专家一起仔细检查、看看这是芯片错误还是应该记录的预期行为
我认为我看到的行为不同、在 t_err_low 计数一旦启动(通过对 EKR 的5次写入)的情况下、连续的故障不会停止计数器、它只是重置计数器、而不会停止计数器。

这很可能在 TRM 中正确记录(除了缺少带图片的清晰示例)、因为它表示计数器已重置(未停止)、 它只需要读取器进行一些改进、以了解它的实际含义、因为对"待定" nERROR 应答的影响根本没有提及。

[引用]在引脚保持低电平的时间内发生另一个故障。 在这种情况下、当发生其他故障时、低电平时间计数器将被重置。[/QUERP]

因此、如果它被正确记录、那么我认为它不能是一个器件错误？ 这只是一个" 意外行为"( 不知道更好的术语)、因为从逻辑上讲、这应该像您描述的那样工作、在发生故障后、需要提供新的 ACK 以使引脚向上。 这与示例#5非常相似、"未指定"的内容、但#5已清楚地记录在案。 #5可能会被用于测试、首先生成 ACK、然后生成故障->无需担心如何将引脚恢复到正常状态的时序 (当然，它也会弥补真正的错误，但由于它看起来没有银弹，如何防止 nERROR 在每种利用可能会造成更多伤害的情况下上升。 但最好不要使用它、即使它很诱人...)

现在等待确认结果是否真实、然后我必须思考我应该怎么做才能使锁扣释放尽可能稳定。 目前认为没有一种方法可以在所有情况下工作、因此很可能应该选择一些并行方法来尝试在应用程序的主要错误处理中捕获可能的错误。 还注意到、根据 TRM (第12.2.3章、第1步)、如果 nERROR 已经关闭、则不能使用错误强制(EKR=0xA)、 因此、一旦 LTC 计数被删除、就无法停止它的计数、这意味着 nERROR 不能永久置入关闭状态、因此基本上它可以随时弹出、因为您无法防止在等待 nERROR 上升时测试某个内容后出现实际错误...

在测试失败的情况下、不同的测试将使 ESM 位保持有效(闪存测试使 ESM 通道始终远离、 但 SRAM 不是)、并且也会有不同之处、即是否给出了 NError ACK (尽管测试结果不同、SRAM 测试仍始终提供 NERROR)。 因此、其他测试会始终将 ESM 通道置位、其他测试会始终将 nERROR 置位...
SRAM_RADECODE_DIAGNOSTICS：
           _sl_SelfTest_SRAD_RAD (sl_tcram2REG、SRAM_stResult)；
           _sl_HoldNClear_nError()；//清除 nError */
           if (ST_PASS =* SRAM_STResult)｛
               SL_esmREG->SR1[1]=(uint32)(1U <<ESM_G2ERR_B1TCM_Uncorr)；
               SL_esmREG->SSR2 =(uint32)(1U <<ESM_G2ERR_B1TCM_Uncorr)；
           ｝

和
FLASH_ECC_TEST_MODE_2BIT (并且您还记得之前的代码段中的 nERROR ACK 位于同一代码块和 ST_PASS 设置中、因此只有在成功的情况下才能完成)：
           /*始终清除闪存和 ESM 状态寄存器*/
           #if defined (_TMS570LS31x_)|| defined (_TMS570LS12x_)|| defined (_RM48x_)|| defined (_RM46x_)|| defined (_RM42x_)|| defined (_TMS570LS04x_)
           SL_flashWREG->FEDACSTATUS = F021F_FEDACSTATUS_B1_UNC_ERR；
           flashread = sl_flashWREG->FUNCHERRADD；
           #endif
           sl_esmREG->SR1[2]= 位(ESM_G3ERR_FMC_Uncorr)；



应该有2个待确认的开放项目
1) 1) SafeTI CCMR4F_self_test_error_en逼 测试会导致 TRM #5未来错误的示例行为、因为它在 nERROR 应加电时会产生 ACK (测试期间是否发生其他实际错误是可以的)
2)"failure-ack-failure (-failure)"- pattern 会导致 nERROR 在 t_err_low 时间结束后从上次故障恢复(无法阻止它)