[参考译文] TMS320F280039C：从 CCS 生成的十六进制代码和从 Uniflash 读取的十六进制代码看起来不同

您好、Wayne、

它是关于 UniFlash 输出中已擦除位置的值0xFFFF 吗？

还是字节序？

谢谢、此致、
Vamsi

尊敬的 Vamsi：

我认为0xFFFF 是相关的、但我不确定其他一些是否相关。

例如、这来自 Uniflash。

这是 CCS 的原始十六进制文件。

实际上、我已经比较了 CCS 生成的校验和以及 Uniflash 读取的校验和、它们是相同的。

但用户希望使用另一个十六进制编辑器进行确认。

也就是说、通过第三方工具来重复确认这一点、以确保它们相同。

尊敬的 Wayne：

在我看来、擦除字都已下载、因为从 Uniflash 下载的内容包括给定存储器范围内的所有位置。

我将把这个分配给我们的 UniFlash 团队、以进一步帮助您(我将在办公室外工作一周)。

谢谢、此致、
Vamsi

尊敬的 Vamsi：

我认为也是这样。

因此、请让 CCS 或 Uniflash 团队对此进行澄清。

CCS 十六进制生成中是否有任何选项可用于生成与 Uniflash 相同的 Intel 十六进制文件？

黄维恩

同意。 与仅具有实际数据的原始十六进制文件相比、UniFlash 会转储整个存储器内容。

Ki 的回复部分正确。  它还有更多内容。   

在 Ki 引用的同一文档中，搜索标题 为 Image Mode (图像模式)和--fill Option (--fill 选项)的子章节。  了解如何将 ROMS 指令放入命令文件中。  ROMS 指令将描述相关的存储器范围(可能是所有闪存)。  使用图像模式和--fill 选项。

另一个需要考虑的解决方案...  阅读 此论坛帖子以及该主题的其余部分。  其中显示了如何更改链接器命令文件以填充与闪存对应的存储器范围。

请理解、虽然我相信这些解决方案能够正常工作、但我无法保证。  hex实用 程序 hex2000的输出和 UniFlash 的转储功能未设计或测试为彼此匹配。  我们可以找到一种使该工作成为意外功能的方法。   

谢谢、此致、

乔治

尊敬的 Ki、George：

您是否会先对其进行测试并确认我们、因为这些工具 CCS hex unutility / Uniflash 都来自您的团队？

我想只有 CCS hex 实用程序/Uniflash 的作者知道这些 hex 文件是如何生成的。

黄维恩

您好、Wayne、

我不确定您希望我们测试什么。 正如 George 提到的、您通常不会比较十六进制文件、其中一个文件基本上是内存转储、另一个文件是从构建工具生成的。 UniFlash 存储器转储功能和十六进制转换实用程序均单独进行测试、以确保有效性和准确性。

请注意、 CCS 用于生成十六进制文件的十六进制转换实用程序来自不同的组(编译器组)、而不是创建 UniFlash (CCS 组)的组。

谢谢

Ki

好的、我相信您在他的上一篇文章中提到了 George 的权变措施。 如果客户可以向我们提供他的项目、我们可以查看一下。

谢谢

Ki

还请客户从 UniFlash 提供他的十六进制文件。 如果您不想公开发布、您可以通过 E2E 论坛发送消息。

尊敬的 Ki：

用户会感到困惑、为什么这与他们的项目相关、因为这应该独立于项目使用。

您是否只需使用如下所示的简单 TI 示例来展示这一点？

C：\ti\c2000Ware_4_01_00_00\driverlib\f28003x\examples\led_ex1_blinky.c  

这是他们使用的十六进制实用程序参数。

--memwidth=16 --romwidth=16 --diag_wrap=off --intel

或者、您是否认为您首先想了解任何特定信息？

黄维恩

除非我们有客户使用的示例、否则我们无法保证解决方案能够满足客户的特定用例。 正如 George 提到的、客户尝试的是不受支持的用例。 我们不希望遇到这样的情况：它适用于一个简单的闪烁示例、但当客户在其实际项目上尝试时、结果低于预期。

否则、客户可以尝试 George 提到的步骤、看看是否对他们有效。

谢谢

Ki

尊敬的 Ki：

让我澄清一下。

您的意思是、您建议的方法可能只是针对特定项目的权变措施、而不是保证所有项目正常工作的系统方法？

黄维恩

我们无法保证任何内容、因为客户尝试将工具用于不是为其设计的目的。 正如乔治所提到的，它应该*起作用。 但这也不是我们已经测试或研究过的用例。 因此没有保证。