在产品升级中，经常会有需要升级产品，修复原有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的时钟，管脚资源，片上外设资源等实际情况调试，直至完全匹配。