[参考译文] RM48L952：即使 PARFLG 为0、在 VIM_SRAM_奇 偶校验_TEST 之后、有时会多次调用 FBPARERR 地址

您好！

我开始怀疑我的2个 CPU 有某种程度的损坏、因为我的同事以完全相同的方式加载了完全相同的二进制文件、并且他们不会收到任何伪 VIM 奇偶校验错误调用/打印...


我最初也遇到过 VIM 奇偶校验测试失败、这是因为在某个时候、VIM 测试很可能无法翻转奇偶校验位或打开 VIM RAM 进行写入... 我的实际代码在假期中因 VIM 奇偶校验失败而在6、5天后跳闸、并且日志中也有这些剧烈的 FBERRADD 地址调用(当时无法获得 SafeTI 测试失败的更详细原因、但原因很可能与下面描述的相同)。

在"错误的 CPU 确定"之前、我通过在中间具有较小操作系统延迟的 while 类型循环中仅运行 VIM 奇偶校验测试来"加速"事情、而问题的出现速度比以前快得多。

我还简单地说了"记录器"、即在触发一次时这些虚假呼叫的实际数量(在 vimParityErrorHandler (如果 PARFLG = 0)中)。 因此、奇偶校验错误看起来很长时间保持活动状态... 我收集了每一个连续的呼叫，每行中出现的呼叫彼此小于100us，因此错误处理程序函数会被调用~1200次，以防它被调用一次：)。
时间：0、呼叫：1、总计：1 @ 1755ms //这行可以忽略，因为它是在杂散错误开始时打印的
时间：967us、呼叫：1199、总呼叫：1200 @ 2584ms
时间：968us、呼叫：1190、总计：2390 @ 19019ms
时间：968us、呼叫：1188、总计：3578 @ 19848ms
时间：968us、呼叫：1188、总计：4766 @ 20677ms
时间：968us、呼叫：1189、总呼叫：5955 @ 28496ms
时间：769us、呼叫：933、总线：6888 @ 31232ms
时间：966us、呼叫：1188、总呼叫：8076 @ 32061ms
时间：968us、呼叫：1189、总呼叫：9265 @ 32890 ms
时间：967us、呼叫：1188、总计：10453 @ 33719ms
时间：968us、呼叫：1186、总呼叫：11639 @ 47214ms
时间：967us、电话：1188、电话：12827 @ 48043ms

以下是一个部分、其中行之间的总时间为16秒...
时间：967us、电话：1183、总电话：431397 @ 2128063ms
时间：967us、呼叫：1184、总呼叫：432581 @ 2144498 ms <LF

下面是"加速测试循环"、您可以看到每~5ms 进行一次测试、杂散跟踪器检测到杂散调用仅持续~1000us、因此在启动新测试之前有时间结束杂散调用 (从上面的帖子可以看出虚假呼叫在测试后立即开始)。 此外、根据该毫秒时间戳、我们可以看到虚假呼叫发生的情况比进行测试时少得多、从~1sec 到甚至16sec。

while (1)
｛
WOS_vDelayMs( 5U )；

#include "sl_api.h"
静态布尔值 bOnce = false；
静态 uint8 u8Expected = 0U；

WOS_vCsEnter()；//禁用 IRQ

if (!bOnce)(如果！bOnce
｛
u8Expected =* vimRAMParLoc；
BOnce = true；
｝
if (* vimRAMParLoc！= u8Expected)
｛
DBG_PRINT ("预测试奇偶校验位：0x%x\r\n"、* vimRAMParLoc)；
｝
if (!sl_SelfTest_VIM (VIM_SRAM_parity))
｛
DBG_PRINT ("奇偶校验测试失败\r\n)；
｝
if (* vimRAMParLoc！= u8Expected)
｛
DBG_PRINT ("测试后奇偶校验位：0x%x\r\n"、* vimRAMParLoc)；
｝
WOS_vCsExit()；//启用 IRQ
｝


对于在帖子开头所涉及的"奇偶校验 RAM 访问错误"、这种情况在该"加速代码"至少运行了224sec (最后一次印戳)之后发生。 因此、"首先打印 PARFLG 或 ESM_REG、这表示已使用 parityRAM 启动测试、其值为 OK =上一次测试的 POST 值也正常。 但在失败后、也会打印测试后的白线、这意味着在 SafeTI 内部注入错误之前、没有发生 RAM 访问(PARCTL 打开失败) 或者奇偶校验位没有翻转、当测试结束时、RAM 再次打开、位再次翻转、这会将奇偶校验 RAM 置于错误状态、测试后检查失败、之后的所有测试也开始失败...
时间：967、呼叫：1185、总呼叫：452471 @ 2242578 ms
时间：967、呼叫：1182、总呼叫：453653 @ 2243407ms
时间：967、呼叫：1185、总呼叫：454838 @ 2244236ms
时间：967、呼叫：1184、呼叫：456022 @ 2245065ms
PARFLG 或 ESM REG：0x0 | 0x0
奇偶校验测试失败
后测试奇偶校验位：0x1
预测试奇偶校验位：0x1
PARFLG 或 ESM REG：0x0 | 0x0
奇偶校验测试失败
后测试奇偶校验位：0x1
预测试奇偶校验位：0x1
PARFLG 或 ESM REG：0x0 | 0x0
奇偶校验测试失败
后测试奇偶校验位：0x1
预测试奇偶校验位：0x1
PARFLG 或 ESM REG：0x0 | 0x0
奇偶校验测试失败


这里是 SafeTI 内部错误打印的来源...
如果(((sl_vimParREG->PARFLG & VIM_PAR_ERR_FLG)== 0U)||
(((sl_esmREG->SR1[0U]和 get_ESM_bit_NUM (ESM_G1ERR_VIM_奇 偶校验_CORRERR))== 0U))
｛
/* VIM RAM 奇偶校验错误未被标记为 ESM。 *
DBG_PRINT ("PARFLG 或 ESM REG：0x%x | 0x%x\r\n"、SL_vimParREG->PARFLG、SL_esmREG->SR1[0U])；
RetVal = false；
｝


我还将检查 SafeTI 内部、以检查它是否是 PARCTL 和奇偶校验位翻转失败、因为在当前设置中、实际测试失败迟早会到达(无需等待数小时)...

问题：基于打开帖子和此帖子、CPU 的坏情形是否可能是原因？ 我强烈认为，由于相同的二进制文件可以与同事的 CPU 一起使用，因此不需要额外的打印(那些带有“时间...”的行) 由于奇偶校验错误处理程序不应被调用...

问题：如果这可能是原因、 我们如何检测各个故障 CPU、因为在12秒测试周期内、持续6.5天、直到出现基于 SafeTI 测试的实际诊断错误、正式测试周期为1h、这意味着如果概率保持不变、VIM RAM 奇偶校验测试将在运行后失败 5、34年导致客户流程虚假跳闸... 这两种情况都使得生产测试仪无法发现此类故障...

这段时间内、~75min 出现错误 RAM 访问错误(~900000实际测试)

时间：967、呼叫：1182、总呼叫：636400 @ 4551078 ms
时间：967、呼叫：1183、总呼叫：637583 @ 4551907 ms
在翻转失败后：0x1与0x1 //下面是 SafeTI 测试失败的根本原因
PARFLG 或 ESM REG：0x0 | 0x0
奇偶校验测试失败
测试后奇偶校验位：0x0
预测试奇偶校验位：0x0
PARFLG 或 ESM REG：0x0 | 0x0
奇偶校验测试失败
测试后奇偶校验位：0x0

当写入 VIM RAM 时、实际 SafeTI 测试失败看起来与问题有关、因为"翻转失败后"打印出现此错误、并且我们未收到预测试打印、因此 PARCTL 寄存器在写入时更改了它的状态。

/*禁用 ESM 错误影响*/
SL_esmREG->DEPAPR1 = GET_ESM_BIT_NUM (ESM_G1ERR_VIM_parity _ CORRERR)；

uint8 u8Value =* vimRAMParLoc；
/*启用奇偶校验测试模式*/
/*SAFETYMCUSW 9 S MR：12.2. 注释_10*/
/*SAFETYMCUSW 134 S MR：12.2 备注_5*/
bit_set (sl_vimParREG->PARCTL、VIM_TEST_MODE)；

if (sl_vimParREG->PARCTL == regBackupPCR)
｛
DBG_PRINT ("PARCTL FAIL：0x%x vs 0x0x\r\n"、SL_vimParREG->PARCTL、regBackupPCR)；
｝

/*翻转 VIM RAM 奇偶校验位置中的位*/
/*SAFETYMCUSW 9 S MR：12.2. 注释_10*/
bit_flip ((* vimRAMParLoc)、0x1U)；

if (* vimRAMParLoc =u8Value)
｛
DBG_PRINT(“翻转失败后：0x%x 与0x%x\r\n”，*vimRAMParLoc，u8Value )；
｝

所以我的两个 CPU 中都有 VIM 和 VIM RAM 相关的问题(假设情况2是 VIM 问题(因为当 VIM 运行时、不应该加载那个过孔矢量)和情况1 VIM RAM 问题)
1) 1)插入到 FBERRADDR 寄存器中的地址会被调用"具体时间"(在本例中、总时间为75分钟、即637583次)、当进入名为 ERROR 函数的 VIM 时、即使是 PARFLG = 0、 如果调用该值一次、则将连续多次调用(每例中持续~770-1000us 的行为900-1200次、实际只能看到2个值、相差超过几个~770us 和~970us)
2) 2) VIM RAM 位翻转失败极少导致实际 SafeTI 失败

只需再更新一次、情况看起来比以前更加奇怪、因为现在其他故障 CPU 开始工作...

今天、我用2个发生故障的 CPU 中的其他代码进行了其他代码开发、这基本上意味着整个 CPU 闪存被重新刷写、因为其他开发包含大量更改。 现在、当恢复"加速"二进制文件(也打印了发生过多少次并行错误调用)时、我再也看不到什么了、因此情况与同事在 CPU 中下载二进制文件时差不多。

以下是该单元的故障 CPU 输出、该单元目前尚未重新刷写：
FW CRC：匹配：0x27ffc66b

您好！

感谢您的反馈、根据您的信息、我设法创造了一种情况、即如果我只承认 PAR_FLG、那么很显然只承认这种情况是不够的、FBPARERR 就会被持续调用。 但是、这仍然不能解决我原来的问题、即当不应该调用奇偶校验错误处理程序并且 VIM RAM 位翻转失败时、将调用奇偶校验错误处理程序...

假设 VIM 也以某种方式"修复了自己"、即使只重新调用了 PAR_FLG、但它需要特定的事件发生、这在任何地方都没有记录、因为根据我的代码、如果 IRQ 矢量中存在奇偶校验错误、FBERRADD 地址调用会在某个点停止、  还测试了如果 您在错误处理程序中向 ESH 高矢量注入错误并仅清除 PAR_FLG、VIM 会始终调用 FBPARERR 地址、因此代码永远不会返回到应用程序...

另请注意、只有奇偶校验真正中断的 VIM 矢量位于地址0xFF280008中(数据表6-31显示它被保留、因此 VIM 不应尝试从它加载任何内容)、 并且由 SafeTI-library 对矢量进行操作、而 VIM 不应使用该矢量。 此外、VIM RAM 在开始时被执行 PBISTed、所以一切都应该正常...

因此、根据您的输入、此 TRM 语句至少不准确、因为清除 PARFLG 基本上不会对 IRQVECREQ 或 FIQVECREQ 产生任何影响、该语句声称在清除 PAR_FLG 后、不会再向 VIC 提供 FBPARERR 值：
"在 PARFLG 寄存器被清零之前、提供给 VIC 端口的值也将反映 FBPARERR "

这里还声称、清除 PAR_FLG 已经足够了-根据您的输入和我的重新测试、这看起来并不是一种情况、最初这种方法看起来很有效、因为我没有在奇偶校验错误处理程序中打印任何内容、因为调用看起来会在一段时间后停止。
e2e.ti.com/.../1131734

问题：如果我正在进行 SafeTI VIM RAM 奇偶校验测试(在执行测试时禁用中断)、并且奇偶校验断开且手动读取矢量以生成所需的奇偶校验错误、同时和/或在 PAR_FLG 上升后出现一些实际中断(例如、RTI) 对于 VIM、这是否会导致 VIM 停止将向量加载到 IRQVECREQ 并保持 IRQVECREQ 中的 FBPARERR、即使 SafeTI 代码也会在退出函数之前手动清除 PAR_FLG？ 这仍然不能解释为什么完全相同的二进制文件在不同 CPU 中的工作方式不同、这意味着其他 CPU 不会生成任何 FBPARERR 地址调用、而是多次调用它们...


我还在 HALCoGen 函数中提到了上述问题。 它通过写入 const 数组(s_vim_init)中的值来修复矢量
/*更正损坏的位置*/
vimRAM->ISR[ERROR_CHANNEY]= s_vim_init[ERROR_CHANNEY]；

如果您使用 SafeTI-library、您的 sl_ESM_Init（)-function 会更改 VIM-RAM 内容(两个 ESM 矢量)或者如果您使用 vimChannelMap（)函数、则会发生相同的情况。 在这两种情况下、HALCoGen 函数都会将错误的矢量恢复到 RAM、它会修复奇偶校验、但会调用矢量-不好...
也就是说、至少我不能使用 HALCoGen 函数、它甚至没有用户代码段来修改函数的行为。

下一个问题与 SafeTI 和可能的 ESM 高矢量损坏有关、无法使用 HALCoGen 函数、因为它调用 HALCoGen 中的 ESM 函数、而在使用 SafeTI 时不使用这些函数。 您也不能执行此操作、因为它看起来代码无法正确地从 pfEsmHigh 返回、pfEsmHigh 会无限地被调用、因为 PC=0x24794会调用该 pfEsmHigh()地址(BLX R0) 当进入该函数时、LR 为0x24798、退出该函数时、PC 设置为 LR-4 == 0x24794、这与调用该函数指针的行相同...
                   if (u32Vec ==0U)
                   ｛
                       //注：矢量0位于 VIM RAM 的插槽1中
                       //t_isrFuncptr pfEsmHigh = vimRAM->ISR[1]；

                       vimREG->INTREQ0 = bit_n( u32Vec )；//手动将其重新封装
                       pfEsmHigh()；   //注意：无法调用，因为此函数被声明为__Fiq，因此无法正确返回
                  ｝

基本上可以做的就是这样、但这要求您必须将 SafeTI 函数的声明从静态更改为"外部"才能到达它们、因此这也不是诱人的选择
                   //如果 ESM 为高电平，则无法禁用/启用它，必须从此处调用
                   if (u32Vec ==0U)
                   ｛
                       DBG_PRINT ("ESM HIGH_\r\n")；
                       //注：矢量0位于 VIM RAM 的插槽1中
                       //t_isrFuncptr pfEsmHigh = vimRAM->ISR[1]；/* lint！e9078！e923 */* r11.4 & r11.6 PD */

                       vimREG->INTREQ0 = bit_n( u32Vec )；//手动将其重新封装
                       //pfEsmHigh()；   //注意：由于此函数为"FIQ"，因此无法调用，无法正确返回

                       u32Vec = esmREG->IOFFHR；

                       if (u32Vec！= 0U)//实数 ESM 错误
                       ｛
                           u32Vec--；//标准化

                           extern void esmGroup1Handler (uint8 esmChannel)；
                           extern void esmGroup2Handler (uint8 esmChannel)；
                           if (u32Vec < 32U)
                           ｛
                               esmGroup1Handler (u32Vec)；
                           ｝
                           否则 if (u32Vec < 64U)
                           ｛
                               esmGroup2Handler (u32Vec-32U)；
                           ｝
                           否则 if (u32Vec < 96U)
                           ｛
                               esmGroup1Handler (u32Vec-32U)；
                           ｝
                           其他
                           ｛
                               esmGroup2Handler (u32Vec-64U)；
                           ｝
                       ｝
                       其他
                       ｛
                           DBG_PRINT ("ESM vector was 0\r\n")；
                       ｝
                   ｝

还测试了当读取 IOFFHR 寄存器时、FIQVECREQ 从 FBPARERR 地址更改为 ESH 高矢量地址、因此基本上、如果奇偶校验处理程序中未处理 ESM 高异常、它将永远丢失(如果它是组2错误、因为 IOFFHR 复位 SR[1]寄存器...

因此、我决定修改 SafeTI FIQ 处理程序、以便绕过函数的实际内容、现在可以从 FBPARERR 函数调用该函数、其他选项是在 ESM 高电平错误时停止 CPU、这样就无需接触 SafeTI 代码。
静态空 SL_ESM_HIGH_intr 处理程序(空)
｛
   extern void sl_ESM_HIGH_handler (void)；
   SL_ESM_HIGH_handler ()； // JSI 30.10.2017：使用包装器也可以从 VIM RAM 奇偶校验错误处理程序中使用它
｝


所以奇偶校验错误处理程序函数现在看起来是这样的(stil 不确定是最优/正确的)
[代码]
_IRQ
静态空 vimParityErrorHandler( void )
｛
   typedef volatile struct vimRam
   ｛
       t_isrFuncPTR ISR[VIM_CHANNELS]；
   } vimRAM_t；

   #define vimRAM ((vimRAM_t *) 0xFFF82000U)

   //如果奇偶校验错误处理不当，VIM 将继续重新触发此函数，因为 IRQVECREQ 和 FIQVECREQ 中的矢量没有更新
   if (VIM_PARFLG == 0U)
   ｛
       DBG_PRINT ("==VIM_PARFLG：0x%x @%u us =\r\n"、VIM_PARFLG、HAL_u32TimeGet ()))；
   ｝
   其他
   ｛
       /*标识损坏的地址*/
       uint32 u32ErrorAddr = VIM_ADDERR；
       /*识别信道编号*/
       uint32 u32ErrorChannel =(uint32)((u32ErrorAddr & 0x1FFU)>> 2U)；
       /*清除奇偶校验错误标志*/
       VIM_PARFLG = 1U；

       if (u32ErrorChannel < VIM_CHANNELS)
       ｛
           (void) vimRAM->ISR[ u32ErrorChannel ]；/*lint !e9078 !e923 */* r11.4 & r11.6 pd *//重新读取同一个矢量

           if (VIM_PARFLG！= 0U) //再次测试奇偶校验器
           ｛
               dbg_print_panic ("\r\n\r\n=VIM RAM 奇偶校验错误-永久错误：%u =\r\n\r\n"、u32ErrorChannel)；
               WOS_vInfiniteLoop ()；
           ｝
           其他
           ｛
               /*临时错误，确认参数已足够*/
               DBG_PRINT ("\r\n=VIM RAM 奇偶校验错误-通道：%u @%u us =\r\n"、u32ErrorChannel、HAL_u32TimeGet ()))；
               //模仿 HALCoGen 的功能-为了获得 VIM 下载新矢量 IRQVECREQ 和 FIQVECREQ、需要此功能
               uint32 u32Vec = 0U；
               /*禁用并启用最高优先级的挂起通道以重新触发实际中断*/
               if (vimREG->FIQINDEX！= 0U)
               ｛
                   u32Vec = vimREG->FIQINDEX；
               ｝
               其他
               ｛
                   u32Vec = vimREG->IRQINDEX；
               ｝

               //检查它是否为实数向量(不只是生成的错误)
               if (u32Vec！= 0U)
               ｛
                   u32Vec--；//从0开始标准化
                   //如果 ESM 为高电平，则无法禁用/启用它，必须从此处调用
                   if (u32Vec ==0U)
                   ｛
                       vimREG->INTREQ0 = bit_n( u32Vec )；//注意：不需要
                       extern void sl_ESM_HIGH_handler (void)；
                       sl_ESM_HIGH_Handler()；
                       //注：矢量0位于 VIM RAM 的插槽1中
                       //t_isrFuncptr pfEsmHigh = vimRAM->ISR[1]；/* lint！e9078！e923 */* r11.4 & r11.6 PD */
                       //pfEsmHigh()；   //注意：由于此函数为"FIQ"，因此无法调用，无法正确返回
                   ｝
                   否则 if (u32Vec < 32U)
                   ｛
                       vimREG->REQMASKCLR0 = bit_n (u32Vec)；
                       vimREG->REQMASKSET0 = bit_n (u32Vec)；
                   ｝
                   否则 if (u32Vec < 64U)
                   ｛
                       vimREG->REQMASKCLR1 = bit_n (u32Vec)；
                       vimREG->REQMASKSET1 = bit_n (u32Vec)；
                   ｝
                   其他
                   ｛
                       vimREG->REQMASKCLR2 = bit_n (u32Vec)；
                       vimREG->REQMASKSET2 = bit_n (u32Vec)；
                   ｝
               ｝
           ｝
       ｝
       其他
       ｛
           dbg_print_panic ("\r\n\r\n==VIM RAM 奇偶校验错误-通道错误：%u =\r\n\r\n"、u32ErrorChannel)；
           WOS_vInfiniteLoop ()；
       ｝
   ｝
｝
[/代码]

但是、如果我在持续 while (1)循环中运行 sl_SelfTest_VIM (VIM_SRAM_paratiation_test)(在进行调用时禁用中断、然后再次启用)、这些修复或原始 HALCoGen 函数奇偶校验错误处理程序函数都不起作用。 系统一直调用 VIM 奇偶校验错误处理程序、并且在一段时间(非常快)后、VIM RAM 奇偶校验位翻转也会失败。 这表示 VIM 中最有可能出现一些故障...

如果在 SafeTI 函数调用之间使用1ms (1tick)操作系统延迟(实际上是1-2ms 延迟、具体取决于节拍发生的时间)、则"这次使用此二进制文件"我看不到任何错误、没有单个奇偶校验错误处理函数调用或奇偶校验位翻转问题(后者可能需要一些时间)。 因此、在奇偶校验错误注入之间产生延迟会"修复"故障行为、这也表明 VIM 中确实存在一些故障。

问题：如果某些中断也处于活动状态、那么如果 PAR_FLG =0、应该读取 FIQINDEX / IRQINDEX (&interrupts 禁用/启用)、因为使用 HALCoGen 函数时、如果 SafeTI 调用之间没有延迟、那么不会频繁调用奇偶校验错误处理函数？ 我仍然认为、在这种情况下、这个函数不应该被调用一次、所以不管你是否读取这些 FIR / IRQ 索引、但是如果 VIM 变得很好、很可能其他方法比其他方法更好... 因此、如果在代码中持续注入和测试奇偶校验故障、则会出现一些问题、即使测试中的 VIM 地址也是如此、VIM 本身也不应使用...

当从 main()运行测试而不启动操作系统时，也设法获取这些调用

_sl_Restore_IRQ (0x00U)；//强制启用 IRQ
while (true)
｛
vVimParityTest( true )；
｝

在每次10000tests 后打印状态时，它看起来是这样的
测试：22260000，parityerrors：13.
测试：22270000，parityerrors：13.
测试：22280000，parityerrors：14
测试：22290000，parityerrors：14

在每1000次测试后打印时(更多打印、更多中断->我们在打印时使用 DMA、因此每次打印仅产生1个中断)
测试：788000，parityerrors：96
测试：789000，并行错误：96
测试：790000，parityerrors：96
测试：791000，parityerrors：97
测试：792000，parityerrors：98
测试：793000，parityerrors：98
测试：794000，并行错误：98
测试：795000，parityerrors：99
测试：796000，parityerrors：99
测试：797000，并行错误：99
测试：798000，parityerrors：100
测试：799000，parityerrors：100

和测试功能本身
void vimParityTest(布尔 bNoOS )
｛
u32Tests++；
#include "sl_api.h"
静态布尔值 bOnce = false；
静态 uint8 u8Expected = 0U；

易失性 uint32 irqStatus；
if (bNoOS)
｛
irqStatus =_sl_Disable_IRQ ()；
｝
其他
｛
WOS_vCSEnter()；
｝

if (!bOnce)(如果！bOnce
｛
u8Expected =* vimRAMParLoc；
BOnce = true；
｝
if (* vimRAMParLoc！= u8Expected)
｛
静态布尔 bOnce1 = false；
if (!bOnce1)
｛
bOnce1 = true；
DBG_PRINT ("预测试奇偶校验位：0x%x\r\n"、* vimRAMParLoc)；
｝
｝
if (!sl_SelfTest_VIM (VIM_SRAM_parity))
｛
静态布尔 bOnce2 = false；
if (!bOnce2)
｛
bOnce2 = true；
DBG_PRINT ("奇偶校验测试失败\r\n)；
｝
｝
if (* vimRAMParLoc！= u8Expected)
｛
静态布尔 bOnce3 = false；
if (!bOnce3)
｛
bOnce3 = true；
DBG_PRINT ("测试后奇偶校验位：0x%x\r\n"、* vimRAMParLoc)；
｝
｝

if (bNoOS)
｛
_SL_Restore_IRQ (irqStatus)；
｝
其他
｛
WOS_vCSExit()；
｝



if ((u32Tests % 1000U)== 0U)
｛
DBG_PRINT ("测试：%u，parityerrors:%u\r\n"，u32Tests，u32ParityHanderCalls)；
｝
｝

将此计算器添加到 HALCoGen 奇偶校验错误处理程序中、以记录每个 PAR_FLG = 0条目
/*识别信道编号*/
uint32 error_channel=((error_addr 和0x1FFU)>> 2U)；

extern uint32 u32 ParityHanderCalls；

if (VIM_PARFLG =0)
｛
u32 ParityHanderCalls++；
｝

if (ERROR_CHANNEL >= VIM_CHANNELS)


可以看到、其他 CPU 活动会影响奇偶校验错误应答调用、这意味着其他 IRQ 与 SafeTI VIM 奇偶校验同时到达、会产生一些副作用...

Jarkko Silvasti、您好、

您是否能够解决 PARFLG = 0时频繁的奇偶校验处理程序调用的问题？ 如果遵循中断线的禁用和启用、处理程序将以干净的方式清除挂起的中断。
如前所述、即使您在禁用中断的情况下运行 VIM 奇偶校验测试、也有可能同时发生其他一些中断。 矢量地址寄存器 VIM 仍将指向 parityHandler。 但是、由于处理程序以干净的方式清除中断、它不应反复分支到奇偶校验处理程序。 每次检测到奇偶校验错误时、将调用一次(PARFLG = 1)。 如果情况不是这样，请告诉我
遗憾的是、TRM 中提到的说法不正确。 清零 PARFLG 不会用实际的 ISR 地址复位向量地址。 我会向有关人士汇报。
作为 HALCoGen 的一部分提供的奇偶校验处理程序是一个参考代码。 它被定义为弱函数。 您可以重新定义相同的内容。 它假定 VIM 被 vimInit 初始化并且不受干扰。
此外、VIM RAM 奇偶校验位翻转失败意味着什么？ 您是否意味着 sl_SelfTest_VIM 函数完成的奇偶校验位翻转不能按预期工作？

谢谢、此致、
Veena

您好！

我认为我现在能够修复"频繁"/"重复"良好的调用、因此在运行 SafeTI 测试时、有时只调用一次奇偶校验处理程序、但下面您的句子与我的观察结果不符、但我想我现在知道发生了什么以及原因。 从 main()运行代码时，如果没有操作系统....，我还成功地获得了我的最新的上述处理程序卡在奇偶校验错误
[引用 user="Veena Kamath"]每次检测到奇偶校验错误时，将调用一次(PARFLG = 1)。
-当 PARFLG = 0时，该函数实际上可能会被调用。

首先、PARFLG = 0调用案例：

如前所述、我使用了 HALCoGen 默认处理程序、其中添加了以下记录器
   if (VIM_PARFLG =0)
   ｛
       u32 ParityHanderCalls++；
   ｝

现在晚上运行时，今天早上的结果就是这样，每1/816次测试都会导致奇偶校验处理程序激活(任何值也可能溢出)。
测试：2749988000，parityerrors：3367989

因此、很显然、奇偶校验处理程序会在 PARFLG = 0时被调用、但现在得出的结论是、在 SafeTI 正在进行测试时、VIM 注册其他中断的情况下、必须发生这种情况
[引用 user="Veena Kamath"]矢量地址寄存器 VIM 仍将指向 parityHandler。
在这种情况下、由于 IRQVECREQ 或 FIQVECREQ 矢量地址被放置在奇偶校验处理程序的位置、因此在 SafeTI 测试结束时清除 SafeTI PARFLG 还不够、就像在奇偶校验处理程序中也不够(在没有中断到达的情况下仍然足够) ->如果由于 SafeTI 测试、某些中断在 PARFLG = 1时到达、这将导致1个对奇偶校验处理程序的调用、其中 PARFLG = 0。

===>您能确认这一结论吗？

然后，在不使用操作系统的情况下从 main()中使用处理程序时，处理程序被卡住：
由于我在 PARFLG = 0的情况下执行了任何操作，因此代码会存至重复的 parityhandler 调用循环。 这必须是由以下事实引起的：在 main()用例中，仅在打印整行后出现与 debug_print 相关的 DMA BTC 中断。 如果在实际应用中使用相同的处理程序、它不会卡在奇偶校验处理程序调用循环中、只会导致对处理程序的"某些"重复调用。

因此、如果新中断在 PARFLG 为0时到达、即使 IRQVECREQ 包含奇偶校验错误处理程序地址、VIM 也必须加载具有适当矢量的 IRQVECREQ。 这意味着奇偶校验错误处理程序必须像 HALCoGen 一样做出反应/工作、在 PARFLG = 0的情况下、中断使能/禁用部分(如果有任何激活和切换、则读取)也是如此。 基本上、在这个 PARFLG =0情况下、不应该做什么是读取 VIM_ADDER 寄存器并尝试恢复那个矢量(不会伤害吗？) 由于没有奇偶校验故障、根据 TRM、寄存器的内容是有效的 (假设内容始终为0或以前的失败地址、因此它将始终处于"有效范围"、这意味着如果只是写入该矢量、则不会发生任何数组访问溢出)...

那么、基本上、有问题的情形就像这样开始
1：禁用中断(CPU I 位)
2、SafeTI 开始测试并继续到目前为止使 PARFLG = 1 (尚未清除)
3.中断(IRQ)到达 VIM -> VIM 将 IRQVECREQ 设置为并行处理程序地址
4、SafeTI 完成 PARFLG 测试= 0
中断使能(CPU I 位)
6. VIM 赢得 IRQVECREQ ->调用奇偶校验处理程序

现在、如果奇偶校验处理程序未重新启用活动 IRQ 且没有更多 IRQ 发出、则 IRQVECREQ 不会更新、但如果有 IRQ 发出、它看起来会更新、以便解除卡纸锁定(这是任何地方也不会读取的内容)。

因此、结论是、尽管是 PARFLG 0或1、但奇偶校验处理程序中始终需要重新启用中断、如果为0、则无需尝试修复任何 VIM 矢量...
===>您能确认这一结论吗？

endof main()不带操作系统案例...

[引用 user="Veena Kamath">此外，VIM RAM 奇偶校验位翻转失败意味着什么？ 您是否意味着 sl_SelfTest_VIM 函数完成的奇偶校验位翻转不能按预期工作？
是的、它看起来是这样的、我几乎100%确定打印件不会说谎。 在某些时候、测试无法翻转奇偶校验 RAM 中的位。 根据打印的结果、问题是实际翻转时不打开 RAM 进行写入。

但是、由于在至少进行了2749988000测试的夜间测试中不再发生这种情况、因此(希望)问题必须与虚假/连续奇偶校验处理程序调用相关、以便这些调用在某个地方发生中断(即使它不应影响位翻转)。 如何仍然考虑从运行时测试中禁用 VIM RAM 奇偶校验测试、因为它确实提供了任何合适的方法来确保这个位翻转不会出现问题、因此测试失败永远不会发生。


将这两个部分固定好后、我认为这个问题已经处理、我会将您的答案标记为已验证(然后希望不会再次出现奇偶校验翻转问题)。


[引用 user="Veena Kamath"]作为 HALCoGen 的一部分提供的奇偶校验处理程序 是一个参考代码。
是的、明白这一点、但由于任何地方都不会有任何评论、因此很难知道哪些器件像在参考中一样至关重要(或至少实现类似的最终结果)、哪些器件也不重要。 然后，混合使用 TRM，它说如果您从那里读取，会给您带来一个陷阱，因此重新编写参考代码以满足您自己的需求是很重要的:)。 我认为自己很幸运能够在我的处理程序中看到这个问题(使用奇偶校验位错误测试处理程序、这些错误在处理程序内部已修复 (用于测试目的)、这是不够的、因为其他 IRQ 使 VIM 刷新矢量、因为 PARFLG 在修复后为0、 应该只在一个中断处于活动状态时进行测试:)),如果我的通用 SafeTI 测试周期是1h 与12sec 的目标值，那么在代码运行很长时间之前，它可能不会弹出可见...

可以看到、该中断重新启用部分看起来是极端关键的、如果没有它、则性能影响最小、更糟的是、如果没有新的 IRQ 进入 vim、则总网格锁定会更严重。 然后、代码的矢量修复部分很可能会在发生实际奇偶校验错误时损坏矢量、并且您已使用运算来更改 VIM RAM 中的矢量。 因此、代码的"一半"是强制性的、而代码的"一半"是我不能建议按原样使用的。


如果有人感兴趣、那么这里是一个函数、他希望能够像 HALCoGen 一样正常工作、但不会尝试从 ROM 中恢复矢量(仅在确认后仍存在故障时检查并停止) 并且还应使用 SafeTI ESM 高损坏案例、因为它使用在 sl_ESM.c 下生成的包装程序函数来转移_Fiq 函数调用返回值问题。
[代码]
_IRQ
静态空 vimParityErrorHandler( void )
｛
   //模仿 HALCoGen 在此函数中的功能
   typedef volatile struct vimRam
   ｛
       t_isrFuncPTR ISR[VIM_CHANNELS]；
   } vimRAM_t；

   #define vimRAM ((vimRAM_t *) 0xFFF82000U)

   // VIM_ADDERR 中的地址仅在 PARFLG = 1时有效，如果 PARFLG 为0，则修复/检查向量中也没有任何内容
   if (VIM_PARFLG！= 0U)
   ｛
       /*标识损坏的地址*/
       uint32 u32ErrorAddr = VIM_ADDERR；
       /*识别信道编号*/
       uint32 u32ErrorChannel =(uint32)((u32ErrorAddr & 0x1FFU)>> 2U)；
       /*清除奇偶校验错误标志*/
       VIM_PARFLG = 1U；

       if (u32ErrorChannel < VIM_CHANNELS)
       ｛
           //注：可以在此处添加矢量恢复，但需要将 sl_ESM_Init()& vimChannelMap()对矢量的更改考虑在内
           (void) vimRAM->ISR[ u32ErrorChannel ]；/*lint !e9078 !e923 */* r11.4 & r11.6 pd *//重新读取同一个矢量

           if (VIM_PARFLG！= 0U) //再次测试奇偶校验器
           ｛
               dbg_print_panic ("\r\n\r\n ==VIM RAM 奇偶校验错误-永久错误：%u、%u =\r\n"、u32ErrorChannel、VIM_PARFLG)；
               WOS_vInfiniteLoop ()；
           ｝
           其他
           ｛
               /*临时错误，确认参数已足够*/
               //DBG_PRINT ("\r\n=VIM RAM 奇偶校验错误-通道：%u @%u us ==\r\n"、u32ErrorChannel、HAL_u32TimeGet ()))；
           ｝
       ｝
       其他
       ｛
           dbg_print_panic ("\r\n\r\n==VIM RAM 奇偶校验错误-通道错误：%u =\r\n\r\n"、u32ErrorChannel)；
           WOS_vInfiniteLoop ()；
       ｝
   ｝

   //为了获取 VIM 下载新矢量 IRQVECREQ & FIQVECREQ，始终需要此选项，在 PARFLG = 0的情况下也是如此
   //处理程序需要重新启用中断，因为在 PARFLG 为0时，IRQVECREQ 不会被释放，直到其它 IRQ 发出
   uint32 u32Vec = 0U；
   /*禁用并启用最高优先级的挂起通道以重新触发实际中断*/
   if (vimREG->FIQINDEX！= 0U)
   ｛
       u32Vec = vimREG->FIQINDEX；
   ｝
   其他
   ｛
       u32Vec = vimREG->IRQINDEX；
   ｝

   //检查它是否为实数向量(不只是生成的错误)
   if (u32Vec！= 0U)
   ｛
       u32Vec--；//从0开始标准化
       //如果 ESM 为高电平，则无法禁用/启用它，必须从此处调用
       if (u32Vec ==0U)
       ｛
           vimREG->INTREQ0 = bit_n (u32Vec)；//看起来可能不需要...
           extern void sl_ESM_HIGH_handler (void)；
           sl_ESM_HIGH_Handler()；
           //注：矢量0位于 VIM RAM 的插槽1中
           /*t_isrFuncptr pfEsmHigh = vimRAM->ISR[1];*/*lint !e9078 !e923 */* r11.4 & r11.6 PD */
           //pfEsmHigh()；   //注意：由于此函数为"FIQ"，因此无法调用，无法正确返回
       ｝
       否则 if (u32Vec < 32U)
       ｛
           vimREG->REQMASKCLR0 = bit_n (u32Vec)；
           vimREG->REQMASKSET0 = bit_n (u32Vec)；
       ｝
       否则 if (u32Vec < 64U)
       ｛
           vimREG->REQMASKCLR1 = bit_n (u32Vec-32U)；
           vimREG->REQMASKSET1 = bit_n (u32Vec-32U)；
       ｝
       其他
       ｛
           vimREG->REQMASKCLR2 = bit_n (u32Vec-64U)；
           vimREG->REQMASKSET2 = bit_n (u32Vec-64U)；
       ｝
   ｝
｝
[/代码]