This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RM48L952:SafeTI:FLASH_ADDRESS_奇 偶校验_self_test 信号演示项目中应用程序的实际组3错误 ANBD 出于相同的原因不能在&quot 中使用;实应用程序要么不能使用"

Guru**** 2350610 points
Other Parts Discussed in Thread: CCSTUDIO
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/602737/rm48l952-safeti-flash_address_parity_self_test-signals-actual-group3-error-to-application-in-demo-project-anbd-for-same-reason-does-not-work-in-real-application-either

器件型号:RM48L952
Thread 中讨论的其他器件:CCStudio

您好!

我一直在尝试通过电子邮件23.5提出这一问题、没有答案...

现在、由于发现并修复了一些其他错误(DMA 测试)、我终于能够运行2.3.1 SafeTI IAR RM48演示应用程序来尝试在那里重现问题。

根据此帖子、此测试中不应再出现任何问题
https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/497516/1800406#1800406

我不同意、是的、可以实现永远的循环 doe 不再存在、但测试会向应用发出实际组3错误信号。

在调用该测试后、代码首先进入 FIQ 处理程序(预计会出现)、然后进入 DATA_ABORT 处理程序。 在数据中止中、代码进入此分支、该分支不会屏蔽错误(猜可能清除诊断模式会阻止 for 永远循环)

  /*由于闪存包装程序测试2位 ECC 故障注入而导致的 DAbort? *
   否则、如果(0!=(sl_flashWREG->FDIAGCTRL & 0x7)){
      maskDAbort = false;

      /*尽管没有必要,但关闭诊断模式*/
      sl_flashWREG->FDIAGCTRL &= 0xFFF0FFF8;//清除诊断使能键*/
      callbkParam1 = sl_flashWREG->FUNCHERRADD;
      callbkParam2 = sl_flashWREG->FEDACCSTATUS;
      ESM_ApplicationCallback (((uint32)(ESM_Grp3_MASK | ESM_G3ERR_FMC_Uncorr)、callbkParam1、callbkParam2、callbkParam3);

      }


由于数据中止调用不是通过标志屏蔽的(演示应用端(ESM 回调)"愚蠢地"清除了组3 ESM 位、甚至向其发出了棘手的实际错误信号)、这种"看起来在演示应用中工作"甚至很难实际不工作。 如果您向数据中止处理程序中添加了一个小错误处理(while (1)-loop、用于非屏蔽中止的代码将在那里并保留在那里。
   if (false =maskDAbort){

      /*提取错误地址并向应用程序报告*/
       //while (1)
       //{
       //};
   }

需要有关如何屏蔽该错误的正确说明、还需要修复演示应用。 此外、我认为组3 ESM 错误应该被置于 SafeTI 代码(sl_selftest.c)内(在无法避免此数据中止的情况下)、就像针对每个其他组3错误那样、当前该测试只清除 sl_selftest.c 内的组2错误 当然、用于 SafeTI 测试的组3 ESM 通道的堆栈不能位于 ESM_Application_callback 内部、在这里会向实际错误发出信号。

此测试在不清除此诊断密钥的情况下运行(它会恢复 sl_selftest.c 中的设置)
sl_flashWREG->FDIAGCTRL &= 0xFFF0FFF8;//清除诊断使能键*/

数据中止处理程序中的代码注释也是指 ECC 2位故障注入测试、因此不应在任何其他测试中输入此分支?

如果在 SL_FLAG_GET 说明此测试处于活动状态并且启用了模式7的诊断(如果(7U =(SL_flashWREG->FDIAGCTRL & 0x7U)))中存在检查数据中止处理程序、则- -通过当前0中的方式,似乎有一个错误!= sl_flashWREG->FDIAGCTRL & 0x7U,如果选择了任何诊断模式,则会进入该分支...


当未启用 FIQ 时,此测试在我的实际应用程序中的 CPU 启动阶段有效,但由于我们捕获到每个非屏蔽错误,代码被停止:)。 因此、根本原因实际上必须是启用 FIQ、这会导致数据中止、而这不会在演示应用程序或 SafeTI 代码中进行处理 (SafeTI 代码应检查是否启用了 FIQ、还要求生成组3错误、并在将 ST_PASS 返回给调用方之前将其返回)。

在这里、我在运行期间运行该测试时的真实应用报告

==data_abort==

 DFSR:0x1008

 DFAR:0x20000000

 状态:0x8

 读:正确

 AxiDec:错误

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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    这是在启用 FIQ 时看起来也能在运行时工作的代码


    DATA_ABORT()检查是在 FIQ 中断后通过适当的诊断模式检查的这种可能的闪存地址奇偶校验测试"剩余"调用
    否则、if ((((TRUE == sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_自_测试)))&(((sl_flashWREG->FDIAGCTRL & 0x7U)== 7U)))
    {//注意:JSI 14.6.2017:如果启用了 FIQ、此测试也会导致数据中止
    maskDAbort = true;

    /*由于闪存包装程序测试2位 ECC 故障注入而导致的 DAbort? *
    否则(0U!=(sl_flashWREG->FDIAGCTRL & 0x7U))



    sl_selftest.c "被严重修改"以检查 FIQ 是否被启用、并根据它采取适当的操作(清除此处的组3、因为错误是由 SafeTI 引起的)

    _sl_Barrier 数据访问();
    flashread =*(volatile UINT32 *) flashBadECC1;

    sl_flashWREG->FPAROVR = regBkupFPUvr;//在错误后、在新的闪存访问之前立即返回内容
    sl_flashWREG->FDIAGCTRL = regBckupFdiagctrl;//此处已恢复相同

    if (flash_address_parity、fault_inject!= testType)

    extern uint32 _fiq_disable_(void);
    布尔型 bGroup3Ok = true;

    //注意:只有启用 FIQ 才会生成数据中止,因此组3错误可能存在,也可能不存在
    if (!_Fiq_disabled_())

    if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
    &&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x0u)&&(位(ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和位(ESM_G3ERR_FMC_Uncorr)))))


    其他

    bGroup3Ok = false;


    /*始终清除闪存和 ESM 状态寄存器*/
    SL_flashWREG->FEDACSTATUS = F021F_FEDACSTATUS_B1_UNC_ERR;
    sl_esmREG->SR1[2]=位(ESM_G3ERR_FMC_Uncorr);
    //请勿读取 sl_flashWREG->FUNCHERRADD,它如下所示


    if (bGroup3Ok)

    if (((F021F_FEDACSTATUS_ADD_PAR_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_ADD_PAR_ERR))))

    //sl_flashWREG->FPAROVR = regBkupFPUVr;
    _sl_HoldNClear_nError();/*清除 nError */
    /*清除闪存和 ESM 状态寄存器*/
    //sl_flashWREG->FEDASTATUS = F021F_FEDASTATUS_ADD_PAR_ERR;//两次,也在下面
    //sl_esmREG->SR1[1]= GET_ESM_bit_NUM (ESM_G2ERR_FMC_Uncorr);//两次,也在下面
    //flashread = sl_flashWREG->FUNCHERRADD;
    *FLASH_stResult = ST_PASS;
    }否则{
    *FLASH_stResult = ST_FAIL;


    其他

    *FLASH_stResult = ST_FAIL;


    /*SAFETYMCUSW 134 S MR:12.2 备注_5*/
    /*SAFETYMCUSW 96 S MR:6.2、10.1、10.2、12.1、12.6 备注_25*/

    /*始终清除闪存和 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;



    另请注意、如果启用了 FIQ、这些类型的寄存器清除完全没用(可能会防止"同时到达可能的实际错误"?) 由于 FIQ 中断处理会自动清除 SR[1]位、因此只有 SSR2位保持活动状态、需要确认...
    sl_esmREG->SR1[1]= GET_ESM_bit_NUM (ESM_G2ERR_FMC_Uncorr);


    是的、诊断寄存器备份恢复在这里是两次、因为不想修改超出必要的代码...

    这不能是 SafeTI 库的用途、集成商需要根据寄存器设置来访问"私有函数" sl_FLAG_Get、Guess 和 Wonder、这些设置可能正在进行、尤其是在演示应用甚至不是故意处理情况时 (嗯、如果/何时演示应用程序停止到 DMA 测试、甚至无法继续执行这些测试、这正是您所期望的...)。


    再次询问、当 SafeTI 的固定版本即将推出时,当前的2.3.1以多种方式被破坏-是的,您可以忍受这种情况(希望您不能修改它:) 但需要对 TI 代码进行"大量修改"、并花费不必要的时间来首先找出根本原因、然后自行修复?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Jarkko、

    我想发送一条简短的消息、让您知道我们已经与本测试设计的原始软件进行了交谈、但我们尚未收到可接受的最终答案。 设计人员的初始响应是将 ESM 处理程序从 SRAM 中执行、以防止异常、我认为这是集成到真实安全应用中的可接受解决方案。 我们将继续研究如何确定修复它的最佳解决方案、并避免将任何元素移至 SRAM 执行。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    只是为了澄清:这是否意味着、在当前形式的代码中、如果启用了 FIQ、那么组3错误+中止是运行此测试的"实际且预期"副作用-而不是我一侧的某种编码错误?

    如果这是真正的确定性副作用、我至少可以忍受该组3错误、因此我不需要从 RAM 运行代码来防止它发生或其他任何更复杂的事情-如果这种行为、我可以很容易地看到 ESM3/ABORT 属于测试 在原始测试中记录并正确处理。 积分器随后还可以"复制逻辑"进行故障注入测试、因为这是预期行为。

    我在这里尝试询问这些诊断模式的实际作用是什么、 由于我不理解为什么这个 ESM3参加这个测试(仍然不理解它-但如果这是真正的副作用、也许我不需要理解它-只要知道 ESM3/ABORT 将被激活是有原因对我来说就足够了)、 当从 FIQ 返回时、Eesm3/abort 将会激活、并执行下一行代码-因此基本上在 FIQ 中执行的 C 代码不会导致该行为。 还想知道为什么 FIQ 中需要手动写入0x5400、因为应该存在"自动清除"DIAG_TRIG、但测试中根本没有设置 TRIG 位、即使 TRM 5.6.2表示如果 DIAG_TRIG 不是、也仍然会生成初始 esm2错误 设置... 但是、如果此测试的 ESM3/ABORT 功能"已确认"、我很可能也不需要了解这方面的详细信息... 只要我需要自己进行相当“繁重”的修改,我就想知道根本原因,因为通常如果你不理解根本原因,“修复”可能是完全错误的,即使它看起来是有效的,并且可能导致更灾难性的失败...
    https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/603175

    //////////// 故障注入变体的更多信息
    这里其他用户的 ESM3问题完全相同(在同一测试的故障注入变体中-我遇到了相同的问题、但由于找到了一种方法来"修复"实际测试、因此相同的步骤适用于故障注入变体)。 想知道为什么有人说测试运行不会出现问题、以防 ESM3出现上述状态的" IDE 影响问题"、或者此测试在不同的 CPU 型号上的工作方式不同、因为需要修改最低0x5400来防止连续 FIQ 环路、具体取决于 可能还需要0x5400位置设置手动 SR1 ACK、以便甚至达到 ESM3/ABORT 弹出的状态、因为至少在我的代码中、"辅助 FIQ"将被解释为真正的故障、因为"一次性消耗性 FI 标志"不再有效、因为它已经失效 在第1轮中清零、代码最终在 while (1)循环中?
    https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/608591

    以下是我的故障注入版本体验(基本上、如果在 sl_ESM.c 中为该测试设置相同的0x5400、您就可以使用该版本 (或在应用程序端 ESM-ERROR 处理程序中执行此操作、但您需要手动将同时挂起的 FIQ 从 SR[1]中删除、因为它已自行恢复、如果没有手动恢复、则代码在退出后立即跳回到 FIQ) -我认为该0x5400的正确位置是 sl_ESM.c,因为这与测试有关,而不是实际的故障处理,如果这是真正的故障,则无需在应用程序端写入0x5400来处理故障,以防代码执行需要继续...
    e2e.ti.com/.../2217778
    -在 sl_sem.c 中设置0x5400之后,应用程序只需等待 ESM3错误弹出,并在处理实际测试时在应用程序端类似地处理它


    ////// 了解信息很好

    平均时间我改进了数据中止屏蔽了这个帖子中代码的位(只是试图防止实际错误不被意外屏蔽掉、 因此、基本而言、每个屏蔽确定至少有2个"密钥"、需要进行匹配才能屏蔽数据中止、从而使其在发生单点故障时更可靠、并在进行测试时捕获可能的真实错误。 在写入0x5400值时、也可以在 sl_ESM.c 中设置一些标志、该值将在此处选中并清除、这样每次测试只允许一次屏蔽、但这需要修改 sl_ESM.c、这可能会在应用 CSP 时导致更多的手动工作)。

       //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN,但在 FIQ 中断中切换内容
       if (((sl_FLAG_GET ((Int32) flash_address_parache_self_test)))&& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE,0x5400U))
       {  //注意:JSI 14.6.2017:如果启用了 FIQ、此测试也会导致数据中止
           if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障,而不仅仅是信任 sl_FLAG_GET_VALUE
           {
               maskDAbort = true;
           }
       }

    这里是我针对故障注入变体的电流屏蔽逻辑(在 DIAG_vEsmAppCallback()内 )如果 tEsmFiCb.bFlashPar_2-flag 已经被清除、ESM3错误就会被删除)
       //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN,但在 FIQ 中断中切换内容
       if (((sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_FAULT_INPUT))& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE,0x5400U))
       {  //注意:JSI 14.6.2017:如果启用了 FIQ、此测试也会导致数据中止
           if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障,而不仅仅是信任 sl_FLAG_GET_VALUE
           {
               //这里是屏蔽的逻辑
               布尔 bFlashAddParCb = tEsmFib.bFlashPar_2;

               callbkParam1 = sl_flashWREG->FUNCHERRADD;
               callbkParam2 = sl_flashWREG->FEDACCSTATUS;
               uint32 u32Error = Set_HIWORD_U32 (ESM_Group_3)| Set_LOWORD_U32 (ESM_G3ERR_FMC_Uncorr);
               DIAG_vEsmAppCallback (u32Error、callbkParam1、callbkParam2、callbkParam3);

               if ((bFlashAddParCb)&&(!tEsmFib.bFlashPar_2))
               {
                   maskDAbort = true;
               }
           }
       }

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

    您好、Jarkko、

    您在下面引述的回复中包含的注释。

    [引用用户="Jarkko Silvasti"]

    您好!

    只是为了澄清:这是否意味着、在当前形式的代码中、如果启用了 FIQ、那么组3错误+中止是运行此测试的"实际且预期"副作用-而不是我一侧的某种编码错误?

    根据代码的当前状态、我认为可以预期出现的异常和中断。 我不能说的是、如果这意味着测试运行正确、异常处理正确。 我们需要确定异常的根本原因、以确定是否可以避免异常、或者我们是否将其保留为测试的预期结果。 在我看来、这个测试是测试闪存地址奇偶校验特性、这是 ESM G2 CH4、并且不应该触发其它 ESM 错误或中止、但是、也许有一个逻辑原因尚未被识别。

    如果这是真正的确定性副作用、我至少可以忍受该组3错误、因此我不需要从 RAM 运行代码来防止它发生或其他任何更复杂的事情-如果这种行为、我可以很容易地看到 ESM3/ABORT 属于测试 在原始测试中记录并正确处理。 积分器随后还可以"复制逻辑"进行故障注入测试、因为这是预期行为。

    在您提到设置了哪个 G3通道标志的线程中、我看不到任何位置、但我假设它是指示不可纠正的闪存错误(2位或更多错误)的通道7。 这可能是由于闪存中可用于两个测试的某些共享位置造成的、但即使是这种情况、也不必要、因为读取的数据不必有数据错误来检查闪存地址奇偶校验。

    我在这里尝试询问这些诊断模式的实际作用是什么、 由于我不理解为什么这个 ESM3参加这个测试(仍然不理解它-但如果这是真正的副作用、也许我不需要理解它-只要知道 ESM3/ABORT 将被激活是有原因对我来说就足够了)、 当从 FIQ 返回时、Eesm3/abort 将会激活、并执行下一行代码-因此基本上在 FIQ 中执行的 C 代码不会导致该行为。 还想知道为什么 FIQ 中需要手动写入0x5400、因为应该存在"自动清除"DIAG_TRIG、但测试中根本没有设置 TRIG 位、即使 TRM 5.6.2表示如果 DIAG_TRIG 不是、也仍然会生成初始 esm2错误 设置... 但是、如果此测试的 ESM3/ABORT 功能"已确认"、我很可能也不需要了解这方面的详细信息... 只要我需要自己进行相当“繁重”的修改,我就想知道根本原因,因为通常如果你不理解根本原因,“修复”可能是完全错误的,即使它看起来是有效的,并且可能导致更灾难性的失败...

    https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/603175

    我同意在没有适当背景/背景的情况下进行修改可能会掩盖真正的问题或以某种方式挫败测试的预期用途。 这就是我们在此帮助扩展对测试的理解的原因。 当然、查看数据表和 ESM 错误类型会有所帮助、但并不能得出结论。 这些器件非常复杂、需要学习很多细节、并需要查看大量文档才能完全理解。 即使这样、文档中的含义有时也会丢失、没有实际的真实使用和示例。 我还没有机会详细查看您的链接帖子、但我计划查看每个帖子、以确保我们捕获 SafeTI Diag Lib (SDL)的问题。 因此、我们可以在下一个版本中包含尽可能多的修复程序、我们将尽可能地将 其纳入计划中、以满足您的项目要求。

    //////////// 故障注入变体的更多信息
    这里其他用户的 ESM3问题完全相同(在同一测试的故障注入变体中-我遇到了相同的问题、但由于找到了一种方法来"修复"实际测试、因此相同的步骤适用于故障注入变体)。 想知道为什么有人说测试运行不会出现问题、以防 ESM3出现上述状态的" IDE 影响问题"、或者此测试在不同的 CPU 型号上的工作方式不同、因为需要修改最低0x5400来防止连续 FIQ 环路、具体取决于 可能还需要0x5400位置设置手动 SR1 ACK、以便甚至达到 ESM3/ABORT 弹出的状态、因为至少在我的代码中、"辅助 FIQ"将被解释为真正的故障、因为"一次性消耗性 FI 标志"不再有效、因为它已经失效 在第1轮中清零、代码最终在 while (1)循环中?
    https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/608591

    以下是我的故障注入版本体验(基本上、如果在 sl_ESM.c 中为该测试设置相同的0x5400、您就可以使用该版本 (或在应用程序端 ESM-ERROR 处理程序中执行此操作、但您需要手动将同时挂起的 FIQ 从 SR[1]中删除、因为它已自行恢复、如果没有手动恢复、则代码在退出后立即跳回到 FIQ) -我认为该0x5400的正确位置是 sl_ESM.c,因为这与测试有关,而不是实际的故障处理,如果这是真正的故障,则无需在应用程序端写入0x5400来处理故障,以防代码执行需要继续...
    e2e.ti.com/.../2217778
    -在 sl_sem.c 中设置0x5400之后,应用程序只需等待 ESM3错误弹出,并在处理实际测试时在应用程序端类似地处理它

    对于故障注入模式的实际用途、我仍然有点困惑。 当然、如果系统级通知正确到位、它可用于测试错误路径和处理、但我最初的理解是、它将用作最终用户开发其安全系统时进行验证的工具。 即、它可用于描述错误响应。 我不确定每个测试都需要包含 FI 测试、也许只能考虑基本元素。 但是、这取决于系统级要求、我们依赖于终端应用集成商对如何使用提供的软件的经验和判断。

    ////// 了解信息很好

    平均时间我改进了数据中止屏蔽了这个帖子中代码的位(只是试图防止实际错误不被意外屏蔽掉、 因此、基本而言、每个屏蔽确定至少有2个"密钥"、需要进行匹配才能屏蔽数据中止、从而使其在发生单点故障时更可靠、并在进行测试时捕获可能的真实错误。 在写入0x5400值时、也可以在 sl_ESM.c 中设置一些标志、该值将在此处选中并清除、这样每次测试只允许一次屏蔽、但这需要修改 sl_ESM.c、这可能会在应用 CSP 时导致更多的手动工作)。

       //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN,但在 FIQ 中断中切换内容
       if (((sl_FLAG_GET ((Int32) flash_address_parache_self_test)))&& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE,0x5400U))
       {  //注意:JSI 14.6.2017:如果启用了 FIQ、此测试也会导致数据中止
           if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障,而不仅仅是信任 sl_FLAG_GET_VALUE
           {
               maskDAbort = true;
           }
       }

    这里是我针对故障注入变体的电流屏蔽逻辑(在 DIAG_vEsmAppCallback()内 )如果 tEsmFiCb.bFlashPar_2-flag 已经被清除、ESM3错误就会被删除)
       //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN,但在 FIQ 中断中切换内容
       if (((sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_FAULT_INPUT))& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE,0x5400U))
       {  //注意:JSI 14.6.2017:如果启用了 FIQ、此测试也会导致数据中止
           if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障,而不仅仅是信任 sl_FLAG_GET_VALUE
           {
               //这里是屏蔽的逻辑
               布尔 bFlashAddParCb = tEsmFib.bFlashPar_2;

               callbkParam1 = sl_flashWREG->FUNCHERRADD;
               callbkParam2 = sl_flashWREG->FEDACCSTATUS;
               uint32 u32Error = Set_HIWORD_U32 (ESM_Group_3)| Set_LOWORD_U32 (ESM_G3ERR_FMC_Uncorr);
               DIAG_vEsmAppCallback (u32Error、callbkParam1、callbkParam2、callbkParam3);

               if ((bFlashAddParCb)&&(!tEsmFib.bFlashPar_2))
               {
                   maskDAbort = true;
               }
           }
       }

    一般而言、我认为异常处理程序作为示例/演示项目的一部分包含在简单示例中。 CSP 不会涵盖这些内容、因为 CSP 仅用于库。 再说一次、这是我的理解、我需要检查这一点才能确定。
    在本主题中、您是否计划使用包括 LDRA 工具在内的完整 CSP? 或者、您是否计划仅使用报告/配套资料证据? 我们讨论了免费提供报告的问题、以便使用 SDL 的客户不会发生任何变化(或仅适用于客户未更改的部件)。 或者、客户可以使用代码并编译、只要他们使用相同的编译器版本和选项、以便 TI 生成的报告仍然适用。
    此外、为了澄清这一点、您使用的是 SafeTI 诊断库的 v2.3.1、对吧?

    [/报价]

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

    我是在度假,这就是为什么延迟答复的原因。

    是的、它会将 ESM 通道位与已猜中的中止一起升高、即编号7 "ESM_G3ERR_FMC_Uncorr"。


    是的、我们目前使用的是 SafeTI 版本2.3.1。


    由于我听说新版本即将推出、我想它会显示此测试的状态吗? 我不介意、如果您可以在这里告诉您、将来它只会发出预期组2错误或该组3错误的信号、以及该组3错误的原因是什么/是什么、原因是什么是它出现/出现-只是为了提高我自己对器件的理解、 从我的中止处理程序代码中可以看到、违规地址是0x20000000、它是镜像闪存、根据该代码应该包含1位错误、#define flashBadECC1 0x20000000u?


    我想这有点偏离主题、但尝试回答您提出/提到/想问的问题:

    我认为、实际 SafeTI 测试对应的故障插入测试应在产品开发期间至少运行一次、可能在代码中带有条件编译标志、以便测试系统是否能够对故障做出反应。 我选择在运行时与常规测试一起运行它们、因为实际上、在构建测试线束时、执行此操作所需的工作量非常小(并且比手动运行更具成本效益)。 但正如您所说的,这是积分器确定何时/如何运行它们的问题,有些积分器可能根本不运行它们,它可能仍然是任何其他方法的有效方法:)... 我习惯做一点"额外"、只是为了确保、而不是用几乎相同的时间来解释为什么不需要这样做。


    对于 CSP、我们的最初意图是"按原样"使用此 SafeTI 库代码、然后使用这些文档、以最大限度地缩短与认证相关的工作时间(如果需要、还可能运行 LDRA 测试)、 但是、在当前的形式中、直接方法似乎是不可能的、因为需要对 SafeTI 代码进行一些(不多)手动更改、因此在任何情况下都需要进行一些额外的手动工作。 让我们看看是否希望新发布的版本会改变这种情况、并且代码可以按原样使用。 更好的是、如果免费收到用于"认证"的文档、因为如果2.3.1正确理解、即使不使用 LDRA、您仍需要购买该 CSP 才能获取文档?

    根据您的评论、即将发布的版本将不包含文档(免费)、如果它将仅声明 CCStudio 的状态库设置、用户可以使用它编译库、然后在 IAR 中使用它? 使用未经修改的库当然是最简单的方法(在任何情况下都是首选方法)、但让我们看看这是否可行。 这种与免费文档捆绑在一起的方式也将具有成本效益和时间效益、如果可能的话、我们很可能会选择这种方式。

    整个"如何认证"概念对我们来说仍然有点开放/模糊、因为我们之前仅使用了自己的代码、即已准备好的认证代码和第三方代码、这些代码没有任何预先制作的安全资料。 因此、这种采用 CSP 的第三方代码对我们来说是新代码、这就是为什么我无法说出我们最终如何"认证"的原因、但我们认为、从现在开始、我们一直在获得执行所需的 SafeTI 测试以及整个产品(我们的、而不是 SafeTI) 因为之前没有任何需要证明的东西... 尤其有雾的是、如果我们需要对 CSP 代码进行1行更改、那么该怎么办、只需将文档用于其余代码、例如、使用审阅来证明更改的正确性和/或基于自己或 LDRA (如果购买了该封装) 已更改零件的单位测试。 我们还计划制作基于 RM44的产品、以便在您能够与特定认证流程取得一定的协同增效时、这可能是进行此操作的最佳方式、同时还请记住、现有产品可能会收到更新、该更新会在板上获取新的 SafeTI 项目(测试)...

    如果你有这方面的建议,我愿意倾听,尽管我没有作出与金钱有关的决定:)。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jarkko、

    欢迎回来。 我希望您有一个美好的假期。

    [引用用户="Jarkko Silvasti"]由于我听说新版本即将发布、我想它将显示此测试的状态吗? 我不介意、如果您可以在这里告诉您、将来它只会发出预期组2错误或该组3错误的信号、以及该组3错误的原因是什么/是什么、原因是什么是它出现/出现-只是为了提高我自己对器件的理解、 从我的中止处理程序代码中可以看到、违规地址是0x20000000、它是镜像闪存、根据该代码应该包含1位错误、#define flashBadECC1 0x20000000u?[/quot]

    我无法谈论将要实施的特定修复、因为这是一个不同的组。 我可以说、您的担忧以及触发错误故障和中止的事实已记录在错误报告中。 地址0x2000000是否有一个单一位或不可纠正的错误取决于诊断模式7的配置。 我的理解是、这个模式允许一个值与 ECC 字节进行异或、以创建指定的错误。 如果在 XOR 设置中选择的值不正确、很可能会导致多个位错误。

    [引用 USER="Jarkko Silvasti">我认为、实际 SafeTI 测试对应的故障插入测试应在产品开发期间至少运行一次、可能需要在代码中使用条件编译标志、以便测试系统是否能够对故障做出反应。 我选择在运行时与常规测试一起运行它们、因为实际上、在构建测试线束时、执行此操作所需的工作量非常小(并且比手动运行更具成本效益)。 但正如您所说的,这是积分器确定何时/如何运行它们的问题,有些积分器可能根本不运行它们,它可能仍然是任何其他方法的有效方法:)... 我习惯做一点"额外"、只是为了确保、而不是用几乎相同的时间尝试解释不需要这么做的原因。

    我同意这种看法。 我可以看到、在系统运行期间运行的故障插入会根据系统运行时间的长短增加一些值。 某些情况下、这些插入测试将验证错误路径是否正常工作以及诊断故障检测是否正常工作、因此这对于某些情况下的潜在故障诊断而言是完美的、但也可能与某些附加的功能诊断软件测试重叠。

    [引述 USER="Jarkko Silvasti">CSP 的说法、我们的最初意图是"按原样"使用此 SafeTI 库代码、然后使用这些文档来最大限度地减少与认证相关的工作时间(如果需要、还可能运行 LDRA 测试)、 但是、在当前的形式中、直接方法似乎是不可能的、因为需要对 SafeTI 代码进行一些(不多)手动更改、因此在任何情况下都需要进行一些额外的手动工作。 让我们看看是否希望新发布的版本会改变这种情况、并且代码可以按原样使用。 更好的是、如果免费收到用于"认证"的文档、因为如果2.3.1正确理解、即使不使用 LDRA、您仍需要购买该 CSP 才能获取文档?

    根据您的评论、即将发布的版本将不包含文档(免费)、如果它将仅声明 CCStudio 的状态库设置、用户可以使用它编译库、然后在 IAR 中使用它? 使用未经修改的库当然是最简单的方法(在任何情况下都是首选方法)、但让我们看看这是否可行。 这种与免费文档捆绑在一起的方式也将具有成本效益和时间效益、如果可能的话、我们很可能会选择这种方式。

    整个"如何认证"概念对我们来说仍然有点开放/模糊、因为我们之前仅使用了自己的代码、即已准备好的认证代码和第三方代码、这些代码没有任何预先制作的安全资料。 因此、这种采用 CSP 的第三方代码对我们来说是新代码、这就是为什么我无法说出我们最终如何"认证"的原因、但我们认为、从现在开始、我们一直在获得执行所需的 SafeTI 测试以及整个产品(我们的、而不是 SafeTI) 因为之前没有任何需要证明的东西... 尤其有雾的是、如果我们需要对 CSP 代码进行1行更改、那么该怎么办、只需将文档用于其余代码、例如、使用审阅来证明更改的正确性和/或基于自己或 LDRA (如果购买了该封装) 已更改零件的单位测试。 我们还计划制作基于 RM44的产品、以便在您能够与特定认证流程取得一定的协同增效时、这可能是进行此操作的最佳方式、同时还请记住、现有产品可能会收到更新、该更新会在板上获取新的 SafeTI 项目(测试)...
    [/报价]

    遗憾的是、对于 CSP 以及如何提供这些封装以及以何种成本提供这些封装、我并不处于主要决策路径中。 我确实理解它们背后的概念、只能提供成本与 Tau (测试自动化单元)真正相关的信息、其中包括测试套件和 LDRA 有限使用许可证。 我们讨论了如何发布 CSP 报告/纸质文档、这些文档记录了 TI 使用特定编译器和特定构建选项完成的测试。 因此、如果您使用提供的二进制文件、或在不使用相同编译器和选项进行任何修改的情况下按原样编译源文件、以创建完全相同的由 TI 测试和发布的二进制文件、 CSP 静态和动态报告以及 TI 认证的软件开发流程通常足以满足客户安全系统中的组件资质。

    我认为、您使用的是与 TI 编译器不同的经过认证的编译器、该编译器经过认证并用于构建经 TI 测试的代码、 即使您未修改代码、这些报告也不适用、然后您需要使用 TAU 工具对生成的二进制文件进行回归测试。

    最后、它实际上是关于安全标准的合规性。 我们尝试重新创建的是一个合规流程(通过流程认证进行证明)以及该流程生成的证据、就像我们的客户在开发其安全系统时所做的那样。 这种差距通常出现在详细信息中、例如我们已讨论何时发现错误或客户的构建环境与我们的不同。 为了解决这个问题、我们提供了 TAU/LDRA 解决方案。  

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

    [引用用户="Chuck Davenport"]

    我认为、您使用的是与 TI 编译器不同的经过认证的编译器、该编译器经过认证并用于构建经 TI 测试的代码、 即使您未修改代码、这些报告也不适用、然后您需要使用 TAU 工具对生成的二进制文件进行回归测试。
    只需继续这个"非主题"、如果我错了、请纠正我的错误、但我已经假设应该可以使用 TI 工具编译库、然后在 IAR 中使用该库? 这样、我们应该能够使用准确指定的编译器版本和设置(即使我们需要对代码进行更改、例如仅对1个函数进行更改、否则其余未修改的代码将直接符合您的测试文档)。

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

    您好、Jarkko、

    [引用用户="Jarkko Silvasti">要继续此"非主题"、请更正我、以防我出错、但我假设应该可以使用 TI 工具编译库、然后在 IAR 中使用该库? 这样、我们就应该能够使用准确指定的编译器版本和设置(即使我们需要对代码进行更改、例如仅对1个函数进行更改、否则其余未修改的代码将直接符合您的测试文档)。

    当然可以。 此外、如果您以这种方式接近项目、如果您修改代码的案例非常有限、则可以像为项目编写的任何其他代码那样开发自己的测试/计划。 即、遵循您自己的软件开发流程、该流程符合安全标准、有助于避免从 LDRA 和我们的软件团队购买 Tau 工具。