[参考译文] UNIFLASH：使用 Uniflash & amp 加载(已编程) MSP430 MCU 文件；使用 UniFlash 读回(已导出)文件不相同

您好！

编译器生成的十六进制文件将仅具有需要刷写的必要数据、而导出的十六进制文件将导出整个闪存范围的所有内容。 其他格式也是如此。

您需要在导出的文件中剪切不必要的信息。 我不会依赖两个文件之间的差异来确认刷写成功。 我会改用数据验证。

Unknown 说：

 3) Hex & TXT 文件格式的"验证映像"选项失败。 为什么会发生这种情况并为其提供解决方案？[/引述]

十六进制实用程序生成的十六进制文件的"验证映像"是否失败？ 还是从内存导出文件失败？

谢谢

Ki

您好 Ki、

感谢您的回复。

请使用 Pra 2：标记与以下各点进行直列查看我的回复：

1) Pra1： 为什么两个文件不相同？  需要执行哪些操作才能使两个文件相同？ 起始地址设置为 0xc400、结束地址设置为0xFFFF。

 KI 1：编译器生成的十六进制文件将仅具有需要刷写的必要数据、而导出的十六进制文件   将导出整个闪存范围的所有内容。 其他格式也是如此。

  您需要在导出的文件中剪切不必要的信息。 我不会依赖两个文件之间的差异来确认刷写成功。 我会改用数据验证。

 PRA 2：我了解导出的文件包含0xC400到0xFFFF 之间的存储器数据、因为该设置在 Uniflash 中可用、而将加载到 MCU 中的生成文件具有实际代码大小、例如4KB、其地址范围为0xC400到0xD3FF。  我想说的是0xC400到0xD3FF 这两个文件应该是相同的、但实际上这两个文件都不匹配。  

 我不想使用此方法来确认刷写是否成功。 我想验证死板中的 MCU 中是否存在程序存储器损坏。  那么、是否有任何解决方案可用于此目的？

3) Pra：Hex & TXT 文件格式的"Verify Image"选项失败。 为什么会发生这种情况并为其提供解决方案？

 KI 1：十六进制实用程序生成的十六进制文件的"验证映像"是否失败？ 还是从内存导出文件失败？

 PRA 2： 来自"UniFlash"的"验证映像"选项无法使用.Hex 和.TXT 文件格式。 但是 、如果加载 映像 为.out 文件类型、则它会成功工作。 那么、为什么.hex 和.txt 文件的验证操作失败？

此致、

PRA

是的、它们应该是相同的。 如果不是、则出现问题。

您能否附加从十六进制实用程序生成的十六进制文件和从存储器导出的十六进制文件？ 让我们从这两者的 Intel hex 格式开始。

如果您不想私下分享、请与我开始私人 E2E 对话。 还应提及您正在使用的确切器件。

谢谢

Ki

您好 Ki、

我认为、为了进行实验和试用、任何文件都应该有效。

 MSP430FR2433。

PFA 15行.Hex 文件。

Load1_15Lines_0x4C0ATo0xC5AD.txt 是编译器生成的.hex 文件、但大小截止文件、该文件使用 Uniflash 加载到 MCU 中。

Export1-15Lines_0x4C0ATo0xC5AD.txt 通过 Uniflash 从 MCU 导出/回读文件。

对于这两个文件、扩展名从.hex 更改为.txt、因为无法在此处上传.hex 文件。 如果需要、您可以将两个文件的扩展名改回.hex。

此致、

PRA

e2e.ti.com/.../Load1_5F00_15Lines_5F00_0x4C0ATo0xC5AD.txt    

e2e.ti.com/.../Export1_2D00_15Lines_5F00_0x4C0ATo0xC5AD.txt

谢谢你。 我正在寻找一个器件来试用它们。 我会随时向您发布我的进度

Ki

相关信息

当我刷写您的十六进制映像 load1_15Lins_0x4C0ATo0xC5AD.hex 时、验证成功：

此验证失败了吗？

Ki、

Uniflash 屏幕截图显示选择了 MSP430FR2633、 但 Pra 报告说他们使用 的是 MSP430FR2433。

您好 Ki、

请检查发送给您的私人消息。

此外、正如 Chester Pls 所强调的、检查 MCU 的差异。

此致、

PRA

PRA -我能够再现您通过私人消息发送的*。hex 文件的问题。 有趣的是、我无法使用 CCS 重现此问题。 它看起来是 Uniflash 特定的。 我将跟进工程、并随时为您发布信息。

PRA、

对于"验证映像"失败的情况、您是否在 UniFlash 控制台中收到了确切的错误消息？

谢谢、

Ricky

PRA、

我让 Ricky 知道您的错误与我得到的错误相同、包括相同的地址(0xC404)。 我正在为 Ricky 设置一个远程环境、以便进一步调查。 我会随时向您发布我们的进度。

谢谢

Ki

PRA -很抱歉耽误你的时间。 在设置远程环境方面存在一些障碍。 完成此操作后、我可以让工程人员来看看。

Ki

PRA、

是否可以禁用"程序加载/闪存操作后运行目标"并重试？ 程序运行后、0xC404处的值似乎发生了变化。 当我禁用它时、验证通过。

谢谢

Ki

您好 Ki、

1)是、在禁用"在程序加载/闪存操作后运行目标"后、验证.Hex &.txt 文件的映像是否成功。

但是、对于.out 文件、即使  启用了"在程序加载/闪存操作后运行目标"、它仍然可以正常工作。 那么、原因可能是什么？

2) 2)您是否有机会 比较  相同.hex 文件的"加载映像"和"导出映像"？ 两个文件中都有一些未观察到的常见部分。 两个文件显示不同。 请查看下面的第3张图片 c)。

 a)画图1：加载的程序映像.Hex

 b)画图-2：导出的相同已加载图像的图像

 C)图片-3：两个已加载图像的比较(仅部分)。 十六进制、它是从电路板导出的图像。 显示两个文件完全不同。

此致、

PRA

1)是、在禁用"在程序加载/闪存操作后运行目标"后、验证.Hex &.txt 文件的映像是否成功。

但是、对于.out 文件、即使  启用了"在程序加载/闪存操作后运行目标"、它仍然可以正常工作。 那么、原因可能是什么？

您能否提供用于生成 hex 文件的*。out 文件？ 您可以通过私人邮件再次发送。

是的。 请注意、内容看起来不同的原因是数据在文件中的呈现方式。 在比较数据时需要考虑这一点。

格式为 Intel hex。 查看以下链接的格式部分：

https://en.wikipedia.org/wiki/Intel_HEX

根据格式、让我们 对文件中的某些行进行比较：

加载十六进制：

:0AC42A0000001EC400000020000006
:20C43400140218021D02220226022B0230023402390E02420247024B025002550259025F

导出的十六进制：

:20C42A0000001EC4000000200000140218021D02220226022B0230023402390E02420201
20C44A0047024B025002550259025E02630267026C02710275027A027F2830288028D0217

它们看起来不同、对吧？ 但实际数据是否不同？

通过查看 wiki、我们可以看到所有行都将以":"开头

接下来的两个字符是实际数据的字节计数

之后的两个是记录类型。

接下来的四个字符表示地址

然后是实际数据

最后两个字符是校验和。

因此、对于：

:0AC42A0000001EC400000020000006

"："是起始代码。

"0A"是数据的字节计数(10)

"C42A"是此行中数据的起始地址

"00"是记录类型。 "00"表示"数据"

"00001EC4000000200000"是实际数据。 这是字节计数中指定的10 (0A)字节

"06"是数据的校验和

现在看第二行：

:20C43400140218021D02220226022B0230023402390E02420247024B025002550259025F

我们可以看到实际数据为："140218021D02220226022B023002340239023E02420247024B02500255025902"

合并这两个数据、我们将在0xC42A 处有前42个字节：

00001EC4000000200000140218021D02220226022B023002340239023E02420247024B02500255025902

现在、在导出的十六进制中、第一行的数据为：

00001EC4000000200000140218021D02220226022B0230023402390E024202

第二行：

47024B025002550259025E02630267026C02710275027A027F02830288028D02

合并这两个数据、我们将在0xC42A 处有前64个字节：

00001EC4000000200000140218021D02220226022B0230023402390E02420247024B025002550259025E02630267026C0271027A027F2830288028D02

如果您查看前42个字节、您将看到它匹配。

导出的十六进制：

00001EC4000000200000140218021D02220226022B0230023402390E02420247024B025002550259025E02630267026C0271027A027F2830288028D02  

加载十六进制：

00001EC4000000200000140218021D02220226022B023002340239023E02420247024B02500255025902

查看 加载十六进制文件下一行中的接下来22个数据字节、您将看到数据为(粗体)：

:20C454005E02630267026C02710275027A027F02830288028D02910296029B029F02A40298

它还与导出的十六进制文件中的内容匹配

到目前为止、数据匹配。 因此、当尝试比较这两个文件以查看数据是否相同时、您需要考虑数据的呈现方式。

我知道解释有点乱、希望可以理解。

谢谢

Ki

您可能还有一个问题、就是为什么从十六进制实用程序拆分中生成十六进制文件、如下所示：

如果地址是连续的、第一行的字节长度为0x0A、而不是0x20？ 回答方法如下：

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1028708/tms320f280049-text-start-address-and-hex-memory-allocation/3805086#3805086

谢谢

Ki