燒寫Flash后的DSP程序運行不正常的情況分析

1、這段時間一直在調(diào)試DSP6713的Flash燒寫，現(xiàn)在對Flash的燒寫也算心中了如。那天，非常Happy的發(fā)現(xiàn)將閃爍LED燒寫到Flash成功了，然后，就以為一切都OK了那天，成功燒寫了一個300KB以上的程序，又認為，這次應(yīng)該OK了那天，寫了個Timer中斷程序，燒寫到Flash，卻死機了那天，在RAM上運行很流暢的一個算法（算法中調(diào)用了CCS的atan函數(shù)），在燒寫到Flash后算法卻死機了那天，我開始思考：是什么情況導(dǎo)致RAM中跑得很Happy的程序燒寫到Flash就運行得如此的不堪眾多的囧相?！扒倚星艺湎А?，珍惜這些次發(fā)現(xiàn)Bug的機會，因此，我要總結(jié)：在RAM中能正常運行，而燒寫到F

2、lash后無法正常運行的一些情況討論。請檢查中斷向量表中斷向量表包含了所有中斷的入口，在燒寫Flash的時候，有兩種方式可以保證中斷能正常工作。具體可參見TMS320C6713燒寫Flash的通用方法的第5小節(jié)。請檢查程序中隱蔽的內(nèi)存錯誤很多情況下，當出現(xiàn)數(shù)組越界時，在RAM中的程序都能正常運行，但在燒寫Flash后運行就會出現(xiàn)死機或程序跑飛的現(xiàn)象。比如定義一個數(shù)組，int x5;你使用x5=10這樣的語句在RAM程序中是某些時候能正確運行的，在PC上應(yīng)該也可以。但將這種程序燒寫到Flash之后運行，DSP果斷和你說拜拜！因此，請謹慎地檢查程序代碼中的數(shù)組越界和指針操作。在DSP程序中，堅決不

3、使用C庫函數(shù)中的malloc函數(shù)。如果需要動態(tài)分配內(nèi)存的操作，可以自己寫一個，或使用uCOS II或DSP/BIOS等嵌入式操作系統(tǒng)。請盡量避免使用math.h中的三角及l(fā)og等函數(shù)也不知道是什么原因，也可能是我對atan函數(shù)的使用方法不正確造成的吧。在我的一個最初的程序中，我是直接這樣計算atan(x)的，float x,y;.y = atan(x); / x范圍為0, 1.7在RAM中以及在PC中都多次測試過沒有任何問題。燒寫Flash之后，也不是死機，但程序運行到atan這個函數(shù)的時候會卡上很長一段時間，再接著往下運行。難道是math.h中的atan運算效率太低？但為什么RAM中就能運行

4、呢？這個還不清楚。于是想了個招，在要使用三角函數(shù)和log等函數(shù)的地方都使用查表法替代庫函數(shù)，在精度要求高而存儲空間又有限的場合，可使用查表+插值的方式。下面是改進方法計算atan，/* table of determine ATAN(x) */const float atan_tb = / 精度(0.020)0.00, 1.15, 2.29, 3.43, 4.57, 5.71 , 6.84, 7.97, 9.09, 10.20,11.31, 12.41, 13.50, 14.57, 15.64, 16.70 , 17.74, 18.78, 19.80, 20.81,21.80, 22.78,

5、23.75, 24.70, 25.64, 26.57 , 27.47, 28.37, 29.25, 30.11,30.96, 31.80, 32.62, 33.42, 34.22, 34.99 , 35.75, 36.50, 37.23, 37.95,38.66, 39.35, 40.03, 40.70, 41.35, 41.99 , 42.61, 43.23, 43.83, 44.42,45.00, 45.57, 46.12, 46.67, 47.20, 47.73 , 48.24, 48.74, 49.24, 49.72,50.19, 50.66, 51.12, 51.56, 52.00,

6、 52.43 , 52.85, 53.27, 53.67, 54.07,54.46, 54.85, 55.22, 55.59, 55.95, 56.31 , 56.66, 57.00, 57.34, 57.67,57.99, 58.31, 58.63, 58.93, 59.24, 59.53 , 59.83 ;y = atan_tb(uint16_t)(x*100) >> 1;建立atan的表可以借助Matlab。在需要插值的場合，比如，上面atan_tb的精度為0.02，而我們希望在少數(shù)的一些場合下使atan在0.01的精度，如果以0.01建表將會使表的數(shù)據(jù)存儲量擴大1倍，這是我

7、們可以在0.02精度表的基礎(chǔ)上再使用插值的方式。比如，要計算atan(0.03)，我們可以從表中查到atan(0.02)和atan(0.04)，如果僅使用線性插值的話，則atan(0.03) = (atan(0.02) + atan(0.04) / 2請檢查程序的邏輯曾傻傻的寫過一個類似下面的程序，uint8_t dir; / 低3位進行了編碼，下面的switch進行解碼int dist_switch(int a, int b, int c) int max_dist; int min_dist; int result = 0; switch (dir) case 0x00: break; c

8、ase 0x01: max=a;min=b;break; case 0x02: max=a;min=c;break; case 0x03: max=b;min=a;break; case 0x04: max=b;min=c;break; case 0x05: max=c;min=a;break; case 0x06: max=c;min=b;break; case 0x07: break; default: break; result = max * 100 / (min + max); return result;咋一看，沒有語法問題，switch的break語句也加上了。問題出就出在：di

9、r低三位進行了編碼，最大編碼個數(shù)應(yīng)該是8。而因為實際中只用到6種情況，switch中對其它的兩種編碼都使用break，問題就出來了，如果我的dir=0x00會怎么樣？switch語句當然沒問題，問題在下一條語句：result = max * 100 / (min + max);dir=0x00沒有對max和min進行任何的賦值，而且其它地方也沒有。因此max和min作為局部變量將會是一個隨機的值，這在RAM中是能夠運行通過的，但燒寫到Flash之后，這種局部變量的不確定性直接回導(dǎo)致Flash宕機。因此，對于switch以及if.else.的邏輯問題，不能只關(guān)注它們所在范圍，請仔細檢查其上下文。

10、請?zhí)貏e關(guān)照一下程序中的除法運算x=a/b中若b可能為0，這樣的程序燒寫到Flash會直接導(dǎo)致DSP死機的。如果可以的話，盡量將除法運算轉(zhuǎn)換為移位運算。比如，要計算y=x/0.02，一個號的轉(zhuǎn)換方式就是：y=(uint32_t)(x*100)/2=(uint32_t)(x*100) >> 1);還可以更好一點，將*100也使用移位替代，uint32_t tmp_x = (uint32_t)x;y = (tmp_x<<6) + (tmp_x<<5) + (tmp_x<<2) >> 1;這樣你就再也看不到除法運算了。/可能原因：1.程序沒有

11、跑起來，程序初始化有問題；2.片內(nèi)程序比仿真運行的快，燈已經(jīng)閃爍了，但是看不出來，可以用示波器查看。看到好多網(wǎng)友遇到過這樣的問題，現(xiàn)在就此問題來收集一下建議和解決方法，有更好的方法，還望大家多多分享。1.程序燒到Flash之后，請用不要斷開仿真器，用Load Symbols將程序加載，然后運行，F(xiàn)lash在線調(diào)試，看看程序跑到什么地方了？另外，程序中是否使用Delay_us()函數(shù)，此函數(shù)是否已經(jīng)copy到Ram中執(zhí)行。Stack的大小開的是否足夠？看看程序是否進入了什么illegal ISR？2.我也遇到了類似的問題，燒到flash里后連著仿真器非常正常，去掉仿真器就有一定的誤碼率。后來不使

12、用DELAY-US來延時，用定時中斷就不會出現(xiàn)這個問題了。DELAYUS在程序里已經(jīng)  .sect "ramfuncs"，是不是已經(jīng)聲明為RAM運行？還用不用在主程序里做一些處理？3.請確認是否正確初始化FLASH waitstates,通過以下方法：MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);/ Call Flash Initialization to setup flash waitstates/ This function must res

13、ide in RAM  InitFlash();/4./* Copy all FLASH sections that need to run from RAM (use memcpy() from RTS library) */ Section secureRamFuncs contains user defined code that runs from CSM secured RAMmemcpy(        &secureRamFuncs_runstart,&secureRamFuncs_loadstart,&

14、amp;secureRamFuncs_loadend - &secureRamFuncs_loadstart);/copy from the flash to the ram  for change the registers of the flash,/* Initialize the FLASH */InitFlash();晶振虛焊導(dǎo)致TI 28335 DSP 燒寫FLASH后，連接仿真器時正常工作，拔掉仿真器卻不能啟動運行 遇到個詭異的問題，28335的DSP，之前程序調(diào)試一切正常，但是燒寫FLASH后，拔掉仿真器卻始終部工作。解決思路：1) 檢查配置文件貌似

15、沒什么問題，復(fù)制到其他工程，在開發(fā)板上拔掉仿真器啟動正常。這部分應(yīng)該沒問題。2) 檢查DSP 啟動選擇部分 XA12XA15，看起來沒問題。3) 檢查DSP上電部分，使用示波器測試，TPS3305工作正常，/RESET信號正常。正當不知所措的時候，用示波器看了下有源晶振輸出，結(jié)果DSP啟動了。下電，再測，DSP不啟動的時候，晶振輸出呈鋸齒波，不同于正常的正弦波。使用示波器多次觸碰，晶振起振。分析：有源晶振虛焊，導(dǎo)致起振困難。原來接著仿真器的時候，仿真器發(fā)出的RESET信號使得晶振起振，DSP工作正常。示波器表筆存在寄生電容，觸碰晶振時使得晶振起振工作。解決：補焊晶振管腳，之后啟動正常。編了一個I2C的程序（中斷讀寫），在CCS里載到RAM運行正常，用CCS燒寫到Flash直接運行程序也正常，但燒寫進Flash如果脫開CCS重新上電，就不正常，I2C總線總是不釋放，不知道什么原因，其他相關(guān)的eCAP、ePWM、ADC、串口等程序在RAM中和在Flash中運行都一樣，惟獨這個I2C程序不行。原來我是在初始化程序完了最后開了中斷以后立即I2CA_Read,就是不行，I2C死在I2CA_Wait地方，現(xiàn)在我在開了中斷以后不立即I2CA_Rea