MDK中绝对地址__attribute__((at(address)))使用疑问?

ubuntuman

使用MDK 4.12 想在FLASH地址0X0807F800的地方存放一个数据，故使用__attribute__((at(address)))函数，具体情况如下：  

（软件仿真情况下，硬件还没试验板子坏了）

1.   使用  const int x2 __attribute__((at(0x0807F600)))=10; /* RO */

Program Size: Code=8572 RO-data=513672 RW-data=308 ZI-data=2668       RO-data=513672   没有使用前RO-data=404       为什么？？

  
查看FLASH 在我要写的地址后跟随了一些其他数据，这又是为什么？  这些数据时那里来的。我并没有操作啊。

2.  不使用const关键字 依然如上；

3.  int x1 __attribute__((at(0x0807F800)));     不赋值的话，一切正常，但没意义了

baifern

我也遇到了同样 的问题了

ubuntuman

这么长时间了这个疑问还是没有解决？ 希望看了的坛友都发表下自己的意见，或描述下自己的发现，谢谢。  期待高人出现。

netting

const int __attribute__((at(0x0807F600)))   x2 =10; /* RO */

sjnh

MDK没用过，用IAR也会出现这种现象；

例如 定义1个变量在地址 100000处，编译完成后RO大小就是100000；  同理都是这样；
我曾定义变量在0x20000000这种地址，编译的时候输出文件一直增加，增加到几十M后我强制停止了；
不想出现这种现象，只需把数据定义为不初始化就可以；

个人理解为了初始化数据，编程程序生成的初始化数据要达到你定义的地址；这样生成BIN文件烧写进去才能运行正确；不然FLASH怎么能初始化；
再具体就没有研究了；

hygbeyond

这样的变量无法用通用的程序初始化，你自己可以研究一下gCC的启动代码就知道了，keil的也应该差不多，跳不出这个圈

Achin

你定义在那么远，下载工具在下载的时候，是要把这个地址区之前的区域全部擦除的。至于后面的那些数据，可能是编译器在拼接代码的时候没做好。

ubuntuman

结贴

今天又将这个问题在MDK4.5.3下试验了下，发现在4.5.3下没有问题，绝对定位处不会再跟一大堆 不知所云的数据了。 由此说明出现上述情况确实和编译器有关。但同时发现似乎MDK在使用绝对地址时对代码的大小计算有问题，此处不做讨论。

希望对该帖问题有更深入理解的大虾和又遇到新的疑惑的小虾都不吝惜的继续发表你们的见解和问题大家共同研究。

tiger_999

不要在定义的时候赋值

Louis_Bright

我也遇到过相同问题，我有个不是万能的解决方法，可以看看：
http://www.amobbs.com/thread-5528560-1-1.html

期待高手真正解决。

pogulu

tiger_999 发表于 2013-5-12 23:38
不要在定义的时候赋值

不在定义的时候赋值 ，是说这样吗

const int x2 __attribute__((at(0x0807F600))); /* RO */


能否透露更多使用上的细节、

xjtyOnly51

mark， thanks

sddzycnq

好久没来坛子里发言了。看到这位仁兄的问题。想想以前也是自己走过的路。
找问题得找根本。这个问题表象是你说的这样。但你顺藤摸瓜不难发现，这和MDK工具（这里说工具更合适，说汇编器，编译器，链接器，很多人就不会看下去了）有直接的关系。其实再分析的话应该是链接器的关系。
那么就应该从MDK的链接器手册入手，所以这里必须要看的资料是ARM Compiler toolchain v4.1 for µVision Using the Linker。

下面一一解答你的问题：

1.   使用  const int x2 __attribute__((at(0x0807F600)))=10; /* RO */
Program Size: Code=8572 RO-data=513672 RW-data=308 ZI-data=2668       RO-data=513672   没有使用前RO-data=404       为什么？？

答：首先我对你提供的这组数字有点疑惑，本应该0x07F600 －8572 － 513672 ＝ －4；但结果是－516。所以断定你在0x08007f800的位置还放了一个int型数据。
如果如我所料，那么解释如下：
由于0x0807f800远超过了程序的code+ro的长度。所以链接器会在7F800的位置放一个int型数据。这样，RO段的大小为：
0x07f804（这里要加上放置在些的int型数据长度4）减去code长度8572等于513672.
而在没有使用这个特性时，ro长度为程序实际ro长度。
     

查看FLASH 在我要写的地址后跟随了一些其他数据，这又是为什么？  这些数据时那里来的。我并没有操作啊。

答：后面跟的是RW段数据。

2.  不使用const关键字 依然如上；

答：const只表示变量属性。而决定变量位置的是后面的at。

3.  int x1 __attribute__((at(0x0807F800)));     不赋值的话，一切正常，但没意义了

答：你指的一切正常是什么意思？但如果是你写的这样的话，ro的长度与赋值时是一样的。

sddzycnq

Louis_Bright 发表于 2013-5-13 09:13
我也遇到过相同问题，我有个不是万能的解决方法，可以看看：
http://www.amobbs.com/thread-5528560-1-1.ht ...

请看我的回复是否对你有用。

hejiang177

mark一下，也正用到这个问题

Feco

mark ,     

qmkj_007

我也遇到此问题了，，。

WM_CH

结合上图说下STM32F407ZGT6的启动过程（采用Cortex-M4、Cortex-M3内核的芯片基本都是这个过程）：
上电后首先从0x00000000（映射到0x08000000，这里只考虑从内部Flash启动）处获得中断向量表，
然后在运行用户代码之前会在（标号2）处有一段引导代码负责把存在Flash中的初始化变量的值Copy到SRAM中对应的变量位置（标号3），之后把ZI区域全部清零（标号4），之后才正式开始运行用户代码（标号5）。




我猜是楼主在目标地址定义了一个RO的值以后，RO程序段膨胀了！本来只用了一点，再连上绝对目标地址处的一个值，然后中间全是0xFF。
目标绝对地址之后的值是RW程序段。

具体为什么会这样，以及如何解决，估计真的要看链接脚本了。
其实用分散加载文件Scatter貌似可以奏效，具体不详。。。

Gorgon_Meducer

看到这个老坟，我想说……为啥不提供map文件？看看map不就啥都知道了？