燒寫Flash後的DSP程式執行不正常的情況分析

這段時間一直在除錯dsp6713的flash燒寫，現在對flash的燒寫也算心中了如。

那天，成功燒寫了乙個300kb以上的程式，又認為，這次應該ok了……

那天，寫了個timer中斷程式，燒寫到flash，卻宕機了……

那天，在ram上執行很流暢的乙個演算法（演算法中呼叫了ccs的atan函式），在燒寫到flash後演算法卻宕機了……

「且行且珍惜」，珍惜這些次發現bug的機會，因此，我要總結：在ram中能正常執行，而燒寫到flash後無法正常執行的一些情況討論。

中斷向量表包含了所有中斷的入口，在燒寫flash的時候，有兩種方式可以保證中斷能正常工作。具體可參見tms320c6713燒寫flash的通用方法的第5小節。

很多情況下，當出現陣列越界時，在ram中的程式都能正常執行，但在燒寫flash後執行就會出現宕機或程式跑飛的現象。

比如定義乙個陣列，

int x[5];

你使用x[5]=10這樣的語句在ram程式中是某些時候能正確執行的，在pc上應該也可以。但將這種程式燒寫到flash之後執行，dsp果斷和你說拜拜！

因此，請謹慎地檢查程式**中的陣列越界和指標操作。在dsp程式中，堅決不使用c庫函式中的malloc函式。如果需要動態分配記憶體的操作，可以自己寫乙個，或使用ucos ii或dsp/bios等嵌入式作業系統。

也不知道是什麼原因，也可能是我對atan函式的使用方法不正確造成的吧。在我的乙個最初的程式中，我是直接這樣計算atan(x)的，

float x,y;
...y = atan(x); // x範圍為[0, 1.7]

在ram中以及在pc中都多次測試過沒有任何問題。

燒寫flash之後，也不是宕機，但程式執行到atan這個函式的時候會卡上很長一段時間，再接著往下執行。

難道是math.h中的atan運算效率太低？但為什麼ram中就能執行呢？這個還不清楚。

於是想了個招，在要使用三角函式和log等函式的地方都使用查表法替代庫函式，在精度要求高而儲存空間又有限的場合，可使用查表+插值的方式。

下面是改進方法計算atan，

/* table of determine atan(x) */
const float atan_tb = ;
y = atan_tb[((uint16_t)(x*100)) >> 1];

建立atan的表可以借助matlab。在需要插值的場合，比如，上面atan_tb的精度為0.02，而我們希望在少數的一些場合下使atan在0.01的精度，如果以0.01建表將會使表的資料儲存量擴大1倍，這是我們可以在0.02精度表的基礎上再使用插值的方式。

比如，要計算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)
result = max * 100 / (min + max);
return result;
}

咋一看，沒有語法問題，switch的break語句也加上了。

問題出就出在：dir低三位進行了編碼，最大編碼個數應該是8。而因為實際中只用到6種情況，switch中對其它的兩種編碼都使用break，問題就出來了，如果我的dir=0x00會怎麼樣？switch語句當然沒問題，問題在下一條語句：

result = max * 100 / (min + max);

dir=0x00沒有對max和min進行任何的賦值，而且其它地方也沒有。因此max和min作為區域性變數將會是乙個隨機的值，這在ram中是能夠執行通過的，但燒寫到flash之後，這種區域性變數的不確定性直接回導致flash宕機。

因此，對於switch以及if...else...的邏輯問題，不能只關注它們所在範圍，請仔細檢查其上下文。

x=a/b中若b可能為0，這樣的程式燒寫到flash會直接導致dsp宕機的。如果可以的話，盡量將除法運算轉換為移位運算。

比如，要計算y=x/0.02，乙個號的轉換方式就是：

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;

這樣你就再也看不到除法運算了。