DSP程序跑飞的原因？你是如何解决的？

zxcvbvbnmn

　　DSP程序跑飞的原因有哪些？你是如何解决的？

　　michael_xing：

　　先说说我以前的项目经历。

　　一般调试代码的步骤有两种方案

　　方案一：先调试主程序，最后添加看门狗等保护电路；

　　方案二：先搭建代码环境，比如看门狗保护电路等，然后在该平台上开发主程序。

　　我呢，为了更好的编写算法代码，往往采用方案一。

　　在我调试代码的过程中，遇到过如下一种程序跑飞的情况：

　　【原因】硬件看门狗电路设计失误

　　【设计】我设计的方案中，采用美信芯片MAX706AT设计硬件看门狗电路，看似非常完美的电路，在连接仿真器进行简单方波输出测试时，发现DSP没有任务输出。程序已经异常了，因为我采用的方案一设计代码，所以我只知道异常，不知道原因。

　　【解决思路】

　　1、无数次的下载程序，并运行程序，但是程序总是异常运行。

　　2、庆幸的是，我的电路设计中有好几个IO直接驱动LED的电路，这时候，我特别注意到LED显示的亮度不正常，然后，我赶紧拿万用表测试IO电压，结果只有1.6V左右。这时，我已经明白，看门狗异常了。

　　3、排查电路中的MAX706AT电路，一点问题都没有。查找MAX706AT的封装和管脚对应时，发现了问题的根源。芯片有SO和UMAX两种封装，说来奇怪，名称完全相同，封装不同，加上管脚定义不同，造成了看门狗芯片的复位电压总是低电压。

　　终于找到问题了。

　　michael_xing：

　　在我调试代码的过程中，遇到过如下一种程序跑飞的情况：

　　【原因】中断处理超时引起程序跑飞

　　【设计】我设计的基于TMS320F28335（4）的双极性信号采集系统，因为频率较高，因此采用了中断采集方式，也就是说，我用PWM输出方波，触发采集模块开始采集，当采集锁存之后，会中断

　　告知dsp进行数据读取。那么数据读取就是在中断中进行的。

　　在初版中，采用周期=20ms/256进行采样触发。

　　很奇怪的问题发生了，DEBUG模式下，没有问题，可以采集到数据，但是RELEASE模式下，采集数据时，程序跑飞。

　　当意识到程序跑飞时，怀疑到中断程序太长，或者处理时间太长。

　　【解决思路】

　　猜测周期太短，那么可以将周期增加，周期=20ms/128，仍然失败告终。

　　再减周期=20ms/64，okay。

　　宜将剩勇追穷寇，周期减为=20ms/32，okay

　　第一次就这样解决了。

　　【附】当使用dsp进行算法处理时，一定要先对算法评估，否则，当认识到自己程序问题时，已经来不及了，因为参数修改之后，有可能不能满足系统的需求。

　　Cresta：

　　我遇到过的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系统不熟悉造成的大错！

　　冰葑世纪：

　　我遇过单片机的程序跑飞的有，静电干扰。 超频过大。导致不稳定。

5 z# E( X  P, A4 H; q  K. e

　　robi：

　　分享下程序经常跑飞的ti dsp 调试原因

　　1） 程序没有结尾或不是循环的程序。

　　2）nmi管脚没有上拉。

　　3）在看门狗动作的时候程序会经常跑飞。

　　4）程序编制不当也会引起程序跑飞。

　　5）硬件系统有问题

　　liulin126：

　　数值溢出，读写了超过范围的存储空间，堆栈溢出，异常主要原因。

　　wjw1989：

　　我之前玩ARM，应该道理是相同的吧。

　　复位芯片的原理，是为了防止程序出错。但是不能通过复位来解决异常问题，所以，首先要调试代码，做到代码正常运转，然后，再添加复位模块。这样才能做好产品，否则，为了复位而复位。

　　wjw1989：

　　分享个别人的经验：

　　我所知道的DSP程序跑飞的原因有：

　　硬件：1.复位电路不稳定；2.电源不稳定；3.地线不稳定。

　　软件：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系统不熟悉造成的大错！

　　wjw1989：

　　朋友也有一些分享，这里总结如下：

　　我所知道的DSP程序跑飞的原因有：

　　硬件：1.复位电路不稳定；2.电源不稳定；3.地线不稳定。

　　软件：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系统不熟悉造成的大错！

　　我个人觉得，关于硬件，问题无非就是一个：电源。

　　电源不稳，芯片工作肯定不正常。不正常会出现什么问题呢？

　　（1）芯片不工作。哈哈。这是我这次却发现，当IO输出短路，会造成芯片不工作，现象是：芯片io电平不死3.3v，而是1.768v

　　（2）芯片不断复位，这个问题不说了，如同芯片不断上电断电。

shapeofyou888

很详细，学习了