電子發燒友App
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系統不熟悉造成的大錯！
冰葑世紀：
我遇過單片機的程序跑飛的有，靜電干擾。 超頻過大。導致不穩定。
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）芯片不斷復位，這個問題不說了，如同芯片不斷上電斷電。
工商網監
評論