[参考译文] TMS570LS0914：运行期间编程未知故障

尊敬的 JP：

在您的应用程序链接器 cmd 文件中、vectors/FLASH1 ECC 的起始地址不正确、并且内核 ECC 不包括在这里。

将 ECC 部分更改为：

ECC_VEC (R)  ：origin=(0xf0400000 +(start (vectors )>> 3) length=(size (vectors)>> 3) ECC=｛algoL2R5F021、input_range=vectors｝

ECC_KNL (R)  : origin=(0xf0400000 +(start(kernel)>>3) length=(size(kernel)>>3)      ECC={algoL2R5F021, input_range=kernel }

ECC_FLA1 (R)：origin=(0xf0400000 +(START (FLASH1)>>3)   length=(FLASH1)>>3)   ECC={algoL2R5F021, input_range=FLASH1｝

尊敬的 JP：

我不建议使用链接器 CMD 计算应用的 ECC。 可以使用 F021闪存 API 在将应用代码编程到闪存时计算应用 ECC：

尊敬的 QJ Wang：

感谢您的快速响应。

我将尝试更改地址、并在收到更新后返回给您。 我不太确定这些部分的计算方式、您能向我解释一下吗？

关于使用 Fapi API 进行的 ECC 计算、我应该在哪里操作？ 需要哪些步骤？

最后、为了添加更多信息、代码在 main 的上方有下面几行：

    esmREG->SR1[2] = 0x00000008U; 
    esmREG->SSR2 = 0x00000008U;
    esmREG->EKR = 0x0000000A;
    esmREG->EKR = 0x00000005;

这些都是为我的同事添加的、我想澄清他们的目标、并证实他们是否需要达到这些目标。

再次感谢您的帮助与时间。

此致

Unknown 说：

关于使用 Fapi API 计算 ECC 的问题，我该在哪里做？ 哪些步骤是？

请参阅 TI 引导加载程序中使用的示例，

e2e.ti.com/.../7360.bl_5F00_flash.c

Unknown 说：

已为我的同事添加了这些内容，我想澄清他们的目标，并证实他们是否需要加入该目录。

我认为添加这些指令以清除错误状态是为了调试目的。  

尊敬的 QJ Wang：

感谢您的快速响应、并抱歉耽误您的时间。

我将尝试通过 Fapi API 了解更多有关 ECC 实施的信息、如果我有新的疑问、可以联系您。

目前、我已经按照您的指令更改了链接器 cmd 文件。 现在、程序可以在不堆叠的情况下运行更多时间(4小时以上或更少)。 但是、如果我尝试调试代码、则调试器会在故障发生之前断开与微处理器的连接、因此我现在无法确切证实发生了什么、以及故障是否相同(似乎是这样)。 调试器会指示它失去与皮质体的连接、但器件会继续运行、直到它堆栈。

对可能发生的事情有任何想法吗？

可能与堆栈大小相关？

调用 ESM REG 句子循环来持续清除错误状态是否有任何意义？ 也许这就是调试器停止工作的原因。。。 ？

另一方面、我使用一个操作系统函数来重新捕获操作时间。 此函数应每1s 运行一次、但是、我意识到微处理器的计数速度比预期的要快、因此可能是时钟配置错误。 我会检查一下、然后返回查看新闻。

再次感谢您的时间和帮助、非常感谢。  

此致、  

日文

我可能是由 堆栈大小缺陷或 对具有无效 ECC 的位置的推测取指令引起的。  

您的引导加载程序对 所有闪存空间的 ECC 值进行编程。 当引导加载程序将应用程序编程到闪存时、引导加载程序会使用 F021闪存 API 擦除多个闪存扇区、然后将应用程序映像加载到这些擦除的扇区中。 未使用的闪存空间具有无效的 ECC 值。  

您可以使用链接器 cmd 为已擦除的扇区生成 ECC：

FLASH_CODE (RX)：origin=0x00200040 length=0x8000 - 0x40 fill=0xFFFFFFFF /*假设应用程序大小< 0x8000*/
FLASH0 (RX)：origin=0x00028000 length=0x00200000 - 0x28000

尊敬的 QJ Wang：

感谢您的快速回复。

我理解这个问题,这对我来说是有道理的。 但是、我不确定如何将这些修改应用到我的代码中。 我应该修改引导加载程序的 link.cmd、还是应用程序代码？ 另外、我不完全了解原点为什么是0x00200040；在应用程序代码中、矢量从0x00020100开始、而在引导加载程序中、闪存1从0x0002000开始、为什么是这个地址？ 您能否以我的代码为例应用所需的修改？ 抱歉、我是新手、对 link.cmd 和 ECC 的了解真的很差。

此外、我想了解为什么在这段代码上发生了错误、而在其他器件上发生了错误。 我在其他器件中具有完全相同的配置和操作系统、同时具有相同的微处理器和更复杂的功能、我不会遇到这种问题...

与此同时、我将尝试为堆栈保留更多的空间、并证实这是否是失败的原因。

再次感谢。

此致

更新：

我已经更改了操作系统的时钟、现在的时间正确。

此外、我已将堆栈大小增加为操作系统中最占用的任务之一、并将整个应用程序代码的堆栈大小(从1500增加到2500)。 它似乎对操作没有影响。 目前、代码在运行大约1小时后再次停止。 现在我可以再次进行调试、所以我进行了检查、代码已在地址0x14C98 (外部代码)中堆叠两次、而在 dabort.asm 中堆叠两次、随后在相应的0x10地址上堆叠。

它是否添加了更多信息？

我认为最好是如您所说的那样修改未使用的闪存空间。 但是、我感到很奇怪的是、此操作失败仅发生在这款器件上、正如我所解释的、当我在其他器件中具有完全相同的存储器和 FEE 配置而没有任何问题时、如果是未使用的闪存空间、 该情况在另一个微处理器上发生？

此致、

日文

Unknown 说：

我不明白为什么原点是0x00200040

我假设从0x200020开始加载应用程序的位置

Unknown 说：

在应用程序代码中、向量从0x00020100开始、而在引导加载程序中、闪存1从0x0002000开始、那么为什么要使用该地址呢？ 您是否可以使用我的代码作为示例来应用所需的修改？

Unknown 说：

、因此我检查并发现代码已在地址0x14C98 (外部代码)中堆叠了两次[/报价]

您的应用程序位于0x20100、但故障地址位于0x14C98。 该故障是由引导加载程序引起的、对吧？ 0x14C98的内容是否具有正确的 ECC 值？

尊敬的 QJ Wang：  

感谢您提供的信息。  

我更改了.cmd 并在不同的存储器地址中填充了0xFFFFFFFF。 代码如下所示：  

    VECTORS (X)  : origin=0x00020100 length=0x00000020
    //KERNEL  (RX) : origin=0x00020120 length=0x00008000
    KERNEL  (RX) : origin=0x00020120 length=0x00008000 - 0x120 fill=0xFFFFFFFF
    FLASH1  (RX) : origin=0x00028120 length=0x100000-0x20000 -0x8000 -0x20-0x100
    STACKS  (RW) : origin=0x08000000 length=0x00002000
    KRAM    (RW) : origin=0x08002000 length=0x00000800
    RAM     (RW) : origin=(0x08002000+0x800) length=(0x20000 - 0x2000-0x800)

    /*STACKS  (RW) : origin=0x08000000 length=0x00002000
    KRAM    (RW) : origin=0x08002000 length=0x00000800
    RAM     (RW) : origin=(0x08002000+0x800) length=(0x20000 - 0x800-0x800)*/

    //ECC_VEC (R)  : origin=0xf0400000 length=0x4 ECC={algorithm=algoL2R5F021, input_range=VECTORS }
    //ECC_FLA1 (R) : origin=0xf0440000 length=0x40000 ECC={algorithm=algoL2R5F021, input_range=FLASH1 }

    ECC_VEC (R)   : origin=(0xf0400000 + (start(VECTORS) >> 3))  length=(size(VECTORS) >> 3)  ECC={algorithm=algoL2R5F021, input_range=VECTORS}

	ECC_KNL (R)   : origin=(0xf0400000 + (start(KERNEL) >> 3))     length=(size(KERNEL) >> 3)     ECC={algorithm=algoL2R5F021, input_range=KERNEL }

	ECC_FLA1 (R) : origin=(0xf0400000 + (start(FLASH1) >> 3))      length=(size(FLASH1) >> 3)      ECC={algorithm=algoL2R5F021, input_range=FLASH1 }

另外、我添加了以下几行来读取有问题的存储器地址、我可以读取数据、结果是子序列。 共享这个位置的内存浏览器的屏幕截图。 我使用的代码是下一个代码：

            Fapi_FlashReadMarginModeType a = Fapi_NormalRead;
            uint32_t addr = 0x00014C98;
            Fapi_StatusType result = Fapi_doMarginRead((uint32_t*) addr ,(uint32_t*) &buffer_rx, 1, a);

但是、当我用调试器执行新代码时、从 CSS 控制台收到以下错误(操作大约30-45分钟后)、但代码仍在运行：

"IcePick：error：(error -150 @ 0x0)：配置期间使用的 FTDI 驱动器函数之一返回无效状态或错误。 (仿真软件包9.9.0.00040)
DAP：错误：(错误-154 @ 0x0)用于写入数据的 FTDI 驱动程序函数之一返回错误状态或错误。 (仿真软件包9.9.0.00040)
IcePick：20次尝试后无法确定目标状态
IcePick：在断开连接之前从目标中删除调试状态失败。 程序存储器中仍可能嵌入了断点操作码。 建议您在连接前复位仿真器并在继续调试前重新加载程序
CortexR4：JTAG 通信错误：(ERROR -2063 @ 0x0)无法复位器件。 对电路板执行下电上电。 如果错误仍然存在、请确认配置和/或尝试更可靠的 JTAG 设置(例如较低 TCLK)。 (仿真软件包9.9.0.00040)
CortexR4：在断开连接前从目标移除调试状态失败。 程序存储器中仍可能嵌入了断点操作码。 建议您在连接前复位仿真器并在继续调试前重新载入程序"

看来微处理器失去了与调试器的连接。 这种故障经常发生。 您是否有任何想法、可能会发生什么情况？ 硬件相关的东西？

我已经执行了代码并进行了新的修改；这次、它在操作3h 后挂起)。 当我在挂起后复位器件并再次将其打开(不删除或修改存储器)时、器件会直接在引导加载程序上启动、但它本身不会跳转到应用程序(它应该直接转到应用程序代码)。 因此、我认为应用程序代码和引导加载程序之间的关系可能是不正确的、原因是似乎发生了跳转到引导加载程序的数据中止故障、并且程序在那里挂起、无法继续运行应用程序或重新启动它。

在第一个帖子中、我共享了引导加载程序以及应用程序.cmd 和 sys_startup 文件的几个文档。 我想知道我是否应该添加或修改其中的信息、以便在两个代码之间建立正确的链接(我认为没有必要、因为这些配置始终对我有效)。 例如、ECC 和自检的配置在引导加载程序启动期间更为详尽、但在应用程序代码中更简单。 在一个帖子中,我读了以下内容:

"启用 ESRAM ECC 检查"会将 checkRAMECC ()；添加到 sys_startup.c 文件中。 函数的详细信息如下所示。 因此将会产生有意的数据中止、这需要 dabort.asm 中的_dabort 函数。 在您的情况下、由于引导加载程序的 intvecs 被加载到地址0、该地址0在数据中止时没有分支到_dabort 例程、因为它是应用程序代码的一部分。 可以从应用中删除"Enable ESRAM ECC Check"、或者找到一种在数据中止期间分支到_dabort 的方法。"

我与大家分享这个帖子的链接、因为他们在其中讨论了 ECC、DATA_ABORT 和 ESM、这些内容在这个代码中不太受我控制、因此我认为会很有用。 不过。 我尝试了他们提出的许多事情,无法解决这个问题。

另外、您能否向我解释一下、我如何检测它是否是堆栈溢出问题？ 当我修改堆栈大小时、与正常大小(0x1500)相比、程序有时会在稍后或更早地挂起、因此可能与问题有关。 不过、我可以检查每个函数的堆栈使用情况、但我不知道如何查看执行时间中的实际使用情况、或者检测失败是否正是由于此原因。

最后、我最终怀疑、如果是硬件故障(内存位置不正确)、它能解释所有这些不同的错误吗？ 我怀疑的原因是、如果我更改了我使用的虚拟扇区以及块的大小(对于 EEPROM 闪存仿真)、程序能够运行的时间、 所以,我认为可能有一些腐败的任何位置的内存和它不会失败,直到达到该点... 此时此刻我不知道还有什么更好的... (过去、我们必须从此器件更改一个微处理器、因为 SPI 相关引脚已损坏)。

很抱歉这么长的消息、但我认为最好尽可能多地与您分享信息。 感谢您的耐心和帮助。

此致、

更新了：我已经完成了一个新的操作周期、这次是2小时、调试器没有断开连接。 这样我就可以停止程序并对问题进行更多的调试了。 我将确切地发布该程序正在做什么、看看它是否告诉您更多信息：

首先、当我在程序挂起时停止调试器时、它会跳转到 sys_intvecs.asm 至_dabort 行。 之后是 dabort.asm。

其次、代码导航到_dabort 中的所有指令、然后导航到 noRAMerror 中(在此指令期间、代码将跳转到 custom_dabort 处理程序)。

下一步是以下屏幕：

调试器似乎找不到库。 我理解这可能是因为库通过引导加载程序从存储器上充电、或类似的东西-请参阅引导加载程序的 sys_link.cmd 以了解更多详细信息)。 昨天、当我在没有引导加载程序的情况下从地址0x0执行代码应用时(以从引导加载程序中丢弃错误)、我遇到了同样的故障。 然后、我看到了此错误、并认为导致此错误的原因是不存在引导加载程序、而且无法为文件充电... 但是、现在使用引导加载程序配置并尝试相同的错误...

然后、代码跳转至0x10地址(由于 dabort)、如果我继续执行、则重复整个过程。

我希望这能为您提供一些更有用的信息。

最终更新：我已经看到了编译和调试器的配置、我将发布一些照片、以便您可以查看是否正确。

堆和堆栈大小：我应该在这里将其增加吗？ 还是仅在.cmd 文件中？

ARM 连接器文件搜索选项：我已经包含 F021 API 库。 但是、如果我转到计算机中的路径、在源文件夹上没有任何.c 文件、我认为它们在库中。

在链接器输出(Arm 链接器)中、我写下了2个句子(在本例中、我不知道其中的原因、所以我想证实这不是问题所在...)

最后、在 Debug/Source 查找路径中、我没有任何路径、我是否应该在这里添加 F021库？ 以避免最后一个问题。 请注意、在我的所有计算机上、我没有 Blanck_Check.c 文件

再次感谢您投入宝贵的时间给予大力支持。

此致。

Javier、您好！

栈内存通常用于以下结构：

1.进行用于保存寄存器内容的函数调用(例如用于返回地址的链接寄存器(LR)))

2.当 CPU 寄存器不可用时，局部函数变量存储在堆栈中。

3、对于中断服务(ISR)的执行、寄存器被存储在堆栈中。

您应该对堆栈使用情况进行分析以确定应该为您的应用设置多大的堆栈。

为  "Stack Usage"视图  Code Composer Studio (CCS 6.2及更高版本中提供)中提供应用堆栈使用情况的静态视图。 此信息由工程编译生成、显示为函数调用树、并以水平条形图形式显示每个函数的栈使用情况。  

尊敬的 QJ Wang：

感谢您的信息。 我已经使用过该屏幕(堆栈使用内存)。 在上面、我可以看到有一个函数使用100%的包容性堆栈(2444个单元)。 原因是操作系统经常调用此函数、并且在其他函数内部使用"sprintf"、这需要很多堆栈。 但我认为问题不在这里。 在其他设备上、我有相同的用途、但这不是问题。

要计算估计的堆栈大小、我应该为每个函数添加包含的或不包含的大小吗？

您能否就我在该帖子上遇到的其他问题提供更多信息？ 它真的很有用、我确实堆叠在这个问题上、需要一些帮助。

最后、您认为这可能是硬件问题吗？ 微处理器存储器是否已损坏或类似问题？

感谢你的帮助。

映射文件(在调试文件夹中)中的堆栈大小是您在链接器 cmd 文件中定义的：起始地址和长度。 它定义了堆栈的位置。  sys_core.asm 中的_coreInitStackPointer_()为每种模式定义了堆栈大小、CCS 链接器选项中的--stack_size 应与 _coreInitStackPointer_()函数中定义的总大小相匹配。

当堆栈溢出时、将出现意外错误。

如果使用链接器 cmd 脚本生成 ECC、则工程属性中的 ECC 选项应设置为"on"

BlankCheck 是 F021闪存库中定义的 API。

如果使用了 FEE、则 TI_FeeInternal_BlankCheck (..) 执行空白检查。

我提到过、我不建议在应用固件中使用链接器 CMD 生成 ECC。 您可以使用链接器 CMD 为引导加载程序和整个闪存生成 ECC。  

在我的引导加载程序示例中、应用程序固件必须为二进制格式、并通过引导加载程序编程为具有 ECC 的闪存。 如果使用链接器 cmd 为应用程序生成 ECC、则二进制文件的大小非常大(>3GB)。

尊敬的 QJ：

感谢您提供的所有信息、并抱歉这么晚才回复。 我一直在努力解决这一问题,试图更深入地了解正在发生的事情。

我创建了一个新项目并删除了与 FEE 驱动器相关的所有功能,这个项目运行的很好。 除了有关 dabort 寄存器的信息外、这还表示问题 与此驱动程序直接相关。 我将为您提供有关该问题的更多信息、看看您能否最终得到原因或解释。

该器件能够正常工作、并通过 FEE 驱动程序保存闪存组7上的信息。 但是、在运行中的某个点、数据中止和程序残桩。 此时、WD 能够重新启动微处理器并  再次运行程序。 首次发生这种情况时、器件 有时可以从闪存恢复信息、但有时 不能。 目前、我观察到其他可能对发现错误很感兴趣的行为。  当程序挂起并重新启动几次时、它开始正常工作(甚至正确加载闪存的数据)、但是、当它达到第一条写入费用数据的指令时、它会再次挂起。 因此、程序能够读取闪存、但无法写入。

我想强调几个要点：

• 我  使用很多采用此 FEE 配置的器件、从未见过此行为(数据中止+擦除闪存)。  我已在手册中检查并确认我将遵循正确更新数据所需的所有步骤->调用"主费用"函数的循环、为执行此过程的 FreeRTOS 功能提供特权模式、配置至少2个虚拟扇区等。 我认为这不是配置或 ECC 问题。
• 由于 HalCoGen 对此微处理器的 OS 没有版本、我在外部添加了 FreeRTOS。
• 我使用的是非常快的串行通信(1Mb/s)。 我认为它可能会对问题产生一些影响、因为我不断与器件通信、以发送指令、因此它可能会影响闪存的写入过程。 但是、我将微处理器的频率提高到150 MHz (从100MHz 开始)、以避免任何时序问题。

最后、经过几个月的调试、我开始认为这可能是硬件问题。 我已经阅读了您的帖子(TMS570LS3137：TI FEE -在 TI_FeeInternal_PollFlashStatus ()-基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛中进入)并阅读了微处理器的数据表、我知道器件供电不良会导致 FEE 驱动程序出现一些问题。 我希望更好地了解这可能是什么问题、以及我如何识别它。 我一直在测量功耗和电压、我没有看到低于3V 的电压、但可能在启动或断电序列以及压摆率方面发生了一些事情。 您能否告诉我、哪种供电故障可能导致这种问题？ 我已更改微处理器以确认它没有损坏、但行为是相同的。

最后、我一直在阅读关于 FEE 驱动器上存在的不同错误函数的内容。 我想实施其中的一些建议、以便更好地了解问题。 也许您可以帮助我解决这个问题。 在本例中、您会使用哪个函数？ 将它们写入负责主要费用函数的任务中是正确的吗？ 我如何处理结果才能真正理解问题？ 请注意、该问题很难调试、因为并不总是同时发生、 如果需要很多小时、调试器可能会失去连接、因此我更倾向于通过串行通信实施某种方法来发送错误代码、从而保证我可以识别错误代码。 我想我可以确定这个问题、并使用数据中止处理程序来显示它。

我真的需要解决这个问题。 正如我所说的那样、我一直在与 FEE 驱动器一起工作、而我从未见过这样的情况。

再次感谢您投入宝贵的时间与精力。

此致

尊敬的 QJ：

我仍在研究这个问题。 我有一些更新、如果有您的一些反馈、我将感到非常高兴。

我们几乎没有针对该问题对器件的电路板进行测试。 我们已断开所有外设的连接、以避免出现任何外部供电问题。 接下来是：

我们已在使用相同微处理器和类似架构的另一个器件中测试了相同的代码、并且 FEE 驱动器运行良好(没有卡滞或数据丢失)。

出现此问题的原始电路板在微处理器周围具有相同的配置(相同的电容器和电阻器网络、相同的供电元件等)。 但是、我们遇到了以下问题：我们为电路板加电、它开始与 FEE 驱动器一起工作。 如果我们在运行开始时关闭和关闭此器件、FEE 驱动器能够找到"参考数据"(一个保存在块第一个位置上的已知数字)。 但是、如果我们等待几分钟、驱动程序将无法恢复参考数据、但设备仍能正常运行。 在任何情况下、驱动器都能够在下电上电后恢复丢失的参考数据。

因此、从我们的角度来看、这似乎是一个硬件问题、因为这一问题没有在另一个类似的微处理器中重现。 我们将测量加电和断电序列、并对其进行比较、以查看馈入微处理器的电流电压是否存在任何问题。 我们需要知道并了解哪种不良电源问题可能会影响 FEE 驱动器。 我们尚未在驱动器文档中找到任何信息、但在我在上一条评论中提到的帖子中、您表示低于3V 的电压可能会影响驱动器的工作。 请解释可能影响费用驱动因素的所有原因。 该信息未被删除、但微处理器找不到它。

再次感谢您的观看。

注单注意事项

Unknown 说：

此信息未被删除，但微处理器找不到它。

数据块的块状态是否正确： 0xFFFF00000000？  如果状态为无效(0xFFFF00000000)、FEE 驱动器将不能读取块数据。  如果器件在对状态进行编程时复位、则置位复位时被编程的位是不确定的、因此状态变为无效。

Unknown 说：

我们为主板通电，并开始使用 FEE 驱动程序。 如果我们在运行开始时关闭和关闭此器件、FEE 驱动器能够找到"参考数据"(一个保存在块第一个位置上的已知数字)。 但是、如果我们等待几分钟、驱动程序将无法恢复参考数据、但设备仍能正常运行。 在任何情况下，驱动程序都能够恢复 th

这很奇怪。 电路板是否遵循上电顺序？ 最小 nPORRST 保持时间为1ms。

IO 电源和闪存泵电源的最小值为3V：

尊敬的 QJ：

感谢您的快速响应。

我们一直在检查上电和断电序列中涉及的所有信号。 我们更改了一个电容器、以确保 PORRST 信号缓慢升高、能够满足所有时序要求。 但是、微处理器在几个周期的工作后仍然无法恢复数据。

让我再给大家一些信息：我们一直在测试、发现如果我们改变频率以节省存储器信息、就会花费更多的时间来失去基准。 让我给出一些具体的时间:如果我们每15秒在内存上保存信息,大约需要5分钟丢失的数据参考(大约20个写入指令)。 但是、如果我们选择5秒来调用 FEE WriteSync 函数、则可能需要大约1：30或2分钟才能失去参考(同样接近20条写入指令)。 请注意、我们在此时间之后执行上电/断电、以确认参考数据是否丢失。 我们每10ms 通过 FRETOS 调用 TEE_MAIN 函数。 如果我们选择其他虚拟块、则该周期数会有所变化。 我们当前正在使用虚拟扇区0和1、如果尝试5和6、并且写入15s 的时间大约需要7分钟丢失参考。

此代码可在使用相同微处理器的其它电路板上正常工作。 因此、我们真的不知道它会导致这个问题的原因是什么。 是否有防御力？

微处理器闪存是否损坏？ 或有任何故障？ 在这种情况下、什么原因会导致此类故障？ exactñy 年、我们更换了微处理器、新微处理器的工作原理是这样的。因此、如果我们再次进行更改、我们希望能够证实故障的可能原因、不会再次发生。

对于我们所读取的内容、不建议过多次地写入闪存、而在写入之间等待足够的时间是非常重要的。 您是否有关于此主题的任何信息？ 有没有规定可以写入闪存的时间限制？ 请致电、了解这方面的信息将非常有用。

此致。