TI中文支持网
TI专业的中文技术问题搜集分享网站

百思不得其解, 变量空间分配奇怪问题(DSP28027)

敢问各位高手, 最近遇到很奇怪的一个问题:

所使用DSP为28027,cmd中定义数据段(显然空间大小1024字)
RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
后面自定义了一个数据段
   commbuf             : > RAMM1        PAGE = 1

在main.c里定义以下几个变量
#pragma DATA_SECTION(sendT, "commbuf")
Uint16 sendT[260];
#pragma DATA_SECTION(receT, "commbuf")
Uint16 receT[260];
#pragma DATA_SECTION(CntPPR, "commbuf")
Uint32 CntPPR[250];
其它无涉及到commbuf的变量,精打细算,共需260+260+250*2=1020,commbuf正好放得下.

但编译结果空间不够(run placement fails for object "commbuf", size 0x474 (page 1).  Available ranges: RAMM1        size: 0x400        unused: 0x400        max hole: 0x400)
于是将sendT放到别的地方,编译通过,赶紧看map文件,看见如下百思不得其解的结果.
00000400   _receT
00000540   _CntPPR
00000880   _DevEmuRegs
可以看出receTemp占了0x140=320字的空间,明明定义的是260字的空间,为什么要占320字的空间呢?难怪原来320+320+500=1140=0x474,超出空间范围.

另外在main.c里还定义了一个变量
Uint32 accumulator[8];
看map文件竟然
00008600   _accumulator
00008640   _sendT
00008780   _dataFlash
很明显,明明只有8*2=16个字,却分配8640-8600=0x40=64个字.

sendT放到别的地方后,调试watch地址
receT[0]  0x400
receT[259] 0x503
CntPPR[0]  0x540
cntPPR[249] 0x732
可以看出0x504~0x53F空间没用,不给你用上,导致精打细算的地址空间不够

 

怎么会是这么个结果,一直都想不通. 谢谢高手前辈帮我分析分析

xiaofen Zhang:

回复 Hank Zhao:

非常感谢Zhao工,请问那28027的RAMM1的数据页多大?

如果这样,那定义大数组不得为了照顾这种分页机制, 拆成小数组?

敢问各位高手, 最近遇到很奇怪的一个问题:

所使用DSP为28027,cmd中定义数据段(显然空间大小1024字)
RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
后面自定义了一个数据段
   commbuf             : > RAMM1        PAGE = 1

在main.c里定义以下几个变量
#pragma DATA_SECTION(sendT, "commbuf")
Uint16 sendT[260];
#pragma DATA_SECTION(receT, "commbuf")
Uint16 receT[260];
#pragma DATA_SECTION(CntPPR, "commbuf")
Uint32 CntPPR[250];
其它无涉及到commbuf的变量,精打细算,共需260+260+250*2=1020,commbuf正好放得下.

但编译结果空间不够(run placement fails for object "commbuf", size 0x474 (page 1).  Available ranges: RAMM1        size: 0x400        unused: 0x400        max hole: 0x400)
于是将sendT放到别的地方,编译通过,赶紧看map文件,看见如下百思不得其解的结果.
00000400   _receT
00000540   _CntPPR
00000880   _DevEmuRegs
可以看出receTemp占了0x140=320字的空间,明明定义的是260字的空间,为什么要占320字的空间呢?难怪原来320+320+500=1140=0x474,超出空间范围.

另外在main.c里还定义了一个变量
Uint32 accumulator[8];
看map文件竟然
00008600   _accumulator
00008640   _sendT
00008780   _dataFlash
很明显,明明只有8*2=16个字,却分配8640-8600=0x40=64个字.

sendT放到别的地方后,调试watch地址
receT[0]  0x400
receT[259] 0x503
CntPPR[0]  0x540
cntPPR[249] 0x732
可以看出0x504~0x53F空间没用,不给你用上,导致精打细算的地址空间不够

 

怎么会是这么个结果,一直都想不通. 谢谢高手前辈帮我分析分析

xiaofen Zhang:

回复 Hank Zhao:

谢谢Zhao工, 我分析了一下,大概是以0x40(64字)为1页,所以大数组尽量以64字为倍数定义。

敢问各位高手, 最近遇到很奇怪的一个问题:

所使用DSP为28027,cmd中定义数据段(显然空间大小1024字)
RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
后面自定义了一个数据段
   commbuf             : > RAMM1        PAGE = 1

在main.c里定义以下几个变量
#pragma DATA_SECTION(sendT, "commbuf")
Uint16 sendT[260];
#pragma DATA_SECTION(receT, "commbuf")
Uint16 receT[260];
#pragma DATA_SECTION(CntPPR, "commbuf")
Uint32 CntPPR[250];
其它无涉及到commbuf的变量,精打细算,共需260+260+250*2=1020,commbuf正好放得下.

但编译结果空间不够(run placement fails for object "commbuf", size 0x474 (page 1).  Available ranges: RAMM1        size: 0x400        unused: 0x400        max hole: 0x400)
于是将sendT放到别的地方,编译通过,赶紧看map文件,看见如下百思不得其解的结果.
00000400   _receT
00000540   _CntPPR
00000880   _DevEmuRegs
可以看出receTemp占了0x140=320字的空间,明明定义的是260字的空间,为什么要占320字的空间呢?难怪原来320+320+500=1140=0x474,超出空间范围.

另外在main.c里还定义了一个变量
Uint32 accumulator[8];
看map文件竟然
00008600   _accumulator
00008640   _sendT
00008780   _dataFlash
很明显,明明只有8*2=16个字,却分配8640-8600=0x40=64个字.

sendT放到别的地方后,调试watch地址
receT[0]  0x400
receT[259] 0x503
CntPPR[0]  0x540
cntPPR[249] 0x732
可以看出0x504~0x53F空间没用,不给你用上,导致精打细算的地址空间不够

 

怎么会是这么个结果,一直都想不通. 谢谢高手前辈帮我分析分析

Hank Zhao:

回复 xiaofen Zhang:

是的,一个数据页为64个字。大数组不必拆成小数组,比如一个数组大小为5*64+10个字,那么它会占用6个数据页,只有最后一个数据页会浪费一部分空间。如果RAM空间足够的话,可以不用考虑这部分RAM的浪费。

赞(0)
未经允许不得转载:TI中文支持网 » 百思不得其解, 变量空间分配奇怪问题(DSP28027)
分享到: 更多 (0)