大家好、
以下是客户可能需要您的帮助的问题：
我当前正在实现基于以太网的固件升级功能。 我通过 hexc2000.exe 将工程的.out 文件转换为 txt 格式。
在对闪存扇区编程时、我发现 ANSI 编码格式已经编程、但 ASCII 编码格式实际上是通过编程器编程的、因此当我完成编程时、我在运行时输入了一个非法中断。
我想询问是否需要将目标文件转换为 ASCII 编码以进行编程、但我没有在 TI 例程中基于 SCI 串行端口固件升级执行格式转换。
因此我有一个问题、为什么以 txt 格式编程后的数据格式与程序员编程的数据格式不一致。
--
谢谢、此致
你好，耶鲁，
请要求客户澄清以下问题、以便我们可以更好地分析此问题、并向相应的专家咨询以帮助他们：
客户提到他们参考了 TI 的 SCI 串行端口固件升级解决方案。 客户可能已经注意到、ROM SCI bootloader 需要主机按特定顺序发送目标地址、数据长度和数据- TRM 的5.8.1.1节" 引导加载程序"数据流结构对此进行了说明。 这种特定结构 对地址和数据字节使用 ASCII 十六进制对象格式-它只不过是"四个地址字节后跟数据字节"。 所有其他信息、如键值、保留字、块长度等、也应该是此结构的一部分、以字节为单位、如上面提到的 TRM 部分所述。 用户可以使用 hex2000实用程序、 通过串行闪存编程应用手册(http://www.ti.com/lit/pdf/sprabv4)中提到的以下命令、从目标文件(file.out)生成该特定的引导加载程序数据流结构格式文件(file.txt)
SCI 主机编程器解析 hex2000实用程序(file.txt)的输出、并将以字节为单位的信息发送到目标器件上的 ROM SCI 引导加载程序。
问题：客户说"当对闪存扇区进行编程时、我发现 ANSI 编码格式已编程、但 ASCII 编码格式实际上是通过编程器编程的"。
1) 1)客户在说 "对闪存扇区进行编程时使用的编程器是什么。 是其基于以太网的自定义固件更新解决方案吗？
2) 2)客户如何确认 ANSI 编码格式是否已编程？ 他们能否提供更多关于 ANSI 编码格式含义的详细信息？ 他们能否提供一些调试器存储器窗口快照并进行清晰解释？
3) 3)当客户说"实际上是通过编程器对 ASCII 编码格式进行编程"时、他们指的是哪个编程器？ 它们是指 TI 的 CCS 片上闪存插件、Uniflash、串行 SCI 闪存内核、还是某些其他第三方解决方案？ 请在此详细说明 ASCII 编码格式的含义。 他们能否提供一些调试器 存储器窗口快照并解释它们的含义？
4) 4)在他们的自定义闪存编程解决方案中、他们向闪存 API 的编程命令提供了哪些确切数据、API 对闪存进行了哪些编程？ 他们能否提供一些内存窗口快照以便我们了解？
5) 5)据我所知、此器件上没有以太网引导加载程序(我不是以太网或 F28388x ROM 专家-我可能错了。 我可以在一两天内与 BootROM 团队确认)。 客户使用 hex2000实用程序与 以太网模块配合使用时具体使用的命令是什么？
谢谢。此致、
瓦姆西
尊敬的 Vamsi：
感谢您的答复。
客户正在使用基于以太网的固件升级解决方案。 他们使用 CCS 生成 Intel hex 格式的升级文件、并通过 TFTP 协议将升级文件发送到 C2000以进行升级。
起初、他们使用主机将 hex 文件直接发送到 C2000。 他们发现 C2000接收到下图红色框中的数据、因此无法正常使用程序。
之后、他们发现在将 hex 文件发送到 C2000之前、他们需要将其转换为右侧的数据。 因为他们发现例程没有此转换过程、所以他们认为使用 sci 解决方案进行升级可以直接将 hex 文件发送到 C2000。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
另一个问题是它们使用 CCS 生成 Intel hex 文件。 在检查数据后、用户发现闪存地址之外有数据、但无法通过闪存 API 对这些数据进行编程。 应如何对这些数据进行编程？
红色框表示地址0x00001500处的数据
红色框之外的数据表示闪存地址0x00080000之后的数据
同样、CM 也存在类似情况：
