工具与软件：
你(们)好
我在使用适用于 TMS570LS0914 IC 的 CCS 时遇到一些问题(我们使用的是自定义引导加载程序)。 我已经在 .cmd 文件中生成(使用 TI 编译器) bin 和 hex 文件、其中包含矢量和闪存的0x00020000地址。 (我使用此文件作为应用文件)。 当通过我们的专有工具刷写 十六进制文件时、它会卡在某个地方、但当我们使用相同代码(同时生成)的 bin 文件时、它使用 HEXVIEW 工具转换为十六进制、并通过我们的专有工具进行刷写。 它正常工作。
我还必须检查另一种可能性-如果我在.cmd 文件中生成了地址为0x00020000的十六进制文件。 和通过 UNIFLASH 工具刷写十六进制文件也可以正常运行。
如果我们假设它的应用程序代码问题,但十六进制文件通过 HEXVIEW 工具生成它的工作,所以我无法 理解它的设置问题在 CCS 或任何其他.
请协助解决此问题。
尊敬的 Rahul：
我对此有怀疑：
bin 文件没有地址信息、它只是由数据组成。
例如、请参考下图、我将生成具有0x20020地址的输出文件、当我在 HexView 中查看.bin 文件时、它会显示数据从0x00000000开始
即使我尝试通过 UniFlash 对此.bin 文件进行编程、也要手动告知二进制文件的起始地址。
另一方面、hex 文件还包含以下文件中的地址信息：
例如、对于以下同一代码、请参阅.hex：
前两行指示数据从0x20020开始、采用 Intel 十六进制格式。
因此、十六进制文件也不需要在 UniFlash 中提及任何地址：
根据上述信息、当您 直接对十六进制进行编程时 、它无法正常工作、因为应用程序位于某个其他地址、如本例中所示的0x20020。 此处应该有引导加载程序、引导加载程序应该能够正确调用应用、然后只能正常工作、这里可能缺失了它。
不过、您说该方法在将二进制转换为十六进制时起作用、因为在这种情况下、应用程序的起始地址可能是0x00000000、因此可能会覆盖引导加载程序、而现在应用程序可能会在复位后直接调用、这可能就是此处工作的原因。
从这个角度考虑一下。
——
谢谢、此致、
Jagadish。
你(们)好
我有以下可能性检查
我已经使用自定义引导加载程序、其地址为0x0000000、应用程序地址为0x00020000
在地址0x00020000处生成了 bin 和 Hex 文件
我必须检查以下可能的情况。
1.当我使用 HEXVIEW (在此过程中、我将添加起始地址0x00020000)将 BIN 文件转换为十六进制文件并通过引导加载程序进行闪存时-运行正常
2.当我通过 CCS (地址为0x00020000)直接生成十六进制文件并通过引导加载程序进行闪存时-它无法正常工作(主要问题)
在这两种情况下、CCS 编译器的所有设置相同。 (同时生成 Bin 和 hex 文件。 我们使用 HEXVIEW 添加地址0x00020000并生成十六进制文件)
3. 当我使用相同的编译器设置通过 CCS (地址为0x00000000)直接生成十六进制文件并通过 UNIFLASH 进行闪存时-工作正常。
所以、第二种场景无法正常工作、
我正在比较第8873行数据中第1个和第2个方案的十六进制文件变得不同。
HEXView 生成的十六进制文件数据 直接 生成的十六进制文件数据
您能给我解决方案吗？
尊敬的 Rahul：
你能试一下一件事吗、
您能否在8874处添加一个直接生成的十六进制文件行：
并包括以下行：
: 045464000000000044.
我之所以建议这样做、是因为两个十六进制文件几乎相同、只是在直接生成的十六进制文件中、5464地址的4个位置不是全部填充为零、但这是在转换后的文件中发生的。
如果您包含上述建议行、则可能会使两个十六进制文件相同、并看看执行中会发生什么情况。
——
谢谢、此致、
Jagadish。
