DSP的BOOT解决之道

1万 · 2012-7-18 19:03

以下内容转自www.xsgps.com
DSP的BOOTLOADER
历时接近20天，一个小小的本不该成为障碍的障碍终于解决了，做一下笔记好了！
问题描述：TI DSP flash烧写及自启动
DSP型号：DM642
所有的系统在结束了仿真器开发后，都需要解决一个问题，就是将程序烧写到外部存储芯片中，完成系统上点后的自启动和引导，大多数，就是flash的烧写和自启动。
一，系统初期，没有估计到这部分的工作量，直到与苏工结帐时仍然以为这是一个手到擒来的过程。
也许是以前在实验室，单片机和FPGA的开发过程中，没有遇到过类似的问题，所以我相当然地以为对于DSP也是同样的过程。现在想想，单片机是用单独的编程器烧写，而FPGA因为开发板提供厂商已经把大量的底层都完善了，我们所需要做得仅仅是编译产生下载文件，下载，OK！按理说，如果我们也是采取购买开发板的途径进行开发，开发板提供厂商也应该把这部分工作做完了。但是，我们找的是单独的小公司设计一块系统板，这部分工作，尤其是如果系统板和开发板有所不同的这部分工作，就应改在设计初期，签合同时，明确提出来是谁做，做到权责明析，很遗憾我们没有。而且，在项目进行中和那个帮我们做板子的人有点不愉快，最要命的是我已经把项目款付给了人家，接下来的工作量，就不能不说是我们自找的了。
二，我意识到，我不得不自己去做这部分工作了，于是开始想要借力合众达。合众达是TI的官方合作伙伴，中国TI DSP的技术支持。
一开始，合众达觉得我是它们开发板的潜在买家。于是开始费力地给我介绍它们的VPM642。于是我告诉它们，我的系统是自己设计的，希望能够得到它们的支持。他们于是好奇地研究了研究我的板子，然后告诉我，它们这边只是支持合众达的VPM642开发板，而且我的板子和它们的不同，它们也不保证提供的在 VPM642上work的东西在我的板子上也能正常工作。anyway，我说给我吧，我可以作为参考。
于是我搞到两块板子的图纸，开始详细比较二者的不同。

1万 · 2012-7-18 19:03

三，根据我比较的结果，我认为，二者没有本质的不同，都是AMD的芯片，型号有差异，一个33，一个320，它们能用的我应该也能用。我拿来SEED的测试程序开始测我的flash，结果是，没有结果……

这时TI 的Robin给了我很重要的hint，需要修改FBTC.pjt，根据flash芯片的不同，不到一天我修改完了，还是不能连接。

四，张金龙给了我两个很重要的暗示的第一个。之所以FBTC修改后，出现错误提示，可能是由于我是用CCS3.1编译的，而原本人家是2.2的。所以我去问SEED要了支持3.1版本的flashburn安装后，flashburn连接的问题解决了。

五，但是硬件上flash的测试仍旧没有通过，张金龙也不知道是为什么。几天后，问题发现了，CPLD中对flash的分页没有工作，而且总线有冲突。我回头去找苏工，他也意识到这是他的问题，于是，两天后，解决了这个问题。flash硬件测试通过，分页信号正确，flashburn也连接上了。

六，做到这一步后，某一个晚上，我连接好所有的系统，将一个闪灯和串口发送的test工程烧写进flash，重新上电后，自启动成功！这时我有点激动，以为问题解决了。可是等我将我们的工程编译下载后，重启动却没有反应！我傻眼了，怎么会呢………………我反复比较两次操作的不同，修改 memory config添加BOOT段，添加boot.asm引导汇编程序，制作hexconv.cmd，一切的一切都是一样的，可是结果却是不同，于是，又是长时间的毫无头续。

七，到这里已经一周过去了。并且接下来的几天，事情没有任何进展，我发现问题可能是由于我们的工程太大了导致的。于是查阅相关资料，发现很多人碰到过同样的问题。但是没有解决问题的人回答过。我于是重新求助合众达，求助苏工，求助张金龙，事情毫无进展，所有人似乎都没碰到过这个问题。这时 SEED的楼工给了我一个hint，可能是由于多页烧写，他给了我一个flashburn多页烧写的boot.asm，结果还是没有成功。

八，张金龙和楼工这时都建议我采用另外编写工程，在线烧写的方式。我甚至已经准备好了这个工程，通过比较hex文件和flash内内容，证明已经能够正确地烧写各个数据段到flash了。但是，各个数据段在flash中的组织格式很麻烦，我研究了两天没有结果。同时，又有了其他方面的新的启发。张金龙给我的第二个hint，发现我的hex文件已经达到了12M，而flash只有4M，就算分页成功了也无济于事。于是我开始怀疑 hexconv.cmd的正确性，最终，去掉了-image这个选项，hex文件大小降到490K，小于flash一页512K的大小。也就是说，根本不用考虑分页的问题了。

九，即使到了这里，我明确的感觉到似乎快要成功了，但是却依然没有头续，究竟是哪里出错了呢？合众达技术支持的最大的牛，SEED技术论坛的元老级人物楼工页没有办法了。他答应给我联系SEED的研发人员，见面解决看看这个问题。而我，在这个等待的过程中，漫无目的地进行这其他的尝试

十，某夜，我将一个中等的采集程序的Config程序进行烧写，它也包括了CMOS的采集部分，只是没有后续处理。发现这个程序可以自启动到 main函数！这对我来说，不叱为一个巨大的鼓舞。我开始比较Config和最大工程evmdm642这两个cdb文件，即DSP/BIOS配置文件。有两个不同，一个是添加了vcap的task，另一个是添加了硬件中断HWI，我于是试着将这两个东西以各种组合加到原来的cdb上，无果。

final，12月19日，一日没有什么结果，与SEED的研发见面时间被推后了，我决定把task和hwi的组合再使一遍，不抱什么希望，当我试到添加 task，也添加hwi，但是去掉hwi内部的一个generate reset at address 0选项时，竟然成功了！

我又烧写了一遍，等到确定成功后，我赶紧把工程备份了，并且起了个名字“nnd为什么好了whywhywhy”，然后收拾东西回家。我实在不愿这时候比较为什么，明天吧！

结果，确实是那个问题，我跟楼工交流过，他和我同时查到了这个选项的说明，他在文档spra403中，我在ccs的在线帮助文档里：

Generate RESET vector at address 0. Check this box in order to

place the interrupt vector table at address 0. This option is available

only if address 0 currently exists within the memory configuration.

TextConf Name: RESETVECTOR Type: Bool

Example: HWI.RESETVECTOR = false;

我是这样理解的：中断向量表VEC默认是保存在0x00－0x200的地址上的，而我们由于再0x00－0x400放的是我们的启动文件Boot，而vecs被顺延到0x400－0x600，所以应该取消这个选项！