烧写Flash后的DSP程序运行不正常的情况分析

这段时间一直在调试DSP6713的Flash烧写，现在对Flash的烧写也算心中了如。

那天，非常Happy的发现将闪烁LED烧写到Flash成功了，然后，就以为一切都OK了……

那天，成功烧写了一个300KB以上的程序，又认为，这次应该OK了……

那天，写了个Timer中断程序，烧写到Flash，却死机了……

那天，在RAM上运行很流畅的一个算法（算法中调用了CCS的atan函数），在烧写到Flash后算法却死机了……

那天，我开始思考：是什么情况导致RAM中跑得很Happy的程序烧写到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等嵌入式操作系统。

请尽量避免使用math.h中的三角及log等函数

也不知道是什么原因，也可能是我对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[] = {  // 精度(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,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,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，而我们希望在少数的一些场合下使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)
{
    int max_dist;
    int min_dist;
    int result = 0;

    switch (dir) {
    case 0x00: break;
    case 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语句也加上了。

问题出就出在：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;

这样你就再也看不到除法运算了。