在产品升级中,经常会有需要升级产品,修复原有BUG等情况,需要我们将原来的代码移植到全新的硬件平台上,通常来说可以重写代码或者移植代码。
在硬件型号相似,SDK变化不大的情况下,移植代码可以有效提升工作效率。
但有时缺乏相对应的技巧也会浪费很多时间,反而不如重写代码。
最近移植的代码较多,下面以深圳曦华科技的Evk为例,分析从CVM0118移植到CVM0128中可能会遇到的一些问题(以Eclipse为例):
1、 SDK版本变更产生的问题
SDK版本变更可能会涉及结构体、函数名、宏定义等等问题。在使用同一公司不同版本SDK包时,这些问题大部分可以通过编译来解决,剩下的小问题再分析一下,这部分基本不会遇到什么难题。
2、芯片型号变更产生的问题
在变更芯片型号时,需要注意软硬件兼容的问题,并注意更新IDE/下载器内对应的配置。
3、环境配置问题
在移植代码时,往往是在原有代码的基础上直接进行修改,因此环境配置也会沿用先前的配置,如果忽视环境配置,可能会产生一些预期之外的问题,下面提供一些常见问题的解决思路。
3.1 ld链接文件不匹配
在修改代码后,如果没注意环境配置,仍然可能会出现问题。
当编译结束后,代码没有问题,但编译器仍可能会报ld文件错误
此时右键项目-Properties-C/C++ Build-Settings-GNU Arm Cross C Linker General找到链接文件路径,确认该路径下的ld链接文件与芯片相匹配。
修改好之后重新编译。
问题修复。
3.2 Debug文件缺失
在Debug时还可能会遇到如下问题。
这类问题是由于Settings文件不匹配产生,这里可以打开Debug Configurations来查看。
上图可以看出,C/C++ Application文件缺失,因此这里需要手动点击Browse来添加elf文件。
添加该文件后,可以正常进入Debug模式,但是这里可以明显看出问题。
Debug时无法自动停下,程序在进入main之前就发生了错误,这很有可能是启动代码出现了问题。
启动代码产生的原因可能有多种,例如访问错误地址,芯片型号与启动文件不匹配等等。
通常情况下,可以默认SDK没有问题。此时可以继续检查debug config的配置。
此时可以看出,Debug配置中的Device name与当前芯片型号不匹配,这仍然是Settings文件生成的默认配置不匹配的问题。
这里手动将Device name修改为CVM0128,并继续Debug。
这里可以看出,修改device name后,程序可以正常运行了。
到这里CVM0118到CVM0128的代码移植完成。
以上介绍了如何将代码移植到新的环境,并成功运行起来。
但在实际的产品开发中,代码还需要根据MCU的时钟,管脚资源,片上外设资源等实际情况调试,直至完全匹配。