您的位置: OpenADSP社区论坛 -> SHARC/TigerSHARC专区 -> 新手上路 -> 21489的ldf导致工程报错
本帖共有269个阅读者
发表帖子 发表投票 回复主题
21489的ldf导致工程报错
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
楼主信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
21489的ldf导致工程报错

在cces上browse了一个sigmaforsharc_2.0.0的aplication例程,其ldf中有一行为

  mem_block0_sw16         { TYPE(SW RAM) START(0x00124300) END(0x0013BFFF) WIDTH(16) }

而编译之后报错cc3089:fatal error:Link failed

我把它改为

mem_block0_sw16         { TYPE(SW RAM) START(0x00124300) END(0x0013B3FF) WIDTH(16) }

之后编译不再报错,但是在21489的datasheet上面写的这一段地址为

Block 0 SRAM

0x0012 4000–0x0013 BFFF

这样的话应该写为0x0013BFFF的话是足够的,但为什么编译出现错误呢?


我是OP...
等级:管理员 参考IP地址:*.*.*.*
2018/4/9 16:58:08
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
1信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
答:你选者是处理器型号如果是支持3Mbit的片上空间,那么Block 0 SRAM-16bit的空间就是从

Block 0 SRAM

0x0012 4000–0x0013 3FFF

如果是5Mbit的片上空间,Block 0 SRAM的空间是从0x0012 4000–0x0013 BFFF,你的工程的LDF是不是还定义了其他的section在Block 0 SRAM?


我是OP...
等级:管理员 参考IP地址:*.*.*.*
2018/4/9 16:58:34
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
2信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
问:多谢!我看了工程,除了那一句,别的地方都没有了,只有那里有关于Block0 SRAM的描述。但我在编译器中的silicon reversion选择的是“any”不知道是不是这个的影响

我是OP...
等级:管理员 参考IP地址:*.*.*.*
2018/4/9 16:58:56
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
3信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
答:我们在本地试过你描述的工程,如果改为0x0013 BFFF,就会报错,是因为LDF文件后面还定义了一个'mem_block0_dm32'的段,地址空间重复了

我是OP...
等级:管理员 参考IP地址:*.*.*.*
2018/4/9 17:00:21
尊贵身份标志
OpenADSP(管理员)
OpenADSP
头衔:社区公民
帮派:无帮无派
帖数:5187
金钱:34761
积分:6369
注册时间:2011/6/7
4信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
问:我昨天看了pgr_rev的pdf对这个问题有了一些了解,也解决了我移植到21375时候ldf报错的问题。

说下我自己的理解。

你这里说地址重复了可能有些模糊,应该说是内部空间4个block的存储容量都是固定的。而对于每个block而言可以使用不同width长度的bus用以接口,这也就导致了地址的不同,所以说,如果在之前用16bit的bus接口block0用完了所有的存储空间的话,再使用32width的空间的话就会导致错误。


我是OP...
等级:管理员 参考IP地址:*.*.*.*
2018/4/9 17:00:38
Powered by OpenADSP Copyright © 2010 www.Openadsp.com. All rights reserved.154052 Call, 1 Queries, Processed in 0.031250 second(s),