stm32f756IGTX系列芯片,之前在IAR 8.10.1版本上编译后bin文件开头值为0x20012348,后面在8.30.1版本上编译后为0x20038389;
在IAP程序中有下面判断语句:if ((((__IO uint32_t)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000),8.10.1的版本能通过,8.30.1的不能通过;
请问同样的代码在不同版本的编译器里面出现这种情况,是什么原因导致?应该怎么解决?
1.这种情况很可能是由于编译器版本的变化导致的。不同版本的编译器可能会对编译后的二进制文件进行微调,从而导致二进制文件的内容发生变化,包括在不同版本下的链接地址也可能会有所不同。
2.对于您的具体问题,可能是由于8.30.1版本的编译器对链接地址进行了微调,导致生成的二进制文件的开头地址不同,因此无法通过IAP程序中的判断语句。
3.解决方法可能是在IAP程序中修改判断语句,或者使用与8.10.1版本相同的编译器版本来重新编译代码,保证生成的二进制文件与之前的版本一致。
不同的编译器版本可能有不同的症状,具体取决于所使用的特定语言、平台和开发环境。 以下是不同编译器版本可能会遇到的一些一般症状:
1.不同的语言特性:不同的编译器版本可能支持不同的语言特性或语法。 使用较新版本的编译器可能允许使用新的语言功能或语法,而使用旧版本可能需要使用较旧的语言功能或语法。
2.不同的优化:不同的编译器版本在生成可执行代码时可能会执行不同级别的优化。 使用较新版本的编译器可能会产生更快或更高效的代码,而使用旧版本可能会导致更慢或效率更低的代码。
3.不同的错误消息:不同的编译器版本在遇到语法错误或源代码中的其他问题时可能会生成不同的错误消息。 使用较新版本的编译器可能会提供更详细的错误消息或突出显示需要修复的特定代码行,而使用较旧版本的编译器可能会提供更一般的错误消息。
4.与库或框架不兼容:不同的编译器版本可能与某些库或框架不兼容,这可能会在构建或运行代码时导致错误或其他问题。 使用较新版本的编译器可能需要更新或替换某些库或框架,而使用旧版本可能需要使用这些库或框架的旧版本。
5.性能差异:不同的编译器版本可能会生成以不同速度运行或消耗不同内存量的代码。 使用较新版本的编译器可能会产生更快或更节省内存的代码,而使用旧版本可能会产生更慢或更占用内存的代码。
使用与目标平台和开发环境兼容的最新稳定版编译器通常是一个很好的做法,因为这有助于确保代码优化、高效,并且没有已知错误或安全漏洞。
这种情况可能是由于编译器优化或者默认设置不同导致的,具体原因需要进一步的调查分析,对比编译过程的log。
具体原因可能包括编译器对地址分配、链接脚本、编译优化等方面的变更,导致生成的bin文件的起始地址发生了变化。因此,为了保证代码的正确性,建议在IAP程序中使用正确的起始地址。
为了解决问题,可以尝试在IAP程序中输出ApplicationAddress的值,以确定其具体数值。然后,根据生成的bin文件的起始地址,调整IAP程序中的判断语句,确保它能正确地判断出ApplicationAddress所处的地址范围。另外,也可以检查编译器的配置和链接脚本等方面,看是否有相关的变更。
简单来说,就是更改判断语句,改为判断一个范围。
这个是做IAP跳转用吗?我在IAR8.32.2上面试了一下
外部宏定义
#define ApplicationAddress (uint32_t)0x08008000
主函数调用时缺了两个*号
if (((*(__IO uint32_t*)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000)
{}
如果还不行,把你的报错内容贴上来我看看
如楼1所讲,肯定会存在区别,IAR 8.10.1版本 比较稳定 调试也比较方便,随着升级8.30.1版本上,默认设置肯定会存在差异,例:
新版的iar 不支持老的core__cm3.h 的头文件。
所以新版需要 直接用IAR 自带的core_cm3.h的头文件
在不同版本的编译器中出现这种情况,很可能是因为编译器的默认设置不同,导致生成的代码偏差。特别是在IAR版本更新后,编译器的默认设置可能会有所改变,例如编译优化等级、编译器选项等等。
为了解决这个问题,可以尝试以下方法:
检查编译器版本之间的差异,查看是否有相关文档或公告,了解编译器的默认设置是否发生了变化;
检查编译器选项、编译优化等级等设置,尝试将编译器设置一致,重新编译代码;
修改IAP程序中的判断语句,以适应不同版本的编译器生成的bin文件。
需要注意的是,修改判断语句可能会对IAP程序的正确性产生影响,所以需要谨慎处理。建议在修改判断语句之前,先进行一些简单的测试,验证是否能够正确判断bin文件的起始地址。