DSP程序跑飞原因状况一
一般调试代码的步骤有两种方案：方案一是先调试主程序，最后添加看门狗等保护电路；方案二是先搭建代码环境，比如看门狗保护电路等，然后在该平台上开发主程序。为了更好的编写算法代码，往往采用方案一。在调试代码的过程中，遇到过如下一种程序跑飞的情况：
【原因】
硬件看门狗电路设计失误。
【设计】
设计方案中，采用美信芯片MAX706AT设计硬件看门狗电路，看似非常完美的电路，在连接仿真器进行简单方波输出测试时，发现DSP没有任务输出。程序已经异常了，因为采用的方案一设计代码，所以只知道异常，不知道原因。
【解决思路】
1、无数次的下载程序，并运行程序，但是程序总是异常运行。
2、庆幸的是，电路设计中有好几个IO直接驱动LED的电路，这时候，特别注意到LED显示的亮度不正常，然后赶紧拿万用表测试IO电压，结果只有1.6V左右。这时已经明白，是看门狗异常了。
3、排查电路中的MAX706AT电路，一点问题都没有。查找MAX706AT的封装和管脚对应时，发现了问题的根源。芯片有SO和UMAX两种封装，说来奇怪，名称完全相同，封装不同，加上管脚定义不同，造成了看门狗芯片的复位电压总是低电压。
终于找到问题了。
DSP程序跑飞原因状况二
【原因】
中断处理超时引起程序跑飞
【设计】
设计基于TMS320F28335(4)的双极性信号采集系统，因为频率较高，因此采用了中断采集方式，也就是说用PWM输出方波，触发采集模块开始采集，当采集锁存之后会中断。
告知dsp进行数据读取。那么数据读取就是在中断中进行的。
在初版中，采用周期=20ms/256进行采样触发。
很奇怪的问题发生了，DEBUG模式下，没有问题，可以采集到数据，但是RELEASE模式下，采集数据时，程序跑飞。
当意识到程序跑飞时，怀疑到中断程序太长，或者处理时间太长。
【解决思路】
猜测周期太短，那么可以将周期增加，周期=20ms/128，仍然失败告终。
再减周期=20ms/64，okay。
宜将剩勇追穷寇，周期减为=20ms/32，okay
第一次就这样解决了。
【附】当使用dsp进行算法处理时，一定要先对算法评估，否则，当认识到自己程序问题时，已经来不及了，因为参数修改之后，有可能不能满足系统的需求。
DSP程序跑飞原因状况三
1.不小心操作到了子函数返回地址值。
2.数值溢出，读写了超过范围的存储空间，堆栈溢出等 。
程序是带有BIOS的程序，当程序跑飞后我就在主函数的最后一行设置断点，结果程序可以跑到主函数的最后一行，接下来就是初始化BIOS操作系统了，操作系统的源代码又是不可见的，所以一时陷入了僵局。不知道该怎么办好。
在移植程序的时候跑飞的，后来我就拿程序的BIOS配置和另一个正常的BIOS配置比较，结果发现Stack Size是0x400(即默认的配置)，而另一个是0x1000，然后改过来之后程序恢复正常。
一开始的时候意识到可能是堆栈溢出造成的程序跑飞，所以就增大了每块存储器上的动态堆栈，即：create a heap in this memory heap size:0x08000 。结果不管用。
后来才修改的Stack Size (MAUs)选项，即全局的堆栈大小，从0x400改到0x1000然后问题排除。后来才明白，动态堆栈是用来动态的创建任务用的，并非是想要的那个堆栈。经过反思感觉还是对BIOS系统不熟悉造成的大错!
DSP程序跑飞原因状况四
过单片机的程序跑飞的有，静电干扰。 超频过大。导致不稳定。
DSP程序跑飞原因状况五
程序经常跑飞的ti dsp 调试原因
1) 程序没有结尾或不是循环的程序。
2)nmi管脚没有上拉。
3)在看门狗动作的时候程序会经常跑飞。
4)程序编制不当也会引起程序跑飞。
5)硬件系统有问题
数值溢出，读写了超过范围的存储空间，堆栈溢出，异常主要原因。复位芯片的原理，是为了防止程序出错。但是不能通过复位来解决异常问题，所以，首先要调试代码，做到代码正常运转，然后，再添加复位模块。这样才能做好产品，否则，为了复位而复位。