5 rtt-studio修改lds链接文件

0x8000 0000本来是boot，上面下载完，boot就没了，说明上面load地址确实是0x8000 0000而不是lds的0x8000 c000

stlink_program.bat这个脚本加载的是elf，关键生成的elf文件本身里边load地址就是错的，说明lds链接时候出错的吧

问题最上面两个截图就是解析elf的数据，load地址没改过来，比较奇怪

@jimmykudo studio这个工具在修改链接脚本后需要清空项目重新编译才会更新，试试这个方法。另外我看了下正常引导的elf文件load地址也没变。

上面方法不行的话，可以安装上stm32cubeprogrammer下载你的elf文件看看有没有问题

stm32cubeprogrammer下载hex没问题，下载bin，填正确地址也没问题，打开elf识别的地址也是0x0800 0000

stlink_program.bat这个脚本是自动生成的，如果可以改成hex而不是加载elf也行啊

@jimmykudo 使用stm32cubeprogrammer下载elf文件能不能正常运行呢，要是不能运行就是studio的问题了。
stuio更新记录

1. 1.1.5 修复了链接脚本无效的问题
2. 1.1.4 版本支持外部flash下载，这点意味着用户可以对调用cli工具可以允许用户修改参数了

目前用的版本，已经无法再更新了。

能否给个邮箱，我可以把工程打包发您看下吗？

@jimmykudo 2.0.0是当前最新版本了，我没测试环境没法验证你的工程。不能下载hex文件应该是studio自身的问题，我尝试改成hex下载调用的还是elf。麻烦这俩大佬看看有解决方案吗@aozima @zouyu

@jimmykudo 对了，可以试试studio仿真是否正常，也关注一下仿真用的是不是elf文件

问题已基本定位清除
起始地址0x08000 0000，最后四个必须都是0！不是0就会强制清0，

lds文件如果写0x0801 0000 readelf得到的load地址就是0x0801 0000，如果lds写0x0801 2000得到的load地址还是0x0801 0000

补充：jlink下载，地址没有问题，所以用arm-none-eabi-readelf.exe -l rtthread.elf直接查看的

基本确认，其他工程也都是的，结论：
lds文件rom地址0x0800 0000，后四个0不是0也会强制清0作为elf里的load地址，
如果lds文件rom地址写0x0800 8000，readelf的load地址为0x0800 0000，
如果lds文件rom地址写0x0801 0000，readelf的load地址为0x0801 0000，
如果lds文件rom地址写0x0801 2000，readelf的load地址为0x0801 0000，
另外，jlink下载可以按正常地址下载仿真，stlink不行，用stlink基地址要为0x08xxx 0000.

问题基本找到了，目前结论如下：
lds的load地址，必须是0x08xxx 0000格式，最后四位不是0，导入到elf的load地址也会自动清0，如
lds的load地址0x0800 8000、0x0800 C000,编译出来elf的load地址都是0x0800 0000，
lds的load地址0x0801 0000、0x0801 2000,编译出来elf的load地址都是0x0801 0000，
即使elf的load地址是错的，jlink下载还是可以正常下载，也许jlink加载的是hex文件吧。不知道这个问题官方有没有一个合理解释。目前看是arm-none-eabi-ld.exe加载lds这一步导致的。

@Jone
问题基本找到了，目前结论如下：
lds的load地址，必须是0x08xxx 0000格式，最后四位不是0，导入到elf的load地址也会自动清0，如
lds的load地址0x0800 8000、0x0800 C000,编译出来elf的load地址都是0x0800 0000，
lds的load地址0x0801 0000、0x0801 2000,编译出来elf的load地址都是0x0801 0000，
即使elf的load地址是错的，jlink下载还是可以正常下载，也许jlink加载的是hex文件吧。不知道这个问题官方有没有一个合理解释。目前看是arm-none-eabi-ld.exe加载lds这一步导致的。

我用keil修改flash地址，然后读出axf文件的信息发现axf文件和keil修改的是一致的。由此来看studio生成的elf文件确实是错误的

@Jone 不能再这里直接改后缀名

@jimmykudo 可能是因为stm32 F系列片内 flash的扇区划分的原因，从0x8010000 开始扇区是64k对齐的，stlink 去编程时的下载算法也按照一个扇区去写flash

只能自己写脚本下载，但是还是没办法仿真，确实比较难搞。

@Jone 是的，IAR和KEIL都是对的，

@chenyaxing 应该不是这个原因，stlink下载elf文件的load地址是来源elf，elf本身read的地址已经是错的，而jlink下载的应该是hex，所以应该还是链接阶段生成elf过程出错的，arm-none-eabi-ld.exe这个工具怎么处理的不清楚

@chenyaxing 我用AT32403A做测试，flash页大小2k，这样flash地址只需要2k对齐就行了。把脚本中flash地址改成0x0800300但生成的elf文件还是0x08000000

@aozima @armink 二位大佬能给个结论吗？

期待解决

@rcp @lizhen9880 麻烦看下

@jimmykudo 要不把这个帖子上有价值的内容整理一下重新发帖试试，这个帖子人多却没有官方人员跟到底

新发帖还是被各种答案覆盖了

目前没有官方回复，测试结果是：

估计是studio里面指定链接脚本没指定对，所以链接脚本的修改不管用。