尊敬的 Champs：
我的客户正在调试基于 F280049的项目 OTA 函数。 有时升级会失败、问题似乎在这里：
客户注意到、如果数据块大小超过0xFFFF (以0X010531为例)、HEX2000会将其视为0X0531数据大小。 这会导致产生的十六进制障碍。
如何解决该问题？ 十六进制是否支持>0xFFFF 数据大小块？ 或者我们可以在 CCS 中分割数据块吗？
此致、
布赖恩
我认为您需要更具体地解决这个问题。 如果您共享了您的设置或命令脚本文件、可能会改善任何答案。
[quote userid="320510" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1228926/hex2000-cannot-correct-deal-with-block-exceeding-0xffff-data-size 能否支持>0xFFFF 数据大小块？我猜您是在制作 Intel Hex 文件。 我确认 hex2000.exe 在这种情况下至少会将超过65536字的图像自动分解为单独的英特尔十六进制文件块。 例如、我使用的命令文件包含以下内容：
您可以看到、在0x80000 (即0x90000)处的65536个字之后插入了一个新的扩展线性地址记录、但没有明确的指令。
客户未使用英特尔十六进制而是 ASCII 十六进制文件
该信息会改变问题。
[quote userid="320510" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1228926/hex2000-cannot-correct-deal-with-block-exceeding-0xffff-data-size 能否支持>0xFFFF 数据大小块？对数据块大小没有限制、因为 ASCII 文件格式中没有大小规格。 它只是一个具有起始地址的任意长度字节流。
我想您可能会说您不能指定大于0xFFFF 的起始地址？ 是这样吗？ 如果不是、请通过实际的 hex 文件样片澄清问题。
在实践中、我看不出问题。 例如、我可以使用起始地址0x80000生成 ASCII 十六进制文件：
理论上,文件似乎不正确和矛盾。 最新的 PDF 手册(https://www.ti.com/lit/ug/spru513y/spru513y.pdf)指出16位地址、但8个字符表示可以使用32位地址：
更让人困惑的是、在线版本(https://downloads.ti.com/docs/esd/SPRUI03/ascii-hex-object-format-ascii-option-stdz079753.html)
指出32位地址和16位地址：
您的客户是否可能只是阅读了本手册并假设32位地址不可能？
George Mock 请查看上述文档摘录并确认为什么在该字段支持32位地址时为 ASCII 十六进制指定了16位地址？
