[参考译文] TMS570LC4357：开发板上存在 EMS 2.3 总线错误、但定制板上不存在

您好、Paul：

我以前从未遇到过这个问题！

我们有一个内部 AI 工具可以分析所有旧问题以及此器件的所有文档、当我向此工具提供您的问题时、我收到了一些建议或建议。 请检查一次。

根本原因 — 可能存在调试器闪存编程差异

事实上、您在使用板载 XDS110 调试器的 LaunchPad 上看到此错误、但在使用 J-Link 的定制电路板上未看到此错误、这强烈建议 a 闪存编程/ECC 生成差异 调试器的区别。

要解决的关键问题：

1、ECC 生成方法冲突 您提到了使用相同的结果来尝试由调试器生成的 ECC 和链接器生成的 ECC。 但是、还有一个关键点： 不能同时使用这两种方法 。 使用链接器 ECC 生成功能（使用链接器命令文件和选项中的 ECC 指令）时--ecc=on、必须在闪存编程工具/调试器设置中禁用 AutoEccGeneration 选项。

2.收费模块初始化问题 删除收费模块初始化使其“暂时有效“这一事实是一个强有力的线索。 FEE（闪存 EEPROM 仿真）模块需要对其使用的闪存扇区进行正确的 ECC 初始化。 如果编程期间未正确生成针对收费区域的 ECC、则当代码尝试访问这些区域时、您将收到 ESM 2.3 错误。

3、STC（自检控制器）问题 _SL_Kickoff_STC_execution第一次运行时卡住表明自检检测到问题、该问题可能与未正确初始化的闪存/ECC 有关。

推荐解决方案：

解决方案 1：使用调试器 ECC 生成功能（建议用于开发）

1. 删除所有链接器 ECC 指令 直接访问该链接器

2. 删除--ecc=on链接器选项

3. 在 CCS 闪存设置中启用 AutoEccGeneration：

   • 右键点击您的工程→Properties→Debug→Program/Memory Load Options
   • 确保选中“Enable Flash Programming“
   • 查找 ECC 相关选项并启用 ECC 自动生成

4. 擦除整个闪存 然后重新编程以确保不会保留过时的 ECC 数据

解决方案 2：使用链接器 ECC 生成功能

如果更喜欢生成链接器 ECC：

1. 将适当的 ECC 指令添加到链接器命令文件中 （确保包含费用地区）
2. 添加--ecc=on到链接器选项中
3. 在 CCS 闪存设置中禁用 AutoEccGeneration
4. 确保正确定义您的费用模块记忆区域 以及相应的 ECC 范围

解决方案 3：特定于调试器的权变措施

因为 J-Link 可以正常工作、但 XDS110 无法正常工作：

1. 检查是否存在 XDS110 固件更新 器件
2. 请尝试使用 UniFlash 而不是 CCS 的内置 LaunchPad 闪存编程器
3. 比较 J-Link 配置和 XDS110 配置之间的闪存编程设置

附加检查：

1. 验证闪存等待状态 都是根据您的时钟频率正确配置的
2. 检查高速缓存是否已真正禁用 -验证 SCTLR 寄存器设置
3. 确保正确的闪存组初始化 在进入收费模块之前
4. 检查您的收费模块配置 -验证闪存地址范围是否与您的代码/数据段相冲突

调试步骤：

1. 读取 ESM 状态寄存器 确认是 ESM 组 2、通道 3（闪存 ECC 错误）
2. 检查闪存 ECC 状态寄存器 （FDACSTATUS、FUNCERRADD 等）来查看导致错误的地址
3. 比较.out 文件 使用 XDS110 与 J-Link 进行编程时生成 — 检查是否存在 ECC 段

--
此致、
Jagadish。

尊敬的  Jagadish：

是的、这些线程大致总结了这些线程的含义。

我通过以下方式修复了 Flash7 EEC 区域：

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


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

/* Bank 7 ECC */
    ECC_FLA7 (R) : origin=(0xf0100000
                   length=(size(FLASH7)  >> 3)
                   ECC={algorithm=algoL2R5F021, input_range=FLASH7 }

我有一个+ (start (FLASH7 )>> 3)、应该不会出现这个。

我正在进一步探究、我似乎在这里遇到了一些奇怪的例外情况、一个一致的例外情况是 PCR 寄存器。

由例外 LR 和 DFAR 确认,似乎:

pcrREG2->PSPWRDWNCLR2 = 0xFFFFFFFFFFFFU；

在 periphInit() 中导致数据中止。

非常奇怪。

编辑：实际上我甚至无法在调试器寄存器列表窗口中读取 PCR 2。 PCR1 和 3 是可读的。 2 不是！

您好、Paul：

我有一个 launchpad 板、

是否可以在我这边共享您的完整工程以进行调试？

--
此致、
Jagadish。

尊敬的  Jagadish：

我已将代码配对到最低 (ish)、似乎与费用相关。

在删除代码时、我发现它是对 TI_Function Fee_Main () 的调用

是否有更私人的共享项目的方式？

您好、Paul：

我向您发送了朋友的请求、请接受、一旦您 接受、我们就可以在论坛上进行私人聊天。

--

此致、
Jagadish。

已接受并发送消息、谢谢！

我似乎在向侧面移动。

因此我删除了：

-- fill_value=0xFFFFFFFF

从 .cmd 文件 — 我认为 ECC 工作需要这个值、但我现在看到它只是设置了未经草签的默认值、它干扰了收费模块、该模块预期内存将变为零。

我在 HalCoGen 示例中发现了另一个启动文件、我已经移植了它。 在中、有一组定义用于启用测试：

#define STC_ENABLE                0
#define PBIST_ROM_ENABLE          0
#define PBIST_L2RAM_ENABLE        0
#define PBIST_PERIPHRAM_ENABLE    0
#define PBIST_VIM_ENABLE          0
#define L2RAMECCCHECK_ENABLE      0
#define FLASHECCCHECK_ENABLE      0
#define PERIPHRAMECCCHECK_ENABLE  0
#define EFUSETEST_ENABLE          0
#define CCMR5TEST_ENABLE          0

我发现如果它们中有任何一个被启用、中断根本不起作用。 它到达 main()、并且 i&F 位在 CPSR 中为 0。 但我的 RTI 计时器不会触发。  

您好、Paul：

您能否请参考我在以下主题中的最后一条评论：

(+) TMS570LC4357：闪存 ECC 问题 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛

在这种情况下、这非常有用、似乎是您面临的同一个问题。

--
此致、
Jagadish。

是的、我准备好了所有内容、以及每个闪存部分的 palign (32) 和 fill=0xffffff。

遗憾的是、它似乎不起作用、需要在调试器中启用自动 ECC。 我使用 cmd 文件中的组生成 CRC。 可能会干扰？

当事情的时刻,我必须禁用 2 PERIPHRAM 和 STC 和自动 ECC calc 需要打开,以使事情正常工作。

又向前迈进了一步：

通过从 RAM 中删除 ti_fe*代码来使链接器 ECC 生成功能正常：

    flashAPI: palign(32), fill=0xffffffff
    {
    	*Fapi_UserDefinedFunctions.obj (.text)
     	// *bl_flash.obj (.text)
     	// *ti_fee_* (.text)
     	--library= "*/F021_API_CortexR4_BE_L2FMC_V3D16.lib" (.text)
	} LOAD = BOOT, RUN = RAM, table(flashCpyTbl)

只剩下库

我注意到该示例中有 BL_FLASH 从 RAM 运行、但它是否需要？

但 STC 仍然不起作用。 数据输入异常清除 CAN 错误  

您好、Paul：

我注意到该示例中的 BL_FLASH 从 RAM 运行、但它是否需要？

是的、它确实需要。

下面的主题中解释了原因：
(+) TMS570LC4357：在同一存储体上执行代码和擦除时出现的问题 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛

(+) TMS570LS0432：是否可以在 BANK0 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛中刷写数据

STC 仍然不起作用。 数据输入异常清除 CAN 错误 

STC 对 ECC 敏感。

在 STC 之前、应使用适当的 ECC 初始化所有闪存段。

--
此致、
Jagadish。

我想我现在已修复了闪存 EEC。

因此、从之前开始：

我正在进一步探究、我似乎在这里遇到了一些奇怪的例外情况、一个一致的例外情况是 PCR 寄存器。

由例外 LR 和 DFAR 确认,似乎:

pcrREG2->PSPWRDWNCLR2 = 0xFFFFFFFFFFFFU；

在 periphInit() 中导致数据中止。

这描述了我所看到的症状：

 TMS570LC4357：软件复位后数据中止异常 

但这个问题对我不起作用。 我仍然可以在 CAN、PCR 或从 OTP 读取 ADC 校准中看到这种情况发生、或者它起作用！

虽然这可能意味着我可以删除我在_c_int00 () 的开头放入的缓存和 MPU 禁用调用

老实说、随着各种症状的出现、我认为存在多个问题。 有时、调试编译会起作用、但版本不会起作用。 有时它'需要重新启动几个调试器才能进入 main ()

确保从复位中禁用缓存和 MPU 有助于（必须在软件重新启动时保持原位？）

我现在看到的问题之一是不触发中断。 模式为系统 (0b11111)、已清除的 IRQ 和 FIQ 位。 RTI 正在运行、但没有中断。 如果我启用任何 STC_ENABLE、 PBIL_PERIPHRAM_ENABLE 或 PERIPHRAMECCCHECK_ENABLE、则会发生这种情况 。 其余的可以打开,它会工作（大部分）。

只是为了澄清（您可以从我发送的代码中看到）。INIT 完成后、一个主 while 循环使用 IDLE 命令启动。 RTI 应每毫秒触发一次并唤醒处理器。 在这种情况下、处理器永远不会唤醒。

在 IRQ 和 FIQ 矢量中放置了断点。 Fiq 被命中 3-4 次,以服务测试, IRQ 不命中在所有。

为了进一步混淆 、在禁用 STC_ENABLE、 PBIL_PERIPHRAM_ENABLE 或 PERIPHRAMECCCHECK_ENABLE 时、只会运行调试构建、而不会运行版本。

我想这意味着 MPU、存储器布局、高速缓存以及任何其他设置都是正确的。 提示计时问题或其他问题？

尝试运行发行版的示例。 （这仍在使用 HalCoGen 示例 SL 启动文件）

调试->

卡在 PBIT_VIM_ENABLE PBIST 失败

重新启动->

预取中止、LR：0x08080004、DFAR： 0xFFFF1204 (Pcr2_MstIdEna)、IFAR： 0x08080000

重新启动->

转到 main ()

启动->  

一直在等待费用闲置

重新启动->

卡在空闲状态（无中断）

您好、Paul：

启用自检时不触发中断

你的观察结果 STC_ENABLE、PBIT_PERIPHRAM_ENABLE 或 PERIPHRAMECCCHECK_ENABLE 防止中断正常工作至关重要。 这表明：

根本原因： 自检控制器 (STC) 和 PBIST 测试可能会影响 VIM（矢量中断模块）状态。 根据文档、STC 在两个 CPU 内核上提供诊断覆盖 和 VIM 本身 。 当这些测试运行时、它们可能会使 VIM 处于意外状态。

建议：

1. 自检完成后对 Re 进行初始化 ：运行 STC/PBIST 测试后、必须重新初始化 VIM 中断矢量表并确保其配置正确
2. 检查 VIM ECC ：VIM 有自己的 ECC 检查、必须正确初始化。 确保中断向量表具有有效数据和相应的 ECC 校验位
3. 清除错误标志 ：自检后、清除 UERR 和 SBERR 标志寄存器和错误地址寄存器

//自检完成后：
// 1。 Re 初始化 VIM 中断向量表
// 2. 启用 VIM ECC（写入 0xA 以启用）
// 3. 清除任何挂起的中断标志
// 4. CPSR 中启用 Re 的 FIQ/IRQ

调试与版本构建差异

调试编译可以正常工作但版本编译失败这一事实强烈建议与编译器优化相关的时序相关的初始化问题

根本原因：

1. 优化消除延迟 :采用更高优化的 Release 内部版本可能会删除隐式延迟,从而屏蔽初始化时序问题
2. 变量缓存 :优化的代码可以缓存外设寄存器值,而不是重新读取它们

--
此致、
Jagadish。

因此：

e2e.ti.com/.../6184201

我已经解决了这里的大多数问题。

一些值（例如几个 cpy_tbl 地址）存储在_memInit_() 中使用的寄存器中、这些值当然被调用破坏了。

我很惊讶以前没有人注意到这一点！ 这不会导致其他问题 

HalCoGen Example_safetyLib.c 需要进行其他更改

您好、Paul：

解决了我在这里遇到的大多数问题。

很高兴听到保罗！

一些值（例如几个 cpy_tbl 地址）存储在_memInit_() 中使用的寄存器中、这些值当然被调用破坏了。

我很惊讶以前没有人注意到这一点！ 这并不会导致其他问题  

HalCoGen Example_safetyLib.c 需要进行其他更改

你的神学似乎是正确的。 但我需要在实际中进行测试。 不管怎样、现在您已被释放、很高兴听到这个消息。 我稍后会花一些时间在这方面,并从最后验证它

--
此致、

Jagadish。