打印

IAR 生成的bin文件大于实际大小

[复制链接]
6215|39
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
m503022388|  楼主 | 2015-11-23 17:14 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
沙发
aozima| | 2015-11-23 18:33 | 只看该作者
你的format选择的是hex吧,编辑器打开观察内容

使用特权

评论回复
板凳
m503022388|  楼主 | 2015-11-24 08:53 | 只看该作者
aozima 发表于 2015-11-23 18:33
你的format选择的是hex吧,编辑器打开观察内容

不是hex,我的format选的是other,然后里面的output是raw-binary

使用特权

评论回复
地板
sjnh| | 2015-11-24 09:11 | 只看该作者
哈哈,连接文件地址分配的问题,当然是bin的问题;

(非430)偶然有一次程序是0地址开始,扩展了SDRAM在0x20000000地址,FLASH有字库,打算把字库编译到SDRAM中好烧写(特殊字库要带地址信息),以前都是hex文件,用bin,编译时计算机嗤啦嗤啦了半天,以为编译器死机了,生成的bin到了几百兆;

因为bin文件不包含数据地址信息,所以要整个数据填充,例如,程序从0开始100个字节,还有一部分从10000开始100个字节,那么生成bin会从0直接到10100,中间会填充无用的数据;而hex文件会指定位置;

使用特权

评论回复
5
m503022388|  楼主 | 2015-11-24 09:25 | 只看该作者
sjnh 发表于 2015-11-24 09:11
哈哈,连接文件地址分配的问题,当然是bin的问题;

(非430)偶然有一次程序是0地址开始,扩展了SDRAM在0x ...

但是不应该呀,正常来说hex比bin多包含了一些地址信息,会导致hex比bin更大。我生成的bin也确实比hex小个100+k,但是没意义呀,我要的是bin文件做串口烧写,不用烧写或调试器的,类似OAD。
我现在不明白的是,FLASH是256KB的空间,明明用仿真器下载完还能剩余空间,生成的bin文件却大的离谱。怎么办?

使用特权

评论回复
6
huangxz| | 2015-11-24 09:28 | 只看该作者
m503022388 发表于 2015-11-24 09:25
但是不应该呀,正常来说hex比bin多包含了一些地址信息,会导致hex比bin更大。我生成的bin也确实比hex小个 ...

一般是地址空间不连续导致的 ,建议你先看看map的情况

使用特权

评论回复
7
sjnh| | 2015-11-24 09:41 | 只看该作者
m503022388 发表于 2015-11-24 09:25
但是不应该呀,正常来说hex比bin多包含了一些地址信息,会导致hex比bin更大。我生成的bin也确实比hex小个 ...

检查你的linker地址分配文件,CC2530的FLASH好像是从8000H开始的,看看你的配置文件是从那开始的;
刚说了,bin文件没有其他信息,hex文件有地址信息;
例如:0地址有个数据xx,100地址有数据yy,中间没数据,那么生成的hex文件可能是:(举例,不是真的)
0000xxLRC
0100yyLRC
完成;
bin文件则是:
xx 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 yy
完成
你说谁大,
数据是连续的时候,hex文件大,不连续就很难说了

使用特权

评论回复
8
m503022388|  楼主 | 2015-11-24 09:43 | 只看该作者
huangxz 发表于 2015-11-24 09:28
一般是地址空间不连续导致的 ,建议你先看看map的情况

请问下map要看哪部分?是看CHECKSUM那堆吗?是不是CODE填充的那105 295byte的原因?
                ****************************************
                *                                      *
                *              CHECKSUMS               *
                *                                      *
                ****************************************

Symbol      Checksum  Memory  Start      End       Initial value
------      --------  ------  -----      ---       -------------
__checksum    0x874f   CODE   00002000 - 0000208F  0x0000 (#0x0000)
                       CODE   00002094 - 00007FFF
                       CODE   00018000 - 0001FFFF
                       CODE   00028000 - 0002FFFF
                       CODE   00038000 - 0003FFFF
                       CODE   00048000 - 0004FFFF
                       CODE   00058000 - 0005FFFF
                       CODE   00068000 - 0006FFFF
                       CODE   00078000 - 0007C7FF

                ****************************************
                *                                      *
                *        END OF CROSS REFERENCE        *
                *                                      *
                ****************************************

146 609 bytes of CODE  memory (+             105 295 range fill )
      24 bytes of DATA  memory (+ 87 absolute )
   7 360 bytes of XDATA memory
     192 bytes of IDATA memory
       8 bits  of BIT   memory
      12 bytes of CONST memory

使用特权

评论回复
9
huangxz| | 2015-11-24 10:00 | 只看该作者
m503022388 发表于 2015-11-24 09:43
请问下map要看哪部分?是看CHECKSUM那堆吗?是不是CODE填充的那105 295byte的原因?
...

code都会写入bin的.

使用特权

评论回复
10
309030106| | 2015-11-24 19:20 | 只看该作者
一般hex比bin多包含了一些地址信息,所以应该是hex比bin更大的

使用特权

评论回复
11
m503022388|  楼主 | 2015-11-27 14:29 | 只看该作者
huangxz 发表于 2015-11-24 10:00
code都会写入bin的.

我刚刚又调了下,发现同样是bin文件,用的编译配置文件不同,生成的大小也是差很多,用f8w2530.xcl生成的bin有130+k,这个应该是正常的,但是我用2530-sb.xcl编译出来的就有234k!我比对过两个生成的bin文件,后面生成的bin里面在靠近末尾有填充了60+k的0xff!这个怎么搞啊。。。。我想把这些填充无用的都去掉要怎么配置?我对比两个xcl文件做修改bin好像也没有变化啊

使用特权

评论回复
12
huangxz| | 2015-11-27 17:29 | 只看该作者
m503022388 发表于 2015-11-27 14:29
我刚刚又调了下,发现同样是bin文件,用的编译配置文件不同,生成的大小也是差很多,用f8w2530.xcl生成的 ...

没用过你那个芯片,实在不行,自己写个程序抽取一下也可以的.bin文件很好处理的.

使用特权

评论回复
13
tongbu2015| | 2015-11-28 10:18 | 只看该作者
这个具体的我就不太清楚的了,一般是直接生成.hex文件的

使用特权

评论回复
14
拉克丝| | 2015-11-28 11:25 | 只看该作者
bin文件大于实际大小

为什么要纠结这个问题呢

使用特权

评论回复
15
单片机菜菜| | 2015-11-28 15:42 | 只看该作者
我也是直接开启编译,开启优化,没注意这个问题。

使用特权

评论回复
16
pmp| | 2015-11-30 07:37 | 只看该作者
写入的小。

使用特权

评论回复
17
pmp| | 2015-11-30 07:39 | 只看该作者
还有头文件在hex里面。

使用特权

评论回复
18
m503022388|  楼主 | 2015-11-30 10:49 | 只看该作者
pmp 发表于 2015-11-30 07:39
还有头文件在hex里面。

我的cc2530是只有256kb的flash,如果生成hex的话就太大了,写不进去,所以只能用bin。
我的写入是直接由主机发送的,由2530的boot直接写flash实现下载更新。

使用特权

评论回复
19
m503022388|  楼主 | 2015-11-30 10:51 | 只看该作者
拉克丝 发表于 2015-11-28 11:25
为什么要纠结这个问题呢

因为flash不够啊,只有256k,bin和hex文件又太大,不懂是编译选项问题还是怎么回事。

使用特权

评论回复
20
m503022388|  楼主 | 2015-11-30 10:52 | 只看该作者
tongbu2015 发表于 2015-11-28 10:18
这个具体的我就不太清楚的了,一般是直接生成.hex文件的

但是hex太大了,都快超过flash两倍了。。。

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

6

主题

37

帖子

0

粉丝