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

1、这段时间一直在调试DSP6713的Flash烧写，现在对Flash的烧写也算心中了如。那天，非常Happy的发现将闪烁LED烧写到Flash成功了，然后，就以为一切都OK了那天，成功烧写了一个300KB以上的程序，又认为，这次应该OK了那天，写了个Timer中断程序，烧写到Flash，却死机了那天，在RAM上运行很流畅的一个算法（算法中调用了CCS的atan函数），在烧写到Flash后算法却死机了那天，我开始思考：是什么情况导致RAM中跑得很Happy的程序烧写到Flash就运行得如此的不堪众多的囧相。“且行且珍惜”，珍惜这些次发现Bug的机会，因此，我要总结：在RAM中能正常运行，而烧写到F

2、lash后无法正常运行的一些情况讨论。请检查中断向量表中断向量表包含了所有中断的入口，在烧写Flash的时候，有两种方式可以保证中断能正常工作。具体可参见TMS320C6713烧写Flash的通用方法的第5小节。请检查程序中隐蔽的内存错误很多情况下，当出现数组越界时，在RAM中的程序都能正常运行，但在烧写Flash后运行就会出现死机或程序跑飞的现象。比如定义一个数组，int x5;你使用x5=10这样的语句在RAM程序中是某些时候能正确运行的，在PC上应该也可以。但将这种程序烧写到Flash之后运行，DSP果断和你说拜拜！因此，请谨慎地检查程序代码中的数组越界和指针操作。在DSP程序中，坚决不

3、使用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中就能运行

4、呢？这个还不清楚。于是想了个招，在要使用三角函数和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,

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，而我们希望在少数的一些场合下使atan在0.01的精度，如果以0.01建表将会使表的数据存储量扩大1倍，这是我们可以在0.02精

7、度表的基础上再使用插值的方式。比如，要计算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:

8、 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低三位进行了编码

9、，最大编码个数应该是8。而因为实际中只用到6种情况，switch中对其它的两种编码都使用break，问题就出来了，如果我的dir=0x00会怎么样？switch语句当然没问题，问题在下一条语句：result = max * 100 / (min + max);dir=0x00没有对max和min进行任何的赋值，而且其它地方也没有。因此max和min作为局部变量将会是一个随机的值，这在RAM中是能够运行通过的，但烧写到Flash之后，这种局部变量的不确定性直接回导致Flash宕机。因此，对于switch以及if.else.的逻辑问题，不能只关注它们所在范围，请仔细检查其上下文。请特别关照一下程序

10、中的除法运算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_x6) + (tmp_x5) + (tmp_x 1;这样你就再也看不到除法运算了。/可能原因：1.程序没有跑起来，程序初始化有问题；2.片内程序比仿真运行的快，灯已经闪烁了，但是看不出来，可以用示波器查看。看到好

11、多网友遇到过这样的问题，现在就此问题来收集一下建议和解决方法，有更好的方法，还望大家多多分享。1.程序烧到Flash之后，请用不要断开仿真器，用Load Symbols将程序加载，然后运行，Flash在线调试，看看程序跑到什么地方了？另外，程序中是否使用Delay_us()函数，此函数是否已经copy到Ram中执行。Stack的大小开的是否足够？看看程序是否进入了什么illegal ISR？2.我也遇到了类似的问题，烧到flash里后连着仿真器非常正常，去掉仿真器就有一定的误码率。后来不使用DELAY-US来延时，用定时中断就不会出现这个问题了。DELAYUS在程序里已经.sect ramfu

12、ncs，是不是已经声明为RAM运行？还用不用在主程序里做一些处理？3.请确认是否正确初始化FLASH waitstates,通过以下方法：MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);/ Call Flash Initialization to setup flash waitstates/ This function must reside in RAMInitFlash();/4./* Copy all FLASH sections that need to run from RAM (use memcpy

13、() from RTS library) */ Section secureRamFuncs contains user defined code that runs from CSM secured RAMmemcpy( &secureRamFuncs_runstart,&secureRamFuncs_loadstart,&secureRamFuncs_loadend - &secureRamFuncs_loadstart);/copy from the flash to the ramfor change the registers of the flash,/* Initialize t

14、he FLASH */InitFlash();晶振虚焊导致TI 28335 DSP 烧写FLASH后，连接仿真器时正常工作，拔掉仿真器却不能启动运行 遇到个诡异的问题，28335的DSP，之前程序调试一切正常，但是烧写FLASH后，拔掉仿真器却始终部工作。解决思路：1) 检查配置文件貌似没什么问题，复制到其他工程，在开发板上拔掉仿真器启动正常。这部分应该没问题。2) 检查DSP 启动选择部分 XA12XA15，看起来没问题。3) 检查DSP上电部分，使用示波器测试，TPS3305工作正常，/RESET信号正常。正当不知所措的时候，用示波器看了下有源晶振输出，结果DSP启动了。下电，再测，DSP

15、不启动的时候，晶振输出呈锯齿波，不同于正常的正弦波。使用示波器多次触碰，晶振起振。分析：有源晶振虚焊，导致起振困难。原来接着仿真器的时候，仿真器发出的RESET信号使得晶振起振，DSP工作正常。示波器表笔存在寄生电容，触碰晶振时使得晶振起振工作。解决：补焊晶振管脚，之后启动正常。编了一个I2C的程序（中断读写），在CCS里载到RAM运行正常，用CCS烧写到Flash直接运行程序也正常，但烧写进Flash如果脱开CCS重新上电，就不正常，I2C总线总是不释放，不知道什么原因，其他相关的eCAP、ePWM、ADC、串口等程序在RAM中和在Flash中运行都一样，惟独这个I2C程序不行。原来我是在初始化程序完了最后开了中断以后立即I2CA_Read,就是不行，I2C死在I2CA_Wait地方，现在我在开了中断以后不立即I2CA_Read，而是