[参考译文] TMS570LC4357：ESM 高电平中断在上电后触发两次

尊敬的 Dai：

我认为额外的添加数据可能会导致这个问题、因为 如果我们启用以下选项、CCS 将自动为应用生成 ECC。

但是、如何将附加数据添加到 CCS 生成的 Hex 文件中？ 是否将 ECC 添加到 ECC 部分的相应数据中？

如果我们没有向相应的数据添加 ECC、那么这可能会导致问题、因为该器件的 ECC 检查将始终处于启用状态。 所以、它将进行推测取数据并验证闪存内容的完整性、如果有任何 ECC 错误、那么器件将生成 ESM 错误。

我的建议是、首先删除您要添加的附加数据并验证 ESM 错误、如果在删除此数据后未出现错误、则应仅针对这些数据。 然后、我们将验证对该额外数据进行编程的过程。

——
谢谢、此致、
Jagadish。

你好、 jagadish、

感谢您的答复

使用 Uniflash 或带有 F021库的 MCU 进行编程。 如下图所示、我应该已经启用了 ECC 相关设置。

2. 我们使用自己的工具来解析 CCS 生成的 hex 文件、并在相应的位置添加所需的数据。 我想知道是否也可以在编程过程中添加 ECC？

3.我尝试不添加额外的数据并vfill在 cmd 文件中添加、但我发现vfill似乎没有填补闪存中的空白、问题仍然存在。 下面是我们的 cmd 文件和实际生成的十六进制文件中的段分配。

十六进制

命令

从地址0x10 0000 (含矢量表)开始、区域大小为0x100。 内核数据从0x10 0100开始、但实际生成的文件似乎在矢量表和内核数据之间存在间隙。

4.最后一个问题、如果以这种方式填充闪存、编程文件将会非常大、从而导致软件编程时间更长。

尊敬的 Dai：

Unknown 说：

1.我们使用 Uniflash 或带有 F021库的 MCU 进行编程。 如下图所示、我应该已启用 ECC 相关设置。[/QUOT]

这对我来说很好。

Unknown 说：

2.  我们使用自己的工具解析 CCS 生成的 hex 文件并在相应位置添加所需的数据。 我想知道是否也可以在编程过程中添加 ECC？[/QUOT]

如果您是像您在第1步过程中提到的那样进行编程、那么在解析级别、我想您无需添加 ECC。

Unknown 说：

3.我尝试不添加额外的数据并添加vfill到 cmd 文件中、但我发现vfill似乎没有填补闪存中的空白、问题仍然存在。 下面是我们的 cmd 文件和实际生成的十六进制文件中的段分配。[/QUOT]

是否可以与该问题共享一个最简单的项目、以便我可以进行调试并在结束时查看生动的问题？

Unknown 说：

4.最后一个问题、如果我们以这种方式填充闪存、编程文件将非常大、可能导致软件编程时间更长。

[/quote]

[/quote][/quote]

您是正确的、代码大小会增加、软件编程需要时间。

——
谢谢、此致、
Jagadish。

[/quote][/quote][/quote]

你好、 jagadish、

今天,我继续测试这个问题,并取得了一些新的发现:

1. 使用 vfill 进行调试时、一旦执行 coreEnableEventBusExport、ESM SR2就会立即更改为8。 如果它被更改为填充、十六进制被填充、ESM 高电平中断将只在程序访问十六进制范围之外的地址时被触发。
2. 我们的程序分为两个部分：一个存储在0x0 (引导)、另一个存储在0x100000 (应用)。 两者都通过 CCS 单独编译。 地址0处的程序会检查地址0x100000的状态、以确定是否启动另一个程序。 但是、根据上述测试结果、当闪存中仅存在引导时、从引导程序访问应用程序地址会触发 中断。 如何避免这种情况？
3. 此外、在仿真调试过程中、我会发现在故障触发后、我会esminit从 HAL 库调用以初始化故障、有时故障会在设置后清除、但有时它不起作用。 这是为什么

我还有一个问题。 现在、我可以看到esmREG->IOFFHR = 36和esmREG->SR1[1] = 8。 是否有进一步调查此问题的方法？ 是否有更多关于 Cortex-R5F 内核-所有致命总线错误事件的详细信息？"

尊敬的 Dai：

是否可以针对该问题设置一个实时调试会话、这将有助于更清楚地了解问题、并根据该会话提供我的建议。

我将在上午10点至晚上8点 IST (印度标准时间)开放、因此根据您的空闲时间安排、提前一天举行会议。

——
谢谢、此致、
Jagadish。

你好、 jagadish、

我不知道如何处理这个实时调试会话。 是否有相应的指南或文档？

遇到的问题是、当程序访问编程范围之外的地址时、会触发 ESM 故障(Cortex-R5F 内核–所有致命总线错误事件)。 例如、如果编程的范围是从0x0000 0000到0x0010 0000、并且在将该十六进制文件编程到芯片后、读取闪存地址0x0020 0000会触发中断。 此时、如果我使用新数据对地址0x0020 0000进行编程、访问该地址将不再导致故障。 我想知道是否有可能确保访问闪存地址不会触发 ESM 中断、即使在程序没有被重新编程时也是如此

由于我们已将闪存地址分频以存储多个程序、例如引导加载程序和多个应用程序、因此引导加载程序将在跳转到应用程序之前验证应用程序的相应闪存地址是否包含有效的应用程序。 如果没有程序已烧录到 APP 区域、此操作将触发 ESM 中断

尊敬的 Dai：

对延迟响应深表歉意。

Unknown 说：

如果没有程序烧录到应用程序区域、此操作将触发 ESM 中断

您是对的、这个操作可导致 ESM 中断。

为避免这种情况、我们应使用有效的 ECC 对整个闪存进行编程。 我的意思是、对于数据0xFFFFFFFF 位置也应包含有效 ECC。 如果发生这种情况、在 APP 区域外部进行访问可能不会产生 ECC 错误。 为此、我们必须  在链接器 cmd 文件中使用 fill 或 vfill 通过0xFFFFFFFF 填充未使用的闪存。

——
谢谢、此致、
Jagadish。