[参考译文] TMS570LS3137：MCU 编程与放大器时 UniFlash v8.8.0行为、CRC

其他测试结果已经证明,使用 UniFlash 实用程序,闪存 ROM 读和导出函数十六进 制格式(1 MB )从上面的任何步骤(包括步骤9)给出相同的二进制. 十六进制输出文件、但第8步(用0x00填充)除外、但第9步的 CRC 是不同的。

我开始怀疑 TMS570 CRC 引擎配置(内存对齐等)。 以下是我针对 DMA 和 CRC 引擎的配置。

DMA CH15配置：

    // ------------------------------------------------------------------------
    // configure DMA CH15 for CRC compression of the Flash ROM (1 MB)
    // ------------------------------------------------------------------------

    DMACP15ISADDR   = (u32)((u32 *) 0x00000000);    // set to start of Flash ROM (initial source)
    DMACP15IDADDR   = (u32) &PSA_SIGREGL1;          // set to channel 1 PSA signature low (fix destination)

    DMACP15ITCOUNT_bit.IETCOUNT = 32;       // element transfer=32
    DMACP15ITCOUNT_bit.IFTCOUNT = 4096;     // frame transfer=4096

    DMACP15CHCTRL   = 0x0000F108;           // RD/WR size: 64 bits, transfer type is one block
                                            // RD mode: post-increment, WR mode: constant
                                            // auto-initiation disabled

    DMACP15EIOFF    = 0x00000000;           // element index address offset: source=destination=0
    DMACP15FIOFF    = 0x00000000;           // frame index address offset: source=destination=0

CRC 引擎配置：

    CRC_CTRL0_bit.CH1_PSA_SWREST = 1;       // reset channel 1 PSA signature register
    CRC_INTS_bit.CH1_CCITENS     = 1;       // semi-CPU mode: enable CH1 CC interrupt

    // CRC Pattern Count × CRC Sector Count = DMA Element Count × DMA Frame Count
    // must match DMA CH15 configuration for other details

    CRC_PCOUNT_REG1_bit.CRC_PAT_COUNT = 131072; // pattern count: 4096*32=131072, 64-bit words
    CRC_SCOUNT_REG1_bit.CRC_SEC_COUNT = 1;      // sector count: 1 (4096*32*8=1 MB)

    CRC_CTRL2_bit.CH1_MODE = 0x0;           // set channel 1 to data capture mode (required step after ISR)
    CRC_CTRL2_bit.CH1_MODE = 0x2;           // set channel 1 to semi-CPU mode

    CRC_STATUS = 0x0000FFFF;                // clear all interrupts

    CRC_CTRL0_bit.CH1_PSA_SWREST = 0;       // release PSA signature register to operational state

CRC 引擎专家可以为您提供帮助吗？

我们将继续调查、这就是我们发现的结果。

如果我们使用 IAR EWARM 进行编译、发布模式、已使用未使用的字节将1MB 闪存 ROM 从0x0分配到0xFFFFF  是什么  0x00 . 此操作同时输出了两个。 OUT 和。 十六进制文件。

现在有了这些文件、使用 IAR EWARM 或 UniFlash 刷写 MCU ROM 时始终会显示相同的 CRC 代码 0xF611 XXXXXXXXXXXX、与上述步骤9一致、不再存在差异！

这是我在 TRM SPNU499C 第14.2.3段中找到的：" CRC 控制器支持对 PSA 签名寄存器进行双字、字、半字和字节访问。  在非双字写入访问期间、所有未写入字节通道在压缩前都用零填充。 "。

如果以某种方式、如上所述、CRC 引擎使用了"0"填充功能、这导致了差异、为什么即使与 DMA 指令一起使用该功能、以始终将8字节双字从0x0传输到0xFFFFF (1MB、包括未使用的存储器字节)？

谢谢。

黄志华

我对延迟响应表示诚挚的歉意、在这段时间内、我一直在关注其他问题。

您是否仍然受困于此问题？ 我从不使用 IAR 进行下面的测试、通常使用 CCS。

如果您还有任何其他发现、请告诉我。 我正在处理您的问题、并将尽快提供我的更新。

——
谢谢、此致、
Jagadish。

Jagadish 早上好 、

感谢您的答复。 从那时起、我们没有对案例进行新的更新。 如上所述、1MB 是8字节传输的倍数、因此 CRC 引擎不应填充0x00、但是在使用0x00 (工作)而不是0xFF (不工作)填充未使用的1MB 存储器时、看起来像这样考虑我的实验。

感谢您的跟进。

黄志华

请您设置一次实时调试会话、因为现在我没有 IAR Workbench 了。

我将在上午10点至晚上8点 IST (印度标准时间)开放、因此根据您的空闲情况、请设置一个现场调试会话。  

——
谢谢、此致、
Jagadish。

感谢您观看现场调试会话建议。  

遗憾的是、我们的设置尚未准备好继续解决此问题。 目前、我们选择使用填充的0x00而不是0xFF 来解决该问题。

但是、我在下面总结了我们的实验和其他证据、以供您进行调查。 如果您能提供任何提示、我们将不胜感激。

• 使用 DMA CH15双字(64位)传输将闪存 ROM 位置压缩到 CRC 引擎 PSA 寄存器、半自动模式。
• 软件二进制代码恰好是263310字节(257.138671875KB)。 为了使其对于 DMA/CRC 可被8整除、我们必须将其四舍五入、最高为263424字节(257.25KB)。
• 使用0xFF 将 未使用的存储器空间填充为1MB。
• 根据下面的结果、我们得出了在计算范围介于270KB 至275KB 之间时发生 CRC 不匹配的结论。
• 请注意：即使这两个 CRC 都不匹配、使用 TI UniFlash 为1MB 空间导出的器件存储器也始终相同(导出的 Intel 十六进制文件相同)。

Jagadish 的好日子

我已经更新了最后一次回复的屏幕截图、以便更清楚地了解 IAR EWARM IDE 和 TI UniFlash v8.8.0之间交替的闪存编程序列、在闪存 ROM 的第一个 MB 中填充或0xFF 未使用的存储器空间。

谢谢。

抱歉、我再次更新了捕获、闪存序列4和5之前是反向的。 现在可以、如下所示：  

尊敬的 Chuck：

我对这一晚的反应表示诚挚的歉意,我在这段时间内一直关注其他问题。

您能否确认您是否仍然遇到此问题。

如果需要、我将立即尝试自行重现并调试此问题。

——
谢谢、此致、
Jagadish。

您好 Jagadish、

我们仍在同一时刻、并将感谢您的帮助。 请随时发帖。

此致！

嗨块、

现在、我花了一些时间讨论这个问题、但我找不到问题的任何根本原因。

[报价 userid="91537" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1433637/tms570ls3137-uniflash-v8-8-0-behavior-with-mcu-programming-crc/5531395 #5531395"]请注意：即使两个 CRC 都不匹配、使用 TI UniFlash 导出1MB 空间的器件内存也始终相同

这对我来说很奇怪、即使存在 CRC 不匹配的情况、但 Uniflash 的导出数据是相同的。

在调试此问题之前、可能无法找到根本原因。

我还有一个建议、我以前从未使用 IAR Workbench、但在 CCS 中我们可以做一件事。

我的意思是、在从 Uniflash 刷写代码之后、我们仍然可以连接到控制器、而无需再次刷写代码。

例如、请参阅以下步骤：

1.首先我从 UniFlash 中刷写代码：

现在从 CCS 启动配置：

3.现在我已连接到目标内核：

4.执行此操作后、无需任何新的代码编程即可查看控制器的存储器数据：

5.我还可以看到反汇编代码:

6.我们也可以逐步调试装配体。

7.我建议执行此过程的原因是、我们可以观察 Uniflash 中的数据如何编程到控制器中。 这在这种情况下可能会有所帮助。

同样、我不确定如何在 IAR 中实现。

——
谢谢、此致、
Jagadish。

是的、非常奇怪。 UniFlash 导出是二进制相同的、并使用 Beyond Compare 进行检查。 现在、您已经知道为什么要进行这个捕获(来自 Excel)来查找发生不匹配故障的区域、这个区域介于270kB 和275kB 之间。

这是因为我无法通过比较转储(它们是相同的)来检查确切位置、唯一能做的就是修改软件以计算填充0xFF 1MB 空间内给定范围的 CRC、直到发现 CRC 故障。  

今天的底线：

• 通过使用0x00将未使用的存储器填充至1MB、相同的 CRC、使用 UniFlash 或 IAR EWARM、以任意顺序编程。
• 通过将0xFF 填充未使用的存储器至1MB、不同的 CRC (UniFlash 和 IAR EWARM)-不匹配位置介于270KB 和275KB 之间(软件修改 DMA 传输大小和 CRC 压缩引擎接收大小)。
• 通过查看 Excel 捕获结果(以前的文章)、我们感觉当 UniFlash 对填充了0xFF 的1MB 文件进行编程时、看起来像是"使用0xFF 无法正确写入闪存位置"。 它是否假设不需要写入0xFF、因为这是默认的存储器状态？？？ ...但再次,为什么出口提供相同的产出????
• 我再次怀疑的是 TMS570 64位 CRC 引擎 在访问存储器时(双字或8字节对齐)的处理方式。

您可以将此帖子保持打开多长时间？ 如果您愿意、我们可能会向您提供一个设置、您可以使用"远程桌面"进行实验。

感谢您的支持。

嗨块、

我的道歉我是在圣诞节假期,没有得到足够的时间在这个问题。

通常我只会在一周内解决的大多数问题、此问题需要更多时间、因为我无法在结束时重现此问题、我需要您的代码。

如果您提供远程设置并准确指导我如何操作、这可能会很有帮助、这样我就可以从结束时进一步调试和纠正问题

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：

新年快乐！

是的、请向我发送一个会议邀请、以便我可以共享我的桌面进行故障排除。 我位于东部时区(纽约)、我们将于上午10：00开始营业。

谢谢。