【新手请教】用CCS编译生成的319K的目标文件，为什么能加载到32K的FLASH中？

FreeBlues

【新手请教】用CCS编译生成的319K的目标文件，为什么能加载到32K的FLASH中？ [复制链接]

【新手请教】用CCS编译 eZ430 Chronos  项目，生成的目标文件 ez430_chronos_915MHz.out 有319K，为什么能加载到32K的FLASH中？

 

前几天折腾我的 eZ430 Chronos  无线手表开发套件，在使用无线更新固件时，把手表刷死了，于是就把TI提供的官方源码编译了一遍，使用CCS重新刷了FLASH，但是发现一个非常奇怪的现象：

输出路径下生成的目标文件 ez430_chronos_915MHz.out 有97K，如何能加载到32K的FLASH中？

 

就算是 ez430_chronos_915MHz.txt 文件的大小也有 97K ，但是eZ430 Chronos 使用的是 F6137 的芯片，最大的FLASH只有32K空间，如何能加载进去呢？ 而且加载进去之后貌似一切正常？

 

作为一名新手，百思不得其解，请教各位，究竟加载到手表里去的是哪个文件呢？

目录如下：

[ 本帖最后由 FreeBlues 于 2012-7-17 00:03 编辑 ]

FreeBlues

有人能指点一下不？

FreeBlues

已经想明白了，因为TI-TXT文件是用TXT的形式来表示16进制数据，用文本编辑器打开生成的目标文件 ez430_chronos_915MHz.txt

 

其内容为：

 

@8000
5A 14 31 80 1A 00 CA 0E B0 13 90 E6 0E 43 3F 40
C8 42 B0 13 E6 C4 81 4C 12 00 81 4D 14 00 CC 0A
B0 13 44 EB 0E 43 3F 40 20 41 B0 13 E6 C4 81 4C
16 00 81 4D 18 00 36 40 11 00 37 40 26 1D 0A 43
28 47 19 47 02 00 CC 08 CD 09 1E 41 12 00 1F 41
14 00 B0 13 96 DA 0C 93 09 38 81 48 08 00 81 49
0A 00 27 52 1A 53 16 83 EB 23 02 3C 0A 93 99 24
7A 90 0F 00 49 28 7A 90 0F 00 2D 24 1C 41 12 00

...........

@fa5c

...........

D6 1E 00 00 02 00 E8 1E 00 00 01 00 EA 1E 00 00
01 00 A6 1E 00 00 01 00 A7 1E 0A 00 01 00 A9 1D
01 00 01 00 7D 1E 00 00 01 00 7C 1E 00 00 01 00
87 1E 00 00 01 00 25 1D 00 00 01 00 35 1E 00 00
01 00 BE 1E 00 00 00 00
@ffe0
1C 95
@ffea
86 E3 E8 CA BC 8B A6 EE
@fffe
E2 E8
q

 

16个BYTE一行的一共有1982行,8个BYTE的有一行

其余的应该是指示地址和发送指令的，如：

 

@8000   是FLASH存储区的开始地址；

中间的 @fa5c ，最后部分的 @ffe0 和 @ffea 以及 @fffe 的作用应该类似。

 

这样的话，把上述数据转换成16进制后的大小就是： 1982*16 + 1*8 = 31,720 byte

 

也就是说这个目标文件的长度约为31KB多一些，刚好可以写入FLASH区。

 

这个疑惑解决了，新的疑惑又出现了，我把CCS的编译选项设置为生成INTEL-HEX的目标文件格式，结果生成了一个名为 的文件，这个文件可是纯粹的二进制格式，它的长度为75KB，看来CCS要把它加载到32KB的FLASH中也需要进行一些转换工作了，不过这个转换的具体细节我就猜不出来了。

Triton.zhang

纠正你一个观点,HEX文件并不是纯而进制文件。
intel的HEX文件是按照一行一条记录的方式保存烧录文件的。每行的头几个字节分别代表了命令和地址。
所以它的长度会大于BIN文件。
只有BIN文件才是用二进制方式保存烧录文件的，所以BIN文件大小能反应出实际代码的容量。
关于HEX文件的格式，你可以在百度找到相关的文档。这里就不一一去列了.

FreeBlues

多谢指教，看来对于新手来说很多常识性的概念都需要好好了解啊，否则就会出现错误