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:VIM RAM 在 VIM RAM 奇偶校验期间损坏-看起来非常时间敏感并且需要同时使用 DMA (或者 DMA IRQ)

Guru**** 2481465 points
Other Parts Discussed in Thread: HALCOGEN, CCSTUDIO, TMDSRM48HDK, SEGGER

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/663406/rm48l952-vim-ram-corrupts-during-vim-ram-parity-test---looks-to-be-very-time-sensitive-and-requires-simultaneous-dma-usage-or-dma-irq

器件型号:RM48L952
主题中讨论的其他器件:HALCOGENCCStudioTMDSRM48HDKSEGGER

您好!

很抱歉发帖很长、但问题很复杂...

我们发现、如果"Moon 在执行测试时正确对齐 mars"、VIM RAM 矢量在 VIM RAM 奇偶校验测试期间/之后会损坏"...
测试是 SafeTI-test (sl_SelfTest_VIM (VIM_SRAM_parity Check ())还是 HalCoGen 测试(vimParityCheck ()),这一点无关紧要
2.可以 IAR 和 CCStudio 中重新生成行为,并在 while 循环中运行 main()中的代码,因此操作系统活动/实际应用程序无关紧要
3.这对时序/配置非常敏感,例如,在启动 VIM PBIST 和 VIM 奇偶校验未被启用的情况下,附加的 CCStudio 项目不会失败(没有单独测试这些测试),而当前项目在 main ()中的571次测试(u32TestCnt =571)后总是失败。
4.被测向量被破坏、看起来至少较低字节一直被转换为0x00或0x01 (奇怪的是 IAR 显示只有最低字节被改变、但 CCStudio 显示整个向量被改变)。 无论测试的矢量是0xFFF82000还是0xFFF82008、都无关紧要。
5.您似乎还需要一些其他中断活动/源(如 RTI)来禁用测试中断-如果没有中断、也不会使我们的 IAR 主循环测试仪崩溃。


其他通知:
a) VIM_FBPARERR 函数被调用很多-几乎每次测试都被调用、但并非每次都被调用(通常为 PAR_FLG = 0、因此这是"重影调用")。 即使设置为 VIM RAM 不会损坏、也会调用此函数
这也很奇怪
b)有时只有 VIM 矢量被破坏、如果你将它修复在"之后"分支中、一切都正常。 但有时它也会在 FLG = 1时触发 VIM_FBPARERR、在这种情况下、您还会像这样获得 ESM 错误

状态(984599651|1|1|1007999222)
之后:VIM_RAM 不同:0x1与0x53bec 之间- 1007999431 //粗体为当前测试编号
VIM_FBPARERR:修正通道:2 -- 1007999431 //粗体为当前测试编号,因此测试后 FLG = 1
ESM:1、CH:15 P1:0xFF82008、P2:0x0、P3:0x0 @ 0ms //这是 ESM 低电平中断处理程序
ESM:已激活失效防护:G:1通道:15
状态(1002149607|2|2|1025999160)

有时您只会遇到矢量损坏-这毫无意义。 我们的打印缓冲区非常大,当时经过全面测试,我确信在这种情况下打印不会丢失99999999%
状态(2054919|0|0|2099865)
之后:VIM_RAM 不同:0x0与0x53bec 之间- 2099909
状态(2347396|1|0|2399839)



我们的 IAR-project main()看起来与 CCStudio 相似(决定进行 OS 依赖测试,但在运行时操作系统处于活动状态时可以看到非常类似的"行为"):

/////////////////////////////////// 代码//////////////////////////////////
   #define vimRAMLoc      ((volatile UINT32 *) 0xFFF82008U)

   uint32 u32Address =* vimRAMLoc;

   布尔 bFail = false;
   uint32 u32Time = 0U;
   while (bFail == false)
   {
       u32Temppi++;

       if (* vimRAMLoc!= u32Address)
       {
           DBG_PRINT(“条目: VIM_RAM 分配不同: 0x%x 与0x%x\r\n”,*vimRAMLoc, u32Address );
       }
       SL_VIM_FailInfo failInfoVIM ={.stResult = ST_FAIL};/*错误注入测试可能根本无法设置此值*//*lint !e785 */*仅初始化一个实例*/
       disable_IRQ_interrupt_();
#if 0
       布尔 bRetVal = sl_SelfTest_VIM (VIM_SRAM_paratiation_test,&failInfoVIM);

       sl_SelfTest_Result failInfo = failInfoVIM.stResult;
其他
       vimParityCheck();
       布尔 bRetVal = true;
       SL_SelfTest_Result failInfo = ST_PASS;
#endif

       if (* vimRAMLoc!= u32Address)
       {
           DBG_PRINT ("之后:VIM_RAM 不同:0x%x 与0x%x --%u\r\n",* vimRAMLocc,u32Address,u32Temppi);
           //bFail = true;//强制停止

           u32VIMRAM_Corr.++;
           * vimRAMLoc = u32地址;
       }

       if ((!bRetVal)||(failInfo!= ST_PASS))
       {
           DBG_PRINT ("VIM 测试失败:%u\r\n",failInfoVIM.failInfo);
       }

       _enable_interrupt_();

       if (HAL_u32TimeGet ()-u32Time >60U*1000U*1000U)
       {
           u32Time = HAL_u32TimeGet ();
           外部 uint32 u32Calls;
           extern uint32 u32 Fix;
           DBG_PRINT ("状态(%u|%u|%u|%u|%u)\r\n"、u32连体 工作、u32VIMRAM_Corr、u32Fiux、u32Temppi);
       }
   }

   while (1);
/////////////////////////////////// 代码结束//////////////////////////////////////////////////////////////

在 Hercules RM48 MCU 演示套件(TMDSRM48HDK)中失败的 CCStudio 项目:

-这个项目使用纯粹的 HalCoGen 文件、对任何东西进行0手动修改
-在此项目中、中断未"正确"禁用(I 位状态不会保留在禁用中、并且在启用时使用)、但由于中断禁用和启用在该 CCStudio 项目中的2个位置使用、这是正常的、因此由于嵌套禁用-禁用-启用-启用模式、IRQ 无法启用。
e2e.ti.com/.../6886.VIM_5F00_RAM_5F00_TEST.zip

请注意、此处的"调试打印"也得到了极大简化、它将在输入调试打印时触发1个"foo\r\n"打印-这足以导致故障。 如果您请求打印更多内容,它将始终触发相同的 foo\r\n,尽管您将其作为参数提供。 使用 DMA 完成打印。 当进行571次测试时,它会进入“测试后 RAM 矢量损坏”分支,这样也启动 DMA 的初始打印“设置”就不会改变 VIM RAM 内容,因为570次测试可以进行而不会损坏....

认为在 CCStudio 代码中、应用程序将写入 VIM RAM 的可能性是零、在我们的实际应用中、变化了0.0001%。

-在 IAR 中,我已经用 SEGGER 观察点检查了没有人写入该 VIM RAM 矢量 (在将矢量校正回已检测到损坏的 if-sentece 内部时、观察点在测试后触发-这也证明观察点有效、它还应证明我们的实际 IAR 应用不会写入该 VIM RAM 区域)。

此外、VIM RAM 测试受中断禁用/启用保护、因此任何人都无法写入该寄存器、 唯一的可能性是 DMA、但由于我们只有1个通道在使用中、它会写入 UART、并且您会在 UART 中看到文本、因此 DMA 不可能写入 VIM RAM (不知道/尚未测试观察点是否也能够看到 DMA 写入)...

在我们的实际 IAR 应用程序和 main()测试循环中,VIM RAM 故障的可能性在很大程度上取决于调试打印活动您打印的 VIM RAM 损坏错误越多, 此外、RTI 周期似乎具有效果1ms 周期产生的误差小于100us 周期、而10us 周期产生的误差小于100us。。。
-通过5秒的测试间隔,我们可以在数小时到数天内运行实际应用程序代码,直到该损坏在4小时到一周内随机发生,这表明出现的错误需要一些神奇的事件和时间来匹配,以实现 VIM RAM 损坏...

在这里,我每60秒打印一次主 while 循环中的状态,说明只发生了一些错误:
状态(1546199563|2|2|1583998758)

格式为: 测试完成后 FB_PARERR |检测到的 RAM 损坏总量| FB_PARERR FLG == 1次调用|进行的测试
因此、几乎每次测试都会触发这些 FLG =0调用、RAM 只损坏2次、两次也会触发 FLG =1调用

在同一主 while 循环中打印相同的状态、但每1秒打印一次、错误比率会大得多

状态(17815128|1155|29|780321957)

之后:VIM_RAM 不同:0x51300与0x513f8 -- 780322779

状态(17819918|1156|29|780531940)

之后:VIM_RAM 不同:0x51300与0x513f8 -- 780532761

状态(17824708|1157|29|780741923)

之后:VIM_RAM 不同:0x51300与0x513f8 -- 780742218

状态(17829498|1158|29|780951906)

之后:VIM_RAM 不同:0x51301与0x513f8 -- 780952137

VIM_FBPARERR:修正通道:2 -- 780952137 /这不会检查向量值是否有效、它只是从备份表将值写入给定的向量

ESM:1、CH:15 P1:0xFF82008、P2:0x0、P3:0x0 @ 0ms

ESM:已激活失效防护:G:1通道:15

之后:VIM_RAM 不同:0x51300与0x513f8 -- 780953681

状态(17834280|1160 | 30|781161858) //请注意,现在它从29变为30,因为我们也得到了 FLG=1 FBPARERR 调用



在实验过程中、还注意到以下情况:

-如果在 VIM 初始化之后和 main ()之前、您将被测试的"保留"矢量至少设置为0x1或0x0、而不是该"phantomInterrupt" 、则 SafeTI VIM RAM 测试偶尔会开始失败、而失败的原因是 ESM 通道未激活 (未使用 HalCoGen-test 对其进行测试)。

状态(7892|0|0|3367759)

状态(9473|0|0|3579331)

之后:VIM_RAM 不同:0x10x0之间- 3579770 //此处我们已手动将 vector 设置为0x0,因此在测试完成后它已更改为0x1,只需将其修复

状态(11046|1|0|3790893)

状态(11046|1|0|4000888)

VIM 测试失败:5. //Now actual VIM test failed after 400 manned test, 5== ESM channel has not activated during the test/*  Check if ESM group1 channel 15 is not flagged */ anned branch in sl_selftest.c //此后会出现更多故障,因此这不是唯一的故障

VIM_FBPARERR:修正通道:2 -- 4001073 //无“打印后 RAM 上下文正常,但在 SafeTI 测试之后进入实际的 FB_PARERR 处理程序//我们有自己的函数,只有在 FLG = 1时才会打印此函数

ESM:1、CH:15 P1:0xFF82008、P2:0x0、P3:0x0 @ 0ms //并且也得到 ESM 错误

ESM:已激活失效防护:G:1通道:15

状态(12622|1|1|4212427)

状态(14201|1|1|4424000)


因此、在这种情况下、RAM 内容未损坏、但仍设置了 FLG = 1、但 SafeTI 无法看到 ESM 错误...

最初、我们注意到了这个问题、因为我们的测试偶尔失败、检查了 VIM RAM 内容(VIM RAM 上的 CRC)、 然后我们减少了测试、以便我们只进行 VIM 奇偶校验测试和 VIM RAM 内容测试、并加快了测试间隔->开始更频繁地失败->然后开始在 CRC 失败期间打印 VIM RAM 的内容->注意到第二个矢量的值错误-> 在每个测试前后添加了校验、该校验是正确值的矢量。 之后、我花了~4天时间来测试 IAR 的不同组合、最近从头开始构建 CCStudio 项目、并评估了需要在那里做些什么才能使它同样失败、现在我得到了...

但我仍然无法准确地说这失败的原因、基本上需要启动和 RTI&DMA 中的某些 VIM PBIST 和一些 DMA 活动来获得该故障、如果您删除1个项目、您很可能不会遇到任何故障、但在我们的实际应用中、每个元素都在使用中。 对我来说、这看起来是 CPU 问题、无法防止...

我们需要了解发生了什么以及原因、猜测从运行时测试中删除 VIM RAM 奇偶校验测试(不提供任何适合的优势)可以消除此问题。 但这只是解决了问题、而不是问题背后的问题。同样的问题是否也会以其他方式出现->如果是、那么我们的 VIM RAM CRC 测试再次失败、系统跳闸...
-当执行 VIM_FBPARERR 处理程序 以使用 SafeTI ESM 矢量并恢复正确的内容时 (向量在 vimInit()之后被修改)我注意到那些“幽灵”FLG =0调用,但当时决定忽略这些调用,因为发生的次数相当小,我们有 FLG =0防护装置,以防止任何有效的处理,那些只消耗少量 CPU 时间的调用。 但现在想这些 FLG =0调用是更严重问题的症状、而那些 FLG =0调用也存在于纯 HalCoGen 项目中、当执行 HalCoGen 的 vimrampar奇 偶校验时...


问题1:CPU VIM_RAM 处理中是否存在一些错误/问题、这些错误/问题会导致奇偶校验测试期间发生损坏、勘误表中应记录这些错误/问题?
问题2:为什么在矢量不是"phantominterrupt"的情况下 SafeTI 测试开始失败、或者应该询问 ESM 通道为何在这种情况下不总是做出反应(由于发出错误信号、SafeTI 测试看起来工作正常)?

-现在在这些加速实验中使用"phantominterrupt"中断时、尚未收到任何 SafeTI-failures (在我们的实际应用中、我们总共看到过 Vim ram 奇偶校验测试失败2倍、但由于默认情况下测试不会说出失败的原因、我们不知道原因、 很可能是由于推测取指令而触发了 nERROR、或者发生了相同的 ESM 通道未激活问题-向 SafeTI 添加了原因、但之后没有得到该错误)
问题3:为什么这些 FBPARERR 调用会伴随 FLG = 0、这些调用不应该出现、因为中断被禁用了为什么进行测试、而是使 FLG 消失-而这些调用为什么不会出现在_evas_测试中?

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

    CCStudio 的屏幕截图丢失了、在这里再次说明、如果是分支、请参阅在内部"检查后"时如何将0xFFF82000更改为0x1

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

    嗯。 图片在"写入"视图中可见(复制和粘贴、但发送时会丢失(插入介质功能的新尝试)...

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

    有几个小错误、DMA 实际上根本没有被 CCStudio 启动、尽管它会(始终一次)导致错误。 因此、基本上可以排除它是导致某种情况的"DMA"。。

    然后我进行了轻微的代码更改(在检查内部中断之前移动了)->不再进入错误-->实时时序至关重要。

    已恢复该更改->再次出现错误...

    然后尝试更改/固定打印位(仍然没有启动任何 DMA)->未发生错误->实时时序关键...

    总的来说、我进行了几次更改、现在它始终如一地多次出现该错误(注释为 while (1) away to automatically seq multiple errors)->通过将断点放入错误分支 并等待它重新触发(或其他地方)可以看到错误 然后查看 u32VIMRAM_corr-variable 的错误量。

    查看此运行中的错误数与执行的测试数、在4,800万个测试运行中为11个



    下面是一个更强大的项目:
    e2e.ti.com/.../6170.VIM_5F00_RAM_5F00_TEST.zip

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

    感谢您的详细博文。 我将向我们的软件团队汇报、以便他们可以查看并查看我是否可以在工作台上重现此问题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Jarkko、

    快速更新...

    我能够下载、编译和加载您提供的代码(从您的上一篇文章中)。 但是、我还没有看到它捕获到错误。 我将启动它、让它持续一夜、看看这是否是我在长时间的跑步后能够捕捉到的更少发生的事情。

    正如您在帖子中提到的、DMA 永远不会启动、因此我从不会看到 SCI 上传输的任何数据。 我不知道这是否会影响事情。 两个 IDE 之间的情况似乎不应不同。 我尝试了代码初始化的几个部分、以查看是否可以启动代码;但是、我没有成功。 如果您能够在没有 IS 的情况下重新创建故障、这可能不是很重要。

    我很感兴趣的是、IAR 工具和 TI 工具之间存在不同的行为。 由于这是一个时序关键因素、它可能与它们之间的编译/二进制文件稍有不同相关、从而在时序上产生轻微差异、从而导致不同的行为。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Jarkko、

    另一个快速更新。 我现在可以使用提供的代码重新创建问题、而不会出现问题。 我能够看到 VIM RAM 内容损坏、导致出现0x00000001和0x00000000的内容。 我没有看到任何与测试时序的关系(换句话说、不能预测每一次测试运行都会导致损坏、或者每一次测试将是0x0和 mth 测试0x1等)。 我观察到了与您所描述的类似的情况、例如对代码的微小更改会影响损坏的频率、甚至可能导致损坏看起来完全消失。 我还注意到、删除 DBG_PRINT 代码也会导致问题消失、即使看起来 DMA 不起作用。 除此之外、我还注意到禁用中断也会导致问题消失。

    根据我到目前为止学到的知识、我仍然不能确定根本原因、但我认为它与 VIM RAM 测试期间发生的中断所导致的堆栈损坏有关。 我将在明天更深入地探讨这一点、并将在我的 COB 或更早的时间报告我的调查结果。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    很高兴您能够重复解决问题。

    快速问题:
    -您是否使用了第一个帖子或以后的一个帖子(第四个帖子)中的.zip 软件包? 应该使用更高版本的-zip 包、这应该会更加稳健、从而出现错误、在第一个软件包中、编译器版本很可能会产生影响。 我的目标是提供失败的数据包、第二个数据包应花费几秒钟的时间才能达到第一个错误、顺序错误应少于10秒钟。

    后来的.zip 封装应该始终如一地出现在这里-我没有测试/查看演示板上的实际 UART 引脚、因为我很高兴获得该 BTC 中断
    #pragma weak (dmaGroupANotification)
    void dmaGroupA 通知(dmaInterrupt_t inttype、uint32通道)

    /* 在用户代码开始和用户代码结束之间输入用户代码。 *
    /*用户代码开始(54)*/
    #ifdef DEBUG_MON
    #include "DMON.h"
       if (inttype == BTC)
       {
           if (channel ==(uint32) dma_ch_DBG_TX)
           {
               DMON_vPacketSent();//此处
           }
       }
    #endif


    堆栈损坏的原因:
    好主意、还必须更仔细地检查、但我们的实际应用中为每个 CPU 堆栈和每个操作系统任务堆栈都安装了堆栈监视器-此监视器不是实时的、而是在特定的时间段内执行、 但它对实际堆栈大小有20%的限制(或至少 nn 个堆栈项目)、因此在 IRQ、FIQ 或中止堆栈接近其实际大小时应发出警告/触发。
    -中断应在 VIM 奇偶校验测试期间被禁用、检查后(以及在第二个.zip 中之前)位于关键段内、所以只有运行过孔奇偶校验器的项目和运行过孔时、才应具有用于寄存传入中断的中断源。

    我不熟悉 CCStudio,可以从链接器输出中找到 IRQ 堆栈的位置/方式,但在 dmaBTCAInterrupt->dmaGroupANotification->DMON_vPacketSent->vStartDmaTransfer 内部,SP 为0x08001278,在检查内存浏览器时,直到0x08001000 (假设系统/用户模式从堆栈启动)

    在检查.map 文件时、它不显示0x08001500之前的内容(最可能的堆栈)、因此当从0x08001278->0x08001000开始为零时、我认为堆栈在这个"演示"中也是可以的
                     00006f74   00000008    (_TI_handler_table)
                     00006f7c   00000010    (_TI_cinit_table)

    .bss      0   08001500   000007f8    未初始化
                     08001500   000007d0    DMON_Main.obj (.bss:au8DataBuf)
                     08001cd0   00000028    sci.obj (.bss:g_sciTransfer_t)

    .data     0   08001cf8   0000002c    未初始化
                     08001cf8   0000000c    rtsv7R4_T_le_v3D16_eabi.lib:exit.obj (.data:$O1$$)
                     08001d04   0000000c    sys_main.obj (.data)
                     08001d10   00000009    DMON_Main.obj (.data)
                     08001d19   00000003    --孔--
                     08001d1c   00000008    rtsv7R4_T_le_v3D16_eabi.lib:_lock.obj (.data:$O1$$)

    然后从 HalCoGen 文件中找到这个、所以 IRQ 堆栈从0x08001300到0x08001200、所以 SP 为0x08001278当在 IRQ 中时、它显然位于安全区域内->这个问题"不能"与堆栈指针损坏相关...
    userSp .word 0x08000000+0x00001000
    svcSp  .word 0x08000000+0x00001000+0x00000100
    fiqSp  .word 0x08000000+0x00001000+0x00000100+0x00000100
    irqSp  .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100
    中止 Sp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100
    undefSp .word 0x08000000 + 0x00001000+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    还检查了 IAR 项目(当测试代码在 main ()的 while 循环内运行时,实际应用程序将开始),那里的堆栈比 CCStudio 中的堆栈大得多。

    IRQ 堆栈为0x08010f80 - 0x08010a80
    SP 0x08010f08当在中断处理程序中非常深时。

    此外、内存窗口还显示0x08010f00中最新的非零内容(因此这很可能是我们在 while ()循环测试器、堆栈监控器尚未初始化、它将填充相同的特殊模式到堆栈)、之后它只会一直为零到0x08010a80。 第一个非零内容出现在0x08010400 (这是我们的系统堆栈)中、零从0x080101b0开始、系统堆栈结束到0x08010020、因此这里还有足够的空间...

    IRQ 和 SYS-STACK 之间为 FIQ 和 SVC 堆栈0x300 (如果您想知道0x08010a80-0x600不是...400、这是因为我们还修复了每个 CPU 堆栈之间额外的空安全间隙、以便为堆栈监控检查提供额外的裕度、因为它主要用于任务堆栈大小检查、也受到 MPU 的保护、以防止泄漏) 因此、由于此时不使用 FIQ & Svc (我们不在 IAR 中使用 SafeTI 堆栈初始化、它将 CPU 保持/置于 Svc 模式)、IRQ-mode 基本上可以一直使用到 sys-stack...

    因此、在对两个项目(IAR 和 CCStudio)进行检查后、我会排除堆栈问题、原因有多种
    1)奇偶校验测试在关键部分内完成(测试代码关键部分也应检查、即使这些部分不是第1个帖子中规定的最佳/稳健性也是如此)
    2) 2)当中断处理程序相当深入时、SP 是可行的
    3) 3)堆栈内存区域在堆栈边界之前有很多0
    4) 4) SEGGER 针对受测 vim 矢量的观察点写入校验器在代码真正恢复 if 后检查中的矢量之前不会执行 trig 操作

    当然、可能还有其他类似的"愚蠢错误"导致了这种情况、但由于示例项目与实际应用相比非常简单、如果存在示例项目、则应该很容易找到它... 此外、如果存在 SEGGER 的观察点、则应触发该观察点。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢 Jarkko 提供的其他信息。

    这很难缩小范围、因为当我在项目中添加标记和调试代码时、问题发生的位置会移动或消失。 这就是我认为它与中断相关的原因。 也就是说、我想知道是否有一个中断触发在一个创建导致损坏的信标类型的时间点上。 这就是为什么我提到了堆栈、并且可能不是堆栈损坏、而是更多地说、在导致问题时、会为返回值加载错误的值。 当然、这只是推测、因为我无法将发生的事件与特定的时间间隔或 ISR 的执行相关联。 我将在周一继续查看、并尝试在事件发生时捕获一些时间戳、看看我是否可以将问题的发生与发生的中断之一相关联。

    通过我使用您的第4个帖子中的项目、这似乎很容易产生问题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jarkko、

    尽管我们没有明确确定哪个中断会导致干扰、但我们已经确定了代码的更改以及禁用/启用中断的方式、这似乎可以解决问题。 本质上、我们必须通过直接写入 VIM 来禁用和重新启用、如下代码片段所示。

    uint32 reqmaskbackup0;
    uint32 reqmaskbackup1;
    uint32 reqmaskbackup2;
    
    布尔 bFail = false;
    while (bFail == false)
    {
    //_disable_IRQ_interrupt_();
    
    //备份中断启用
    reqmaskbackup0 = vimREG->REQMASKSET0;
    reqmaskbackup1 = vimREG->REQMASKSET1;
    reqmaskbackup2 = vimREG->REQMASKSET2;
    
    //清除中断使能
    vimREG->REQMASKCLR0 = vimREG->REQMASKCLR0;
    vimREG->REQMASKCLR1 = vimREG->REQMASKCLR1;
    vimREG->REQMASKCLR2 = vimREG->REQMASKCLR2;
    
    u32TestCnt++;
    
    if (VIMRAMLOC!= u32ExpectedAddress)
    {
    while (1){};
    }
    
    vimParityCheck();
    
    if (VIMRAMLOC!= u32ExpectedAddress)
    {
    //bFail = true;//强制停止
    
    u32VIMRAM_Corr.++;
    VIMRAMLOC = u32指定地址;
    
    while (1){};
    }
    
    //_enable_interrupt_();
    
    //恢复中断启用
    vimREG->REQMASKSET0 = reqmaskbackup0;//= vimREG->REQMASKSET0;
    vimREG->REQMASKSET1 = reqmaskbackup1;//= vimREG->REQMASKSET1;
    vimREG->REQMASKSET2 = reqmaskbackup2;//= vimREG->REQMASKSET2;
    
    

    我对提供的示例项目进行了此更改、并在48小时内执行了该更改、但没有失败。

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

    大家好、太好了、

    如果我错了、请纠正我的问题、但该实验是否会显示 VIM 外设中存在一些未识别的问题、因为这两种方法都可以防止中断、但 CPU 内核的 I 位使用会在对 VIM 执行奇偶校验测试时导致 VIM 问题?

    该实验还会排除编码错误/堆栈损坏/从 IRQ 返回错误?

    使用这种方法、您是否获得了任何 FLG = 0的 VIM_FB_PAR_ERR 调用?

    为了澄清一下、您是否让其他调试打印关键部分成为_enable_interrupt_()? 如果是、这会将问题缩小到奇偶校验测试、以便在任何其他地方都可以正常使用常规内核 I 位、而不会出现任何问题(至少我们没有发现系统中的任何其他 VIM RAM 损坏或常规 I 位使用中的任何其他问题)?

    因此、解决此问题的一种方法可以是伪代码(例如、由于操作系统限制、在其他代码位置使用 I 位是非常必要的、因此我们使用的是经过认证的操作系统、因此无法更改其关键的进入/退出方法):
    1.输入通用 SafeTI 测试线束(在以下步骤中,整个真实线束并不像下面那样简单:)
    2. CPU I 位禁用
    3.如果 TEST = VIM RAM 奇偶校验
    3A。 备份和禁用 VIM 请求掩码
    4.进行1次 SafeTI 测试
    5.如果 TEST = VIM RAM 奇偶校验
    5A。 恢复 VIM 请求掩码
    6. CPU I 位使能
    7.退出通用 SafeTI 测试-线束

    基本上、处理 VIM RAM 奇偶校验测试的方式与处理任何其他 SafeTI 测试的方式稍有不同、在代码修改方面也很可能提供最简单/最佳的解决方案?

    我在同一个 CCStudio 项目中快速尝试了该伪方法(让您注释的 IRQ 启用/禁用行取消注释、只需在恢复后移动 I 启用即可)、并且没有收到任何错误、即使是具有 FLG = 0副作用的 VIM_FB_PAR_ERR 也没有收到任何错误...

    因此、FLG = 0调用也是实际的副作用、这表明如果出现这种情况、设置中的一切都不正常?

    因此、您的解决方案(以及在上面的真实代码中使用伪代码)将提供一种完全消除问题和副作用的方法、 因此、如果矢量内容正常、测试完成后无需手动 VIM RAM 内容检查和修复、之后处理/忽略 ESM IRQ ...

    但是、除非您能够找出根本原因、我们如何才能确保问题在运行1个月后确实消失了? 当然、我非常确信这个修复、因为对我来说、最初看起来在测试期间传入的 IRQ 和/或 DMA 传输(可能需要几个、也可能同时需要)是故障的原因。 由于修复 VIM 的工作方式很可能会有所不同、因为它不会在出现这些 IRQ 时立即注册这些 IRQ、它会在重新启用掩码时对它们进行注册、并且最有可能更改某些内容...

    您是否要进行勘误表输入或与此问题相关的内容(因为我怀疑这些 e2e-Links 是否能实现"永久")、因此有助于正确标记代码。

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

    我将要求查看我们是否可以获得一些设计资源来模拟此问题、但我不希望这种情况会发生、因为设计团队专注于高优先级的新设计。 这意味着、我必须尝试查看是否有办法更好地隔离问题的原因。 如您所述、这很可能是与其他 IRQ 或 DMA 交互的结果。 由于我们在其他发生 IRQ 和 DMA 事务的情况下没有看到这个问题、我想推测它是特定于这个 VIM 测试的东西以及它与正在进行的活动的交互。 进一步推测、它是特定于 DMA 活动的、因为它是架构中的第二个主器件、并且能够修改可寻址存储器。 我将设置另一个测试来输出方向 VIM 中断访问、但启用 DMA MPU 以禁止它写入 VIM RAM 空间。 如果它与 DMA 传输相关、我应该会得到一个异常。 一旦我能够缩小范围、我就可以更加专注于 DMA 及其运行。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Jarkko
    我将其标记为 TI 认为已解决。
    请随时打开另一个帖子-如果此帖子有待处理的问题-系统每天都会锁定旧主题、因此您可能无法在一天或两天内对此帖子作出响应。

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

    Chuck 的帖子"2018年2月22日4:54 PM"使用 vim req masks 掩膜解决了问题(使用"2018年2月23日上午7:23 "后提到的伪代码步骤)、但根本原因仍在帖子"2018年2月23日下午3:01点"中打开。

    如果有问题标记为已解决、我认为应该是发布在"2018年2月22日下午4:54 "之后-我现在就会执行该操作。 但是、这样做的根本原因是最好接收或勘误标记或其他内容、因为现在在自己的代码中只是对这个线程的引用、为什么已经完成了一些操作。